diff --git a/CLAUDE.md b/CLAUDE.md
index f7624763..c7179573 100644
--- a/CLAUDE.md
+++ b/CLAUDE.md
@@ -8,17 +8,48 @@ This repo is the single source of truth for the TrUAPI protocol. It vendors `dot
 
 ```
 rust/crates/
-  truapi/                Rust trait + type definitions for protocol versions v0.1 and v0.2
+  truapi/                Rust trait + type definitions for protocol versions v0.1 and v0.2 (canonical)
   truapi-codegen/        rustdoc JSON → TypeScript client + Rust dispatcher
   truapi-macros/         #[wire(id = N)] proc-macro
+  truapi-platform/       Host syscall traits (storage, navigation, consent, ...)
+  truapi-server/         Rust runtime hosts implement; ships as WASM (browser/node) and via UniFFI (iOS/Android)
+  uniffi-bindgen-cli/    Thin CLI wrapper around uniffi::uniffi_bindgen_main()
 js/packages/
-  truapi/         @parity/truapi TS package; generated TS lives under ignored paths
-playground/              Next.js interactive playground; deploys to truapi-playground.dot
-hosts/dotli/             dotli submodule
-docs/                    design docs, RFCs, feature proposals
-scripts/codegen.sh       regenerate the TS client from the Rust crate
+  truapi/                  @parity/truapi TS package; generated TS lives under ignored paths
+  truapi-host/             @parity/truapi-host host-side codegen + dispatcher (no shared core)
+  truapi-host-wasm/        @parity/truapi-host-wasm: WASM-backed host runtime. Subpath entries:
+                           `.` (core Provider + dispatcher + node runtime), `/web` (iframe + Web
+                           Worker), `/electron` (MessagePortMain), `/worker-runtime` (Worker entry).
+                           WASM bundle (gitignored) under dist/wasm/{web,node}/, built via `make wasm`
+android/
+  truapi-host/             io.parity:truapi-host-android Maven library (AAR + UniFFI Kotlin bindings)
+ios/
+  truapi-host/             TrUAPIHost Swift Package (sources + UniFFI Swift bindings)
+playground/                Next.js interactive playground; deploys to truapi-playground.dot
+hosts/dotli/               dotli submodule
+docs/                      design docs, RFCs, feature proposals
+scripts/codegen.sh         regenerate the TS client from the Rust crate
 ```
 
+### Crate + binding invariants
+
+- `truapi` is canonical; runtime crates re-export rather than redefine. New
+  syscall traits and host-side runtime types live in `truapi-platform` and
+  `truapi-server`, not in `truapi`. Any additions to `truapi` itself are limited
+  to additive `Display` impls.
+- All types exposed by `truapi-platform` and `truapi-server` come from
+  `truapi::versioned::*` and `truapi::v01::*`. The runtime crates re-export
+  rather than redefine.
+- `truapi-server` WASM artifacts live under
+  `js/packages/truapi-host-wasm/dist/wasm/{web,node}/` and are gitignored.
+  Build them locally with `make wasm` (rerun whenever
+  `rust/crates/truapi-server/` changes); CI builds the bundle fresh from the
+  Rust source on every run.
+- UniFFI bindings under `android/truapi-host/` and `ios/truapi-host/` are generated from the
+  `truapi-server` cdylib via `make uniffi`. The generated Swift modulemap may
+  need a one-time relocation into `Sources/truapi_serverFFI/include/`, the
+  `make uniffi` target prints a reminder.
+
 ## Code style
 
 - Every `pub` Rust item (functions, methods, types, traits, modules, constants) carries a doc comment (`///` or `//!`).
@@ -116,6 +147,87 @@ submodule init + `bun install` and the per-pane `cd` discipline).
 Alternatively, with a deployed Polkadot Desktop Host installed, navigate to
 `https://dot.li/localhost:3000` from within it.
 
+#### Local dotli + playground E2E notes
+
+Use `make dev DEBUG=1` from the repo root for the local host stack. It prepares
+the ignored WASM/build artifacts, verifies dotli can resolve
+`@parity/truapi-host-wasm`, then starts dotli on `:5173` and the playground on
+`:3000`. Open `http://localhost:5173/localhost:3000`.
+
+When automating with Playwright, block service workers for smoke tests unless
+the test is explicitly about SW behavior. Stale host/product bundles can mask
+runtime fixes. Use a fresh cache-busting query string on
+`http://localhost:5173/localhost:3000?...`, collect `pageerror` and
+`console` messages, and fail on unexpected page errors.
+
+For interactive SSO checks, prefer a persistent headed Chrome profile and reuse
+the same browser context across checks. SSO pairing needs a real phone QR scan,
+and signing/resource-allocation flows may need web or mobile confirmation; if
+the human or companion app is unavailable, skip those methods and record the
+skip instead of treating it as a protocol failure. Non-interactive checks should
+still verify that the playground renders, the TrUAPI debug panel receives
+host/product events, generated examples can call non-confirmation methods, and
+logout/relogin does not restore a stale session.
+
+The dotli Playwright e2e suite under `hosts/dotli/apps/host/tests/e2e/`
+pairs through the signer-bot service. It requires `SIGNER_BOT_SVC_TOKEN`;
+`SIGNER_BOT_BASE_URL` and `SIGNER_BOT_NETWORK` default to dotli CI's
+`https://signing-bot-dev.novasama-tech.org/` and `paseo-next-v2`. Without the
+token, do not treat the full suite as locally runnable. Use
+`E2E_DOTLI_SMOKE=1 make e2e-dotli` for the no-phone QR smoke path.
+
+For a fully automated local playground diagnosis run, use:
+
+```bash
+SIGNER_BOT_SVC_TOKEN=... \
+make e2e-dotli
+```
+
+`make e2e-dotli` starts dotli preview and the playground, signs out any
+restored host session, signs in through signer-bot by extracting the QR payload,
+runs the playground Diagnosis screen, auto-accepts host-side Allow/Sign modals,
+and writes `hosts/dotli/test-results/e2e-dotli/diagnosis-report.md`.
+
+Root CI runs the same target when it can read the private dotli submodule. It
+needs `DOTLI_CHECKOUT_TOKEN` for submodule checkout; without that token, the
+job warns and skips dotli e2e rather than failing unrelated PR checks. With
+dotli access but without `SIGNER_BOT_SVC_TOKEN`, CI runs the no-phone smoke
+path only.
+
+A useful no-phone smoke assertion is:
+
+```bash
+E2E_DOTLI_SMOKE=1 make e2e-dotli
+```
+
+For manual debugging of that smoke path:
+
+1. Start `make dev DEBUG=1`.
+2. Open `http://localhost:5173/localhost:3000?debug=truapi&cachebust=<ts>` with
+   service workers blocked.
+3. Wait for `globalThis.__truapi?.setLogLevel`, call
+   `__truapi.setLogLevel("debug")`, and confirm the console logs
+   `[truapi worker] logLevel=debug providers=0`.
+4. Click `#auth-button`, wait for `#auth-modal-backdrop.open`, and confirm:
+   the modal shows `Login with Polkadot Mobile`, `__truapi.getProviderCount()`
+   is greater than zero, worker frame/callback logs appear, and there are no
+   page errors.
+
+If `make dev` reports `EADDRINUSE` on `:5173` or the playground moves from
+`:3000` to `:3001`, kill stale `preview-server.ts` / `next dev` processes and
+restart the tmux session. Port drift causes false-negative local e2e results.
+
+Useful debug signals:
+
+```bash
+localStorage.setItem("truapi:logLevel", "debug")
+sessionStorage.setItem("dotli:truapi-debug", "1")
+```
+
+Reload after setting them. Watch for `Unknown wire discriminant`, missing
+`@parity/truapi-host-wasm` imports, worker WASM instantiation failures, and
+debug-panel traffic disappearing when the login popup opens.
+
 ## Deployment
 
 Pushes to `main` trigger `.github/workflows/deploy-playground.yml`, which builds `playground/` and publishes the static export to `truapi-playground.dot` via `bulletin-deploy`.
diff --git a/README.md b/README.md
index a08d9483..78c09f9b 100644
--- a/README.md
+++ b/README.md
@@ -57,14 +57,47 @@ rust/crates/
   truapi/                Rust trait and type definitions (v01, v02)
   truapi-codegen/        rustdoc JSON to TypeScript client + Rust dispatcher
   truapi-macros/         #[wire(id = N)] proc-macro
+  truapi-platform/       Host syscall traits used by truapi-server (storage, navigation, consent, ...)
+  truapi-server/         Rust runtime that hosts implement: dispatcher, frames, SCALE, WASM + UniFFI surfaces
+  uniffi-bindgen-cli/    Thin CLI wrapper around uniffi::uniffi_bindgen_main() for the workspace
 js/packages/
-  truapi/                @parity/truapi TypeScript client
-playground/              Interactive Next.js playground (truapi-playground.dot)
-hosts/dotli/             dotli host, vendored as a submodule
-docs/                    Design docs, RFCs, feature proposals
-scripts/codegen.sh       Regenerate the TS client from the Rust source
+  truapi/                  @parity/truapi TypeScript client
+  truapi-host/             @parity/truapi-host host-side codegen and dispatcher (no shared core)
+  truapi-host-wasm/        @parity/truapi-host-wasm: WASM-backed host runtime; entries `.` (core),
+                           `/web` (iframe + Web Worker), `/electron` (MessagePortMain), `/worker-runtime`
+android/
+  truapi-host/             io.parity:truapi-host-android Maven library (AAR + UniFFI Kotlin bindings)
+ios/
+  truapi-host/             TrUAPIHost Swift Package (sources + UniFFI Swift bindings)
+playground/                Interactive Next.js playground (truapi-playground.dot)
+hosts/dotli/               dotli host, vendored as a submodule
+docs/                      Design docs, RFCs, feature proposals
+scripts/codegen.sh         Regenerate the TS client from the Rust source
 ```
 
+### Native + JS host SDKs
+
+JS hosts integrate the Rust core through [`@parity/truapi-host-wasm`](js/packages/truapi-host-wasm),
+a single package with tree-shakeable subpath entries (the separate
+`@parity/truapi-host`, with no shared core, is for hosts that bring their own runtime):
+
+- `@parity/truapi-host-wasm` (the `.` entry) ships the `truapi-server` WASM bundle, the
+  `Provider` factories that drive it, the dispatcher adapter, and `createNodeWasmProvider`.
+- `@parity/truapi-host-wasm/web` wires the WASM provider into a browser host: the iframe
+  MessageChannel handshake (`createIframeHost`) plus `createWebWorkerProvider`.
+- `@parity/truapi-host-wasm/electron` wraps an Electron `MessagePortMain` as a `Provider`.
+- `@parity/truapi-host-wasm/worker-runtime` is the Web Worker entrypoint so the WASM core can
+  run off the page main thread.
+
+Native shells sit one level under `android/` and `ios/` and ship as versioned packages from git tags:
+
+- [`android/truapi-host/`](android/truapi-host) builds the `io.parity:truapi-host-android` Maven artifact (AAR + POM + sources jar). Distributed via JitPack as `com.github.paritytech.truapi:truapi-host:<tag>`.
+- [`ios/truapi-host/`](ios/truapi-host) is a Swift Package consumed via `.package(url:)` or `.package(path:)`.
+
+The nested layout leaves room for additional packages alongside (e.g. `android/widgets/`, `ios/something-else/`) without re-shaping the top-level directories.
+
+Both link the `truapi-server` cdylib via UniFFI-generated bindings. The bindings are regenerated from the same Rust source via `make uniffi`.
+
 ## How it works
 
 1. The protocol is defined as Rust traits in [`rust/crates/truapi/`](rust/crates/truapi/), with each method tagged `#[wire(id = N)]` for a stable byte-level dispatch table. Every method's doc comment must carry a ` ```ts ` example, which codegen extracts into the playground's EXAMPLE tab; the build fails if any method is missing one.
@@ -80,9 +113,11 @@ Common tasks are wrapped in the top-level `Makefile`. Run `make help` for the fu
 
 ```bash
 make setup    # submodules + JS dependencies
-make build    # Rust workspace + TypeScript client
-make test     # Rust + TypeScript client tests
+make build    # Rust workspace + TypeScript client + @parity/truapi-host-* packages
+make test     # Rust + TypeScript client + @parity/truapi-host-* tests
 make check    # full suite: build, fmt, clippy, test, TS tests, playground build + lint
+make wasm     # rebuild truapi-server WASM artifacts under js/packages/truapi-host-wasm/dist/wasm/
+make uniffi   # regenerate UniFFI Kotlin + Swift bindings under android/truapi-host/ and ios/truapi-host/
 ```
 
 To run the playground locally:
@@ -129,4 +164,3 @@ See [`CONTRIBUTING.md`](CONTRIBUTING.md) for issue reports, feature proposals, a
 ## License
 
 [MIT](./LICENSE)
-
diff --git a/docs/design/dotli-architecture-change.md b/docs/design/dotli-architecture-change.md
new file mode 100644
index 00000000..9a58f4d8
--- /dev/null
+++ b/docs/design/dotli-architecture-change.md
@@ -0,0 +1,300 @@
+# Dotli architecture change, visual reference
+
+Companion to [dotli-rust-core-proposal.md](./dotli-rust-core-proposal.md). Shown as diagrams plus a deep dive on how the host-callback surface maps to the shared-core SDK vision.
+
+The point of these diagrams: justify what is **in scope** for the dotli migration diff and what is explicitly **deferred**. The migration replaces the novasamatech/host-api stack with the TrUAPI Rust core; nothing else.
+
+---
+
+## 1. Where protocol logic lives (the headline change)
+
+```
+                       BEFORE (origin/main)
+   ┌─────────────────────────────────────────────────────────────┐
+   │ Product iframe (sandbox)                                    │
+   │   @novasamatech/host-papp ─── product client                │
+   └──────────────────────┬──────────────────────────────────────┘
+                          │  postMessage (host-container wire)
+                          ▼
+   ┌─────────────────────────────────────────────────────────────┐
+   │ dot.li main thread                                          │
+   │ ┌─────────────────────────────────────────────────────────┐ │
+   │ │ container.ts  +  statement-store-mapping.ts             │ │
+   │ │ ─────────────────────────────────────────────────────── │ │
+   │ │  routing • codecs • subscriptions • permissions service │ │
+   │ │  topic encoding • statement mapping • dotns parsing     │ │
+   │ │  rate limiting • feature flags • etc.                   │ │
+   │ │            ALL OF THIS IS RE-IMPLEMENTED                │ │
+   │ │            ON iOS / Android / Electron TOO              │ │
+   │ └────────────────────────────┬────────────────────────────┘ │
+   │                              │                              │
+   │             OS primitives  (modals, localStorage,           │
+   │             smoldot, host-papp, fetch, Notification API)    │
+   └─────────────────────────────────────────────────────────────┘
+
+
+                       AFTER (this refactor)
+   ┌─────────────────────────────────────────────────────────────┐
+   │ Product iframe ── origin: <cid>.app.dot.li ── (per-CID)     │
+   │   @parity/truapi (codegen) ─── product client               │
+   └──────────────────────┬──────────────────────────────────────┘
+                          │  MessageChannel (TrUAPI wire bytes)
+                          │  port handed off via the host shell
+                          │  during the `truapi-init` handshake
+                          ▼
+   ┌─────────────────────────────────────────────────────────────┐
+   │ Host shell ── origin: dot.li ── (user-visible UI)           │
+   │ - top bar, modal prompts                                    │
+   │ - creates the protocol iframe + product iframe              │
+   │ - relays MessagePorts between them (no protocol logic)      │
+   └──────────────────────┬──────────────────────────────────────┘
+                          │  MessageChannel port (transferred)
+                          ▼
+   ┌─────────────────────────────────────────────────────────────┐
+   │ Protocol iframe ── origin: host.dot.li ── (STABLE origin)   │
+   │ (hidden iframe embedded by every dot.li tab)                │
+   │                                                             │
+   │  thin JS shim:                                              │
+   │  - constructs the SharedWorker below                        │
+   │  - exposes platform callbacks the WASM core can't make      │
+   │    directly from a worker (modal UI prompts are routed      │
+   │    back through the host shell at dot.li)                   │
+   │  - migrates legacy localStorage sessions into IndexedDB     │
+   │                                                             │
+   │           ┌────────── SharedWorker (host.dot.li) ─────────┐ │
+   │           │                                               │ │
+   │           │  truapi-server (Rust → WASM)                  │ │
+   │           │  ──────────────────────────                   │ │
+   │           │  routing • SCALE codecs • subscriptions       │ │
+   │           │  permissions service                          │ │
+   │           │  statement mapping                            │ │
+   │           │  dotns parsing • rate limit                   │ │
+   │           │  embedded smoldot ── chain provider           │ │
+   │           │  session state                                │ │
+   │           │                                               │ │
+   │           │  storage: IndexedDB on host.dot.li            │ │
+   │           │  (stable across product CID changes; shared   │ │
+   │           │   across every tab via SharedWorker semantics)│ │
+   │           └───────────────────────────────────────────────┘ │
+   └─────────────────────────────────────────────────────────────┘
+
+   Same logic, written once in Rust, shared across iOS / Android / web.
+```
+
+### Origin model, why host.dot.li
+
+Production nginx routes (see `dotli/nginx/nginx.polkadot`):
+
+| Hostname                  | Build       | Role                                                              |
+|---------------------------|-------------|-------------------------------------------------------------------|
+| `dot.li` and `*.dot.li`   | host        | Main shell, user-visible UI, top bar, dApp loader               |
+| `<cid>.app.dot.li`        | sandbox     | Product iframes, origin changes every CID update                |
+| `host.dot.li`             | protocol    | Stable-origin protocol iframe, hidden, embedded by every tab    |
+
+Product iframes can't host the protocol core: their origin changes with every app CID, so any `localStorage` / IndexedDB / OPFS state would be lost on every update. The host shell at `dot.li` is stable but cohabits with user-facing UI; running heavy crypto + smoldot there would block paint frames.
+
+The protocol iframe at `host.dot.li` has neither problem: it's a stable origin and it has no UI, so a same-origin worker constructed from it runs the WASM core off the main thread while keeping `truapi`'s persistent state on a stable origin.
+
+> The shipped `@parity/truapi-host-wasm/worker-runtime` entrypoint is a plain per-tab dedicated Web Worker. The `SharedWorker` topology drawn in these diagrams is the recommended target (see Option 2 in the companion proposal), not yet implemented. Read every `SharedWorker` mention below as the future shape.
+
+`SharedWorker` semantics give two further wins:
+
+- **One core per browser, not per tab.** Session state, permission grants, and chain connections are implicit cross-tab state. Replaces the existing `BroadcastChannel` glue for shared auth.
+- **Embedded smoldot.** Since the SharedWorker is already the single per-origin core, smoldot lives inside it. Dotli's separate `protocol-shared-worker.ts` smoldot SharedWorker collapses into this one.
+
+`SharedWorker` does not expose `localStorage` (main-thread only). The `truapi-platform::Storage` impl persists to **IndexedDB** on the `host.dot.li` origin. The thin JS shim in the protocol iframe runs a one-time migration of the existing `PAPP_${siteId}_*` localStorage keys into IDB so sessions survive the cutover.
+
+---
+
+## 2. Module-level diff in `@dotli/ui`
+
+```
+   ──── DELETED ────                ──── NEW ─────────────────────────
+
+   container.ts            930 LOC  host-callbacks/
+   statement-store-mapping  170 LOC    ├─ Account.ts          host-papp
+                                       ├─ Chain.ts            smoldot/RPC
+                                       ├─ LocalStorage.ts     localStorage
+   ──── DEPS DROPPED ───               ├─ OpenUrl.ts          window.open
+                                       ├─ Preimage.ts         Helia (IPFS)
+   @novasamatech/host-api              ├─ PromptPermission.ts modal
+   @novasamatech/host-container        ├─ PushNotification.ts Notification
+   @novasamatech/sdk-statement         ├─ Signing.ts          host-papp
+   @novasamatech/statement-store       ├─ StatementStore.ts   sub-store
+                                       └─ handlers.ts         glue
+
+   ──── DEPS ADDED ────
+
+   @parity/truapi-host-wasm        SharedWorker entrypoint that imports
+                                   the WASM core (smoldot embedded)
+   @parity/truapi-host-wasm/web    protocol-iframe shim: constructs the
+                                   SharedWorker, exposes the platform
+                                   callbacks the worker can't make from
+                                   its own context (modal UI, etc.),
+                                   relays MessagePort handoffs from the
+                                   host shell at dot.li
+   @parity/truapi                  types from codegen
+
+   ──── KEPT ──────────
+
+   bridge.ts                rewritten: ~80 LOC, was ~120 LOC
+   permissions.ts           kept (per-dApp grant storage)
+   permission-modal.ts      kept (UI primitive)
+   render.ts                kept (no-op for non-iframe content)
+   topbar.ts                kept (UI)
+   @novasamatech/host-papp  kept (account/signing; retired in D1)
+```
+
+---
+
+## 3. The shrinking host-callback surface
+
+```
+                 BEFORE                            AFTER
+              (15+ handlers,                  (6 host-facing
+               JS owns the logic)              capability traits
+                                                the core can't
+                                                make itself)
+
+  ┌──────────────────────────┐         ┌──────────────────────────┐
+  │ accountGet               │ ──────► │ accountGet      (D1*)    │
+  │ accountGetAlias          │ ──────► │ accountGetAlias (D1*)    │
+  │ getNonProductAccounts    │ ──────► │ getNonProduct…  (D1*)    │
+  │ getUserId                │ ──────► │ getUserId       (D1*)    │
+  │ accountConnectionStatus… │ ──────► │ accountConn…    (D1*)    │
+  │ signPayload              │ ──────► │ signPayload     (D1*)    │
+  │ signRaw                  │ ──────► │ signRaw         (D1*)    │
+  │ statementStoreSubmit     │ ──────► │ statementStore… (D2*)    │
+  │ statementStoreSubscribe  │ ──────► │ statementStore… (D2*)    │
+  │ statementStoreCreateProof│ ──────► │ statementStore… (D2*)    │
+  │ preimageLookupSubscribe  │ ──────► │ preimageLookup… (D2*)    │
+  │                          │         ├──────────────────────────┤
+  │ devicePermission ────────┼─────►   │ devicePermission         │
+  │ remotePermission ────────┼─────►   │ remotePermission         │
+  │ navigateTo (parsing) ────┼─────►   │ navigateTo (parsed core) │
+  │ featureSupported         │ ──────► │ featureSupported         │
+  │ localStorage*            │ ──────► │ Storage read/write/clear │
+  │ pushNotification         │ ──────► │ pushNotification         │
+  │ chainConnection          │ ──────► │ chainConnect    (E1*)    │
+  │ themeSubscribe (#366)    │ ──X     │ (out of scope)           │
+  └──────────────────────────┘         └──────────────────────────┘
+
+   * (D1/D2/E1) = host-papp, libp2p, layer-2 retirement issues already
+                  documented in tracking issues, NOT this PR.
+   The AFTER column names match the `truapi-platform` traits as shipped:
+   `Permissions` keeps the two-call device/remote split per v0.1,
+   `Navigation` receives URLs already parsed by the core, `Features`,
+   `Storage`, `Notifications`, and `ChainProvider` cover the rest.
+```
+
+---
+
+## 4. Mapping host callbacks to `truapi-platform` traits
+
+Every row in the middle block of diagram §3 is one piece of "logic that used to live in JS, now lives in Rust." Each maps to one of the **capability traits** the host implements in `truapi-platform` (`Storage`, `Navigation`, `Notifications`, `Permissions`, `Features`, `ChainProvider`); everything else gets pulled out of the host into the core. Where a section below describes a single consolidated prompt or a different trait vocabulary, it is calling out a **proposed future shape**, not the shipped surface; the shipped names are the six above.
+
+### 4.1 `devicePermission` + `remotePermission` (shipped split; consolidation proposed)
+
+**Before, host did the policy work.** Two separate callbacks:
+
+- `devicePermission(name)`, for browser-mediated permissions (camera, mic, geolocation, push). The JS host:
+  1. Maintained the per-dApp grant cache in `localStorage`.
+  2. Classified which device permissions were even *enforceable* in a browser iframe (notifications and `openUrl` are not really gateable from a sandboxed iframe; mic and camera are).
+  3. Showed the consent modal, persisted the result, dispatched a "permission changed" event so the iframe could reload with the updated `allow` attribute.
+- `remotePermission(req)`, for protocol-level permissions (`TransactionSubmit`, `StatementSubmit`, `ChainSubmit`, `WebRtc`, a wildcard `Remote` variant). The JS host:
+  1. Mapped `TransactionSubmit` → user-friendly "Sign Transactions" label.
+  2. Decided which `Remote` variants were gated vs. auto-granted.
+  3. Showed a different modal flow (the now-deleted `showRemotePermissionModal`).
+  4. Rate-limited.
+
+That is policy: classification, mapping, caching, rate limiting. By the test "why can't the Rust core do this directly?", none of it is a syscall.
+
+**Shipped today: the `Permissions` trait keeps the two-call split.** Per v0.1, `truapi-platform::Permissions` has `device_permission(HostDevicePermissionRequest)` and `remote_permission(RemotePermissionRequest)`, mirrored by the dotli adapter and the iOS/Android bridges. The host renders one modal flow per call and returns the response.
+
+**Proposed future shape: collapse both into one prompt.** A single host trait of the form `prompt_permission(HostPermission) -> bool` would let the Rust permissions service in core:
+
+- Know the canonical wire tags and their human labels.
+- Check the cached decision (via `Storage::read`) before calling back.
+- Decide whether the permission is enforceable; auto-grant the unenforceable ones without bothering the host.
+- Rate-limit.
+- Only when *the user must actually be asked*, dispatch the prompt and wait for the boolean.
+
+In dotli that consolidated callback would be a single `host-callbacks/PromptPermission.ts` whose sole job is to render the modal and return `true` on grant, `false` on deny, with the same trait implemented by Swift on iOS and Kotlin on Android. None of them would re-implement the cache, the rate limiter, or the wire-tag mapping. This consolidation is not yet in core; it is the direction this section argues for.
+
+The dotli adapter references `getPermissionStatus` / `setPermissionStatus` against a local `permissions.ts` store. Once the grant cache moves into the core's `Storage`, `permissions.ts` can disappear from the dotli tree entirely.
+
+### 4.2 `navigateTo (parsing)` → `Navigation::navigate_to (already parsed)`
+
+**Before, host was a URL parser.** `navigateTo(url)` handed a raw string to the host. JS had to:
+
+1. Detect a `.dot` deep link (`testingout.dot/some/path`) → drive the dotli internal router (DOTNS resolution, swap iframe contents, push history state).
+2. Detect a normal `https://` URL → `window.open(url, "_blank")`.
+3. Detect malformed input → reject.
+
+That is a parser plus a deep-link dispatcher. Three platforms, three parsers, three places to drift.
+
+**After, host owns one trait: "hand this URL to the OS browser."** Two distinct surfaces split in the core:
+
+- Internal routing (deep links to other `.dot` apps) is handled entirely inside the core. It dispatches itself, no host roundtrip.
+- External navigation surfaces as `Navigation::navigate_to(url)`, and `url` is *already validated* by the core. The host treats it as opaque.
+
+In dotli, this is the host's `Navigation` impl, which is essentially `window.open(url, "_blank")`. The shipped `truapi-platform::Navigation` trait has the single `navigate_to` method; there is no separate deep-link callback because the core already knows the dApp graph and dispatches deep links directly.
+
+### 4.3 `featureSupported` (kept; planned for removal)
+
+`featureSupported(genesisHash)` lets the core ask "does this host know about this chain?" before letting a product call it. The host answers yes/no from its supported-chain catalog.
+
+The plan, tracked separately, is to drop this callback. The Rust core will bundle the chain catalog itself, so there is no question for the host to answer. That fits the "why can't the Rust core do this directly?" test, the answer for `featureSupported` is "it can," so the callback should not exist.
+
+### 4.4 `localStorage*` → `Storage::read` / `Storage::write` / `Storage::clear`
+
+**Before, implicit, scattered.** The novasamatech protocol had several scoped storage callbacks (one per dApp namespace), and the JS host computed prefixes (`dotli:<label>:<key>`), guarded against quota errors, and decided what counted as "scoped" vs. "global" state. The core did not own a storage abstraction; it asked the host for what it needed and trusted the host's scoping.
+
+**After, three flat ops, no scoping in the host.** The shipped `truapi-platform::Storage` trait:
+
+```rust
+pub trait Storage: Send + Sync {
+    fn read(&self, key: String)
+        -> impl Future<Output = Result<Option<Vec<u8>>, HostLocalStorageReadError>> + Send;
+    fn write(&self, key: String, value: Vec<u8>)
+        -> impl Future<Output = Result<(), HostLocalStorageReadError>> + Send;
+    fn clear(&self, key: String)
+        -> impl Future<Output = Result<(), HostLocalStorageReadError>> + Send;
+}
+```
+
+Three methods. The core:
+
+- Owns the namespacing convention (`truapi:…` for core-owned state, per-dApp prefixes computed in core before calling back).
+- Owns the cache invalidation rules.
+- Owns the schema for any structured value stored.
+
+The host, `host-callbacks/LocalStorage.ts` in dotli, just plumbs to `window.localStorage.getItem` / `setItem` / `removeItem`. On iOS that is `NSUserDefaults`. On Android `SharedPreferences`. None of those hosts cares what the keys mean; they just store bytes against strings.
+
+This is also what makes the permission-cache cleanup in §4.1 tractable: once permissions migrate fully to `Storage::read`/`Storage::write`, the dotli adapter loses `permissions.ts` entirely and the core owns the grant cache the way it owns every other piece of state.
+
+---
+
+## 5. Mapping dotli `host-callbacks/` to `truapi-platform` traits
+
+Each `host-callbacks/*.ts` file in dotli implements one capability trait:
+
+| dotli file              | `truapi-platform` trait | core owns                           | host owns              |
+|-------------------------|-------------------------|-------------------------------------|------------------------|
+| `LocalStorage.ts`       | `Storage`               | namespacing, schema, invalidation   | `window.localStorage`  |
+| `OpenUrl.ts`            | `Navigation`            | URL parsing, deep-link dispatch     | `window.open`          |
+| `PushNotification.ts`   | `Notifications`         | rate limiting, dedupe, payload fmt  | `Notification` API     |
+| `PromptPermission.ts`   | `Permissions`           | classification, cache, mapping      | the consent modal(s)   |
+| `Chain.ts`              | `ChainProvider`         | chainHead state machine, RPC fan-in | smoldot / RPC socket   |
+
+`Permissions` is shipped as the two-call device/remote split (§4.1); `Features` (`featureSupported`) is the sixth host-facing trait and is planned for removal (§4.3). The "before" column for each row was a handler in `container.ts` that mixed all three concerns, protocol logic, policy, *and* the OS call, in JS. The refactor's whole purpose is to leave only the third column on the host side, and that is what makes iOS/Android able to share the rest with web.
+
+The remaining dotli callbacks (`Account.ts`, `Signing.ts`, `StatementStore.ts`, `Preimage.ts`) are the ones marked `(D1*)`, `(D2*)` in diagram §3. They are not part of the `truapi-platform` trait set: account, signing, statement-store and preimage flows live in the Rust core itself, and these callbacks currently rely on JS-only libraries (`host-papp` for accounts/signing, sub-store, Helia). Each retirement issue describes how the underlying capability moves into Rust so the dotli callback can be dropped, leaving only the host-facing capability traits above.
+
+---
+
+## 6. What this justifies about the migration diff
+
+- **In scope:** anything between BEFORE and AFTER in §1 and §2 (delete `container.ts` / `statement-store-mapping.ts`, add `host-callbacks/`, swap `bridge.ts`, swap deps).
+- **Out of scope, deferred to issues:** anything marked `(D1*)` / `(D2*)` / `(E1*)` in §3.
+- **Out of scope and not coming back:** `themeSubscribe`, `requestLogin(reason, label)`, the remote-permission modal, these are #366 features that targeted the deleted `container.ts` and would need to be re-modeled as new Rust traits, not patched into the syscall layer.
diff --git a/docs/design/dotli-rust-core-proposal.md b/docs/design/dotli-rust-core-proposal.md
new file mode 100644
index 00000000..10868ad3
--- /dev/null
+++ b/docs/design/dotli-rust-core-proposal.md
@@ -0,0 +1,284 @@
+# dot.li with a single Rust core, proposed architectures
+
+Companion to [dotli-architecture-change.md](./dotli-architecture-change.md). This doc documents what dot.li runs today (host page + protocol iframe at `host.dot.li` + per-CID app subdomain iframe + product iframe) and explores how the topology changes if we adopt a single Rust core as the runtime, and what it would take to drop the per-CID app subdomain iframe.
+
+## Goal
+
+The current dot.li architecture predates TrUAPI's "Rust core is the application" stance. It carries a four-frame topology that grew out of layer-2 isolation requirements, content-delivery sandboxing, and JS-side smoldot ownership. Each frame carries weight: a vite bundle, a wildcard DNS record, an OOPIF process, and at least one postMessage hop on every host-API call.
+
+If the Rust core owns *all* protocol logic, chain access (smoldot + RPC), DOTNS resolution, content fetching from IPFS, per-product storage, permission gating, most of what the app subdomain iframe gives us either becomes redundant or moves into the core. This doc explores what that endpoint looks like.
+
+The two specific questions this doc answers:
+
+1. Can we eliminate the app subdomain iframe (`<cid>.app.dot.li`)?
+2. Can the Rust core load directly in the protocol iframe (`host.dot.li`) instead of in a Web Worker spawned by the host page?
+
+## What the app subdomain iframe gives us today
+
+Two things, doing each well:
+
+1. **Origin isolation per dApp.** Each `.dot` product gets a unique DNS subdomain `<cid>.app.dot.li`. The browser scopes localStorage, IndexedDB, cookies, service workers, and the iframe's Permissions Policy storage to that origin. Product A cannot read Product B's storage even when they're loaded in adjacent iframes of the same dot.li tab.
+
+2. **Content fetching + sandboxed mount.** `apps/sandbox` reads the CID from its own subdomain, fetches the archive over P2P/Helia, decrypts, packs into a `Blob`, and mounts the product iframe at `blob:https://<cid>.app.dot.li/...`. The blob URL inherits the sandbox's origin, so the product iframe is same-origin with the sandbox, isolated from everything else.
+
+Removing the app subdomain iframe means losing both. So: how much of (1) and (2) do we still need in a Rust-core-centric world, and where does the rest go?
+
+## What origin isolation actually buys, and what replaces it
+
+Per-product origin separation today gives products:
+
+| What | Today | If core owns it |
+|---|---|---|
+| `localStorage` per product | scoped by `<cid>.app.dot.li` origin | core's `host_local_storage_*` syscalls, namespaced by product label |
+| IndexedDB per product | per-origin DB | core's KV (extends `Storage` trait if needed) |
+| Cookies per product | per-origin | products don't use cookies in the TrUAPI model |
+| Service Worker per product | per-origin SW registration | products are static content; SW is replaced by core-side caching |
+| Cache API per product | per-origin Cache | core fetches and caches |
+| Permissions Policy | per-origin `allow=…` attribute | iframe gets a generic `allow` attribute set by the host; core's `prompt_permission` is the actual gate |
+| `postMessage` security | products can address each other only via `targetOrigin` | products can't address each other at all (no shared parent) |
+| Cross-product storage leak | impossible (different origins) | impossible if products are forced through the core (see below) |
+
+The pivot: in the Rust-core model, **origin separation isn't the security boundary anymore, the core is**. The browser-level origin still has to be *something* (every iframe has an origin), but it can be the same for every product as long as products can't bypass the core's API for storage, fetch, permissions, etc.
+
+The mechanism for "products can't bypass the core's API" is the iframe `sandbox` attribute *without* `allow-same-origin`, which gives the iframe an **opaque origin**. Calls to `localStorage`, `indexedDB`, `Cache`, `serviceWorker.register`, etc. all throw or no-op on opaque origins. Network `fetch` still works (subject to CSP), but if we tighten CSP via the iframe's `csp` attribute we can restrict that too.
+
+So the trade is: drop per-CID DNS subdomains, accept opaque origin for products, route all persistence and (where needed) fetch through the core.
+
+This matches the shared-core model in the companion architecture doc. It's also the only way to keep the architecture meaningful on native (iOS/Android), where DNS subdomains aren't a thing, products there already go through the core for everything.
+
+## Content delivery without `<cid>.app.dot.li`
+
+If the app subdomain iframe goes away, who fetches and unpacks the dApp archive, and how does it become an iframe?
+
+Three viable options:
+
+### Delivery option A, Service Worker on `host.dot.li`
+
+Register a service worker on `host.dot.li` that intercepts fetch requests matching a path scheme, e.g. `/__product/<cid>/*`. The product iframe is mounted with `src="https://host.dot.li/__product/<cid>/index.html"`. The SW intercepts, asks the Rust core for the file, returns it.
+
+Origin of the product iframe: `https://host.dot.li`. To prevent cross-product leakage on shared storage, also set `sandbox` without `allow-same-origin` → opaque origin → storage APIs no-op.
+
+Pros:
+- Product loads via a normal `src` URL; existing dApp tooling that expects a "real" load works.
+- The SW gives us a uniform fetch interception layer, including for nested resources the dApp loads (CSS, sub-pages, images).
+- Service Worker is broadly supported (yes Safari).
+
+Cons:
+- Service worker registration is per-origin and async; must be resolved before any product iframe loads.
+- Range requests, streaming, Content-Type sniffing all have to be handled by the SW.
+- The SW becomes a long-lived dependency on the host.dot.li origin; updates must be carefully coordinated.
+
+### Delivery option B, Blob URL from the protocol iframe
+
+The protocol iframe at `host.dot.li` runs the Rust core, which fetches the archive. JS in that iframe creates a `Blob` from the unpacked HTML and assigns the blob URL to the product iframe's `src`. Origin of the blob URL = `host.dot.li`.
+
+Pros:
+- No service worker. Simpler bootstrap.
+- Blob URLs work everywhere.
+
+Cons:
+- Sub-resources (CSS, JS, images) loaded by relative URL inside the dApp resolve against the blob's URL, which is opaque. Either the dApp must inline everything (works for a static SPA bundle) or we add another mechanism for sub-resources.
+- For dApps with non-trivial asset trees, this breaks down.
+
+### Delivery option C, Service Worker on the product iframe's origin
+
+Mount the product iframe at a URL on `host.dot.li`, register a service worker scoped to that path, let the SW handle content. Functionally the same as option A; differs only in scoping (per-product vs shared).
+
+Trade-off: per-product SWs cost more (registration overhead, browser-quota implications) but contain failures.
+
+**Recommended**: option A (single SW on host.dot.li) for non-trivial dApps; option B as a fast path for archive-of-one-HTML-file products. The two can coexist, the host shell picks based on archive shape.
+
+## Architecture options
+
+Four placements for the Rust core, in increasing ambition. All four eliminate `<cid>.app.dot.li` and use opaque-origin product iframes via `sandbox` without `allow-same-origin`.
+
+### Option 1, Rust core in the protocol iframe (per-tab)
+
+The core lives inside a Web Worker spawned by the protocol iframe at `host.dot.li`. Product iframes are mounted as children of the protocol iframe (the protocol iframe becomes the visible surface; the host page renders the topbar via overlay or via a small wrapper layout above the iframe).
+
+```
+┌─ tab @ dot.li ──────────────────────────────────────────────────────────┐
+│  apps/host, topbar + label parsing (thin shell)                        │
+│                                                                         │
+│  ┌─ protocol iframe @ host.dot.li (visible, full-bleed) ────────────┐   │
+│  │  apps/protocol, orchestrates Rust core + product mount          │   │
+│  │  ┌─ Web Worker (host.dot.li) ─ Rust core ─────────────────────┐  │   │
+│  │  │  smoldot · DOTNS · content fetch · per-product storage     │  │   │
+│  │  │  permission gate · all host-API methods                    │  │   │
+│  │  └────────────────────────────────────────────────────────────┘  │   │
+│  │                                                                  │   │
+│  │  ┌─ product iframe (opaque origin via sandbox) ──────────────┐   │   │
+│  │  │  src = "host.dot.li/__product/<cid>/..." (SW intercepts)  │   │   │
+│  │  │  ↕ MessageChannel ↔ Web Worker (Rust core)                │   │   │
+│  │  └───────────────────────────────────────────────────────────┘   │   │
+│  └──────────────────────────────────────────────────────────────────┘   │
+└─────────────────────────────────────────────────────────────────────────┘
+```
+
+**Trade-offs:**
+
+- One Rust core per tab. Smoldot runs once per tab.
+- All chain state (smoldot warm-start IndexedDB, persisted permissions, content cache) lives on `host.dot.li`, isolated from `dot.li`'s storage.
+- Product iframe parents the protocol iframe → direct postMessage / MessageChannel; host page is not in the message path.
+- Layout: protocol iframe is positioned full-viewport with the host page rendering only the topbar above (z-indexed or via a flex layout where the topbar is in the host page DOM and the iframe occupies the content area).
+- N concurrent tabs = N Rust cores = N smoldots. Same drawback as documented in the E2 chain-provider unification work.
+
+### Option 2, Rust core in a SharedWorker (cross-tab)
+
+Move the Rust core into a `SharedWorker` scoped to `host.dot.li`. The protocol iframe in each tab becomes a thin relay that connects to the SharedWorker via `MessagePort` and forwards product → core traffic.
+
+```
+┌─ tab A @ dot.li ───────────────┐    ┌─ tab B @ dot.li ───────────────┐
+│  apps/host, topbar            │    │  apps/host, topbar            │
+│  ┌─ protocol iframe ─────────┐ │    │  ┌─ protocol iframe ─────────┐ │
+│  │ (host.dot.li, thin relay) │ │    │  │ (host.dot.li, thin relay) │ │
+│  │ ┌─ product iframe ──────┐ │ │    │  │ ┌─ product iframe ──────┐ │ │
+│  │ │ opaque origin         │ │ │    │  │ │ opaque origin         │ │ │
+│  │ └───────────────────────┘ │ │    │  │ └───────────────────────┘ │ │
+│  └──────┬────────────────────┘ │    │  └──────┬────────────────────┘ │
+└─────────┼──────────────────────┘    └─────────┼──────────────────────┘
+          │                                     │
+          └──────────────┬──────────────────────┘  MessagePort
+                         ▼
+┌─ SharedWorker @ host.dot.li ──────────────────────────────────────────┐
+│  Rust core: smoldot · DOTNS · content fetch · per-product storage     │
+│             permission gate · all host-API methods                    │
+└───────────────────────────────────────────────────────────────────────┘
+```
+
+**Trade-offs:**
+
+- One Rust core per origin (across all tabs). Smoldot syncs once for the user, not once per tab.
+- Cross-tab session sync becomes a feature for free (same core sees all products on all tabs).
+- Shared content cache, shared chain warm-start.
+- The lifetime of the SharedWorker is "while at least one same-origin context is open", when all dot.li tabs close, the core terminates. Chain warm-start state must live in IndexedDB to survive.
+- **Browser support:** SharedWorker is now broadly available, Chrome, Firefox, Safari macOS, and Safari iOS 16.0+ all support it. The remaining caveat is iOS-specific lifecycle: iOS aggressively suspends backgrounded tabs, and a SharedWorker with no visible client is a candidate for termination. The amortization benefit ("one smoldot for the whole session") still holds while the user has at least one foreground tab; when all tabs are backgrounded the worker may die and re-sync on resume. This isn't worse than per-tab Workers (which die with their tab on iOS too), but the cross-tab payoff is smaller on iOS than on desktop.
+
+### Option 3, Rust core in a Web Worker on the host page (`dot.li`)
+
+Skip the protocol iframe entirely. The host page at `dot.li` directly spawns a Web Worker containing the Rust core. Product iframes are children of the host page.
+
+```
+┌─ tab @ dot.li ──────────────────────────────────────────────────────────┐
+│  apps/host, topbar + Rust core orchestration                           │
+│                                                                         │
+│  ┌─ Web Worker (dot.li) ─ Rust core ──────────────────────────────────┐ │
+│  │  smoldot · DOTNS · content fetch · per-product storage             │ │
+│  │  permission gate · all host-API methods                            │ │
+│  └────────────────────────────────────────────────────────────────────┘ │
+│                                                                         │
+│  ┌─ product iframe (opaque origin via sandbox) ──────────────────────┐  │
+│  │  src = "dot.li/__product/<cid>/..." (SW intercepts)               │  │
+│  │  ↕ MessageChannel ↔ Web Worker (Rust core)                        │  │
+│  └───────────────────────────────────────────────────────────────────┘  │
+└─────────────────────────────────────────────────────────────────────────┘
+```
+
+**Trade-offs:**
+
+- Simplest. One frame, one origin, one worker.
+- Smoldot's chain-state IndexedDB and WebSocket connections live on the user-visible `dot.li` origin. Slight UX wart (DevTools shows weird WSs on the user-visible domain) and a hosting concern (CDN behavior on `dot.li` storage).
+- Cross-tab: per-tab core unless we promote the worker to a SharedWorker on `dot.li`.
+- Removes the host.dot.li origin entirely from the topology. Simplifies DNS / nginx; removes a vite build.
+- Topbar UI and chain state share an origin → topbar JS could (in principle) read the core's state directly without going through postMessage. Convenient but blurs the API/UI separation.
+
+### Option 4, Hybrid: per-tab Rust core, chain core in SharedWorker
+
+Two cores. The per-tab Rust core handles product-specific work (account, signing, storage, permissions, content). It connects to a separate SharedWorker that owns *only* chain access (smoldot/RPC) and DOTNS resolution.
+
+```
+┌─ tab A @ dot.li ──────────────────────────┐
+│  ┌─ protocol iframe @ host.dot.li ──────┐ │
+│  │  ┌─ Web Worker, per-tab Rust core ┐ │ │     ┌─ SharedWorker @ host.dot.li ─┐
+│  │  │  account · signing · storage     │ │ │     │  Rust core (chain only):     │
+│  │  │  permissions · content delivery  │ │ │     │   • smoldot                  │
+│  │  │  remote_chain_* ─ port ──────────┼─┼─┼────▶│   • DOTNS resolver           │
+│  │  └──────────────────────────────────┘ │ │     │   • content fetch (IPFS)     │
+│  │  ┌─ product iframe ─────────────────┐ │ │     └──────────────────────────────┘
+│  │  │ opaque origin                    │ │ │             ▲
+│  │  └──────────────────────────────────┘ │ │             │ same SW from
+│  └───────────────────────────────────────┘ │             │ other tabs
+└────────────────────────────────────────────┘             │
+┌─ tab B @ dot.li ──────────────────────────┐              │
+│  (same shape) ────────────────────────────┼──────────────┘
+└────────────────────────────────────────────┘
+```
+
+**Trade-offs:**
+
+- Best-of-both-worlds: chain expense shared across tabs (the heavy thing), per-product state isolated per-tab (the light thing).
+- Two Rust cores compiled and shipped, but they can share the same source crate with feature flags ("chain-only" vs "products"). Bundle size goes up but not by much; chain core has most of the LOC anyway.
+- Two postMessage hops for chain methods (product → per-tab core → shared core). Throughput is fine; latency is two `postMessage` (~0.1ms each on modern browsers).
+- Lifetime: SharedWorker survives across tab closes; per-tab core dies with the tab.
+- iOS lifecycle: as in Option 2, the SharedWorker's amortization benefit shrinks when all tabs are backgrounded (iOS may suspend it). No special fallback needed, the per-tab core handles its own work either way.
+- Most complex of the four. Justified only if Option 1's per-tab smoldot cost is measured to be a real problem.
+
+## Comparison
+
+| Axis | Option 1 (per-tab core in protocol iframe) | Option 2 (SharedWorker core on host.dot.li) | Option 3 (per-tab core on dot.li) | Option 4 (hybrid) |
+|---|---|---|---|---|
+| Frames | host + protocol + product | host + protocol(thin) + product | host + product | host + protocol + product |
+| Rust cores per origin | 1 per tab | 1 across all tabs | 1 per tab | 1 per tab + 1 shared |
+| Smoldot instances | N (per tab) | 1 (across all tabs) | N (per tab) | 1 (across all tabs) |
+| host.dot.li used | yes (visible iframe) | yes (SW host) | no | yes (both) |
+| Cross-tab session/chain sync | manual (BroadcastChannel) | automatic (one core sees all tabs) | manual | automatic for chain, manual for session |
+| Safari iOS path | works as-is | works (16.0+); cross-tab benefit reduced when all tabs backgrounded | works | works (16.0+); same iOS caveat as Option 2 |
+| Complexity | low | medium | low | high |
+| Eliminates `*.app.dot.li` | yes | yes | yes | yes |
+| Eliminates `host.dot.li` | no | no | yes | no |
+
+## Recommendation
+
+**Land Option 2: the Rust core lives in a SharedWorker scoped to `host.dot.li`.** The protocol iframe in each tab becomes a thin shim that constructs the SharedWorker once per browser, exposes the small set of platform callbacks the worker can't make from its own context (modal UI prompts routed back via postMessage), and relays MessagePorts from the host shell at `dot.li` to the worker.
+
+> The shipped `@parity/truapi-host-wasm/worker-runtime` entrypoint is a plain per-tab dedicated Web Worker (Option 1's worker model). SharedWorker is the recommended target here but is not yet implemented.
+
+Reasons:
+
+1. **Stable origin for persistent state.** `host.dot.li` is the only origin in the topology that doesn't change with every CID update. `truapi-platform::Storage` lives in IndexedDB on that origin so granted permissions, session state, content caches, and chain warm-start data survive product upgrades.
+
+2. **One core per browser, not per tab.** SharedWorker semantics make session state, permission grants, and chain connections implicit cross-tab state. This replaces dotli's current `BroadcastChannel` glue for shared auth, and folds the existing standalone `protocol-shared-worker.ts` smoldot worker into the same process: smoldot is embedded inside `truapi-server`, not a parallel SharedWorker.
+
+3. **No protocol logic on the user-visible thread.** The host shell at `dot.li` renders the top bar and modals; it never decodes a TrUAPI frame. Heavy crypto + smoldot + libp2p stay off any paint-frame budget.
+
+4. **Falls back cleanly when SharedWorker isn't available.** Feature-detect (`typeof SharedWorker !== "undefined"`) and downgrade to a per-tab `Worker` (Option 1 behavior). The same `@parity/truapi-host-wasm/worker-runtime` entry point covers both, only the constructor differs. Safari 16+ ships SharedWorker, so the fallback is only for very old engines.
+
+5. **iOS lifecycle is acceptable.** iOS may suspend a SharedWorker when all tabs are backgrounded. The amortization benefit shrinks but isn't worse than a per-tab Worker (which also dies with its tab on iOS). Cross-tab payoff is still real on desktop and is a no-cost win when the browser keeps the worker alive.
+
+Options 1 (per-tab worker in protocol iframe), 3 (worker on the user-visible `dot.li` origin), and 4 (hybrid) remain in the comparison table for context; Option 2 supersedes them.
+
+## Migration considerations
+
+To get from today's topology to Option 2:
+
+1. **Ship `truapi-server` WASM as a SharedWorker entrypoint.** Today `@parity/truapi-host-wasm/worker-runtime` runs as a per-tab dedicated `Worker`; this step promotes the same entrypoint to `new SharedWorker(...)` from the protocol iframe at `host.dot.li`. Smoldot is embedded inside the WASM, so dotli's existing `apps/protocol/src/protocol-shared-worker.ts` retires in the same step.
+
+2. **Migrate auth-storage from localStorage to IndexedDB.** The current `apps/protocol/src/main.ts` shared-auth handler writes `PAPP_${siteId}_${key}` keys to `localStorage`. SharedWorkers have no `localStorage`; persistent state lives in IDB. The protocol-iframe shim runs a one-shot migration: enumerate `localStorage` for `PAPP_*` keys, write them into IDB, then clear localStorage. Cross-tab notifications switch from `BroadcastChannel` to the SharedWorker fan-out.
+
+3. **Move content fetching into the Rust core.** Today `apps/sandbox` does P2P/Helia in the product iframe. Port that to Rust (libp2p-in-WASM, or HTTP gateway behind a feature flag). Add `content_fetch(cid) → bytes` to the protocol surface.
+
+4. **Add a service worker on `host.dot.li`** that intercepts `/__product/<cid>/*` and serves from the core's content cache. Register at protocol-iframe boot.
+
+5. **Switch the product iframe to opaque origin.** Use `sandbox="allow-scripts allow-forms allow-pointer-lock allow-popups"` (no `allow-same-origin`). Verify products handle the storage no-op correctly, they should already, in the TrUAPI model.
+
+6. **Render the product iframe inside the protocol iframe.** The protocol iframe goes from `display: none` to full-viewport; the host page's topbar overlays it (or wraps via flex layout).
+
+7. **Retire `apps/sandbox` and `*.app.dot.li`.** Drop the vite build, the nginx wildcard route, and the DNS record.
+
+8. **DOTNS resolution moves into the core** (also covered by the layer-2 ownership work).
+
+Order: steps 1 and 2 are blocking, without IDB-backed storage and the SharedWorker entrypoint, the rest can't migrate. 3, 4 can land independently and behind feature flags. 5, 6 require previous steps in production. 7, 8 are parallel to 1.
+
+## What native (iOS / Android) keeps in mind
+
+Native dotli runs the Rust core in-process via UniFFI. There are no iframes; the product runs in a WebView. The architecture decisions above are web-specific. Native parity is mostly automatic, UniFFI generates Swift/Kotlin bindings for the same `Platform` trait, the WebView talks to the in-process core via a local-loopback transport. The thing native doesn't get for free is **per-tab vs cross-tab smoldot sharing**, that's not a concept on mobile (one app instance), so the question is moot. Native always behaves like "one core per app instance", same as Option 3 conceptually.
+
+## Open questions for the team
+
+1. **Content fetching in Rust-WASM.** Do we want libp2p/Helia in the Rust core, or do we keep an HTTP gateway path? libp2p in Rust-WASM is doable but adds significant binary size. HTTP gateway is simpler but adds a server dependency.
+
+2. **Service worker scope on `host.dot.li`.** A per-cid SW (option C in the delivery section) gives us tighter quota / failure isolation but more registrations. A single SW is simpler. Decide based on observed product behavior.
+
+3. **Topbar layout.** Today the topbar is host-page DOM. If the protocol iframe goes full-viewport, the topbar either (a) stays on the host page and z-indexes above the iframe, or (b) the topbar moves into the protocol iframe and the host page becomes a degenerate wrapper. Option (a) is simpler but means the topbar can't read core state directly (has to postMessage in). Option (b) collapses host page → protocol iframe but raises questions about deep linking and URL parsing.
+
+4. **Cross-product UX features.** If the user expects products to share auth (logged in once, all products see the session), that needs explicit support whether the core is per-tab or shared. Shared state via the core's KV; cross-tab sync via BroadcastChannel or SharedWorker. Decide before committing to per-tab vs shared.
diff --git a/docs/design/host-contract-and-core-impl/A - host-primitives.md b/docs/design/host-contract-and-core-impl/A - host-primitives.md
new file mode 100644
index 00000000..77d2eaf9
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/A - host-primitives.md	
@@ -0,0 +1,178 @@
+# A - Host primitives (`truapi-platform`)
+
+> Part of the [host-contract & core-impl spec](index.md).
+
+SSO pairing, transaction/raw signing, transaction construction, ring-VRF alias, and the product
+statement store all ride **one** mechanism: the People-chain statement store, reached through the
+**existing `ChainProvider`** trait, with the protocol run **in the core** ([H](<H - sso-pairing-protocol.md>)).
+That leaves exactly **one** genuinely new host primitive for the SSO protocol: a QR presenter.
+
+Replacing dotli's current `@novasamatech/host-container` bridge still requires a few host/platform
+surfaces for behavior that is already implemented in the current dotli checkout or required by the
+core-owned session model: scheduled notifications, theme subscription, preimage submit/lookup,
+resource-allocation confirmation UI, host-global session persistence, and static product identity. Those
+are not SSO protocol primitives, but they are part of current dotli feature parity or secure restore. For
+the trait conventions and the five-layer wiring recipe, see the [annex](<G - annex.md>).
+
+## A0. Delta from PR 104's platform surface
+
+PR 104 currently ships `truapi-platform` with:
+
+- `Storage`, `Navigation`, `Notifications`, `Permissions`, `Features`, `ChainProvider`, and
+  `JsonRpcConnection`;
+- no runtime product config object;
+- no SSO QR presenter;
+- no host-global `SessionStore`;
+- no theme/preimage/resource-allocation-confirmation traits;
+- a `Notifications` trait that can push but cannot return a notification id or cancel scheduled
+  notifications.
+
+This spec keeps `Storage`, `Navigation`, `Permissions`, `Features`, and `ChainProvider` as real host
+capabilities. It extends or adds only the host surfaces listed below. Account, signing, transaction
+construction, alias, statement-store submit/subscribe/proof, entropy, and logout are **not** host
+callbacks in the final architecture.
+
+## A0.1. Portability rules
+
+No method in `truapi-server` may depend on dotli-only APIs, package names, storage keys, browser globals,
+or UI components. dotli supplies those details through its adapter layer and `RuntimeConfig`; the Rust core
+sees only platform traits and opaque configuration values.
+
+The same host contract must be usable from:
+
+- **dotli web/Electron:** WASM worker runtime; QR, modals, notifications, preimage, theme, and
+  host-global `SessionStore` backed by web/Electron APIs.
+- **iOS/Android:** UniFFI/native runtime; the same QR/deeplink, session-store, notification, chain, and UI
+  confirmation capabilities implemented with native platform APIs.
+- **future hosts:** one new platform implementation plus product config. No forked SSO protocol, no
+  host-owned signing proxy, and no separate wallet connection.
+
+## A1. `PairingPresenter`: show the QR/deeplink **(S–M)**
+
+**What:** display the `polkadotapp://pair?handshake=<hex>` deeplink the core builds during
+`request_login`, as a QR (or open-url), and report user-initiated cancel. No protocol knowledge: it
+renders a string the core produced ([H §1](<H - sso-pairing-protocol.md>)).
+
+**Proposed trait** (lib.rs):
+
+```rust
+pub trait PairingPresenter: Send + Sync {
+    /// Show the pairing deeplink/QR. The future resolves when the user dismisses/cancels.
+    /// The core drops it on success/abort, which the host treats as "close the modal".
+    fn present(&self, deeplink: String) -> impl Future<Output = ()> + Send;
+}
+```
+
+The drop-to-close, resolve-on-cancel shape lets `request_login` `select!` over {handshake statement
+arrives, present-future resolves (cancel), `cx.cancel()`}.
+
+**Bridge:** `present` takes a `String` (like `navigate_to`) but must resolve on cancel, so it needs a
+bespoke invoker: a JS callback returning a `Promise<void>` that resolves only when the user closes the
+QR. **dotli mapping:** `topbar.ts` renders it via `QRCode.toCanvas(payload)`; the modal's close button
+resolves the promise. **Acceptance:** the core drives show/close; closing the modal aborts pairing.
+
+## A2. `RuntimeConfig`: static product and pairing inputs **(S)**
+
+Each product iframe/runtime needs values that are fixed before the core can answer product-scoped
+methods or build the pairing QR:
+
+```rust
+pub struct RuntimeConfig {
+    pub product_id: String,
+    pub product_label: String,
+    pub site_id: String,
+    pub host_name: String,
+    pub host_icon: Option<String>,
+    pub host_version: Option<String>,
+    pub platform_type: Option<String>,
+    pub platform_version: Option<String>,
+    pub people_chain_genesis_hash: [u8; 32],
+    pub pairing_deeplink_scheme: PairingDeeplinkScheme, // polkadotapp:// or polkadotappdev://
+}
+```
+
+This is constructor/configuration state on `PlatformRuntimeHost`, WASM, UniFFI, and the JS worker package,
+not a host callback and not part of every request payload. Current dotli creates one container per
+product label and derives the product id with `labelToProductIdentifier(label)` in
+`~/github/dotli/packages/ui/src/container.ts`. The same value is used by `get_legacy_accounts`, alias
+permission prompts, signing validation, resource allocation, and product entropy derivation, so the Rust
+runtime should be instantiated per product with this identity already known. Nested dApps are not a
+separate runtime/config boundary for v1; if dotli keeps nested message forwarding, nested traffic uses the
+same Rust core and product identity as the containing product. The current JS nested bridge behavior and
+its possible future value are tracked separately in [I](<I - nested-dapps.md>).
+
+For current dotli main, pairing metadata is embedded directly in the SSO V2 proposal. dotli should pass
+`host_name = "Polkadot Web"`, `host_icon = "https://dot.li/dotli.png"`,
+`host_version = __DOTLI_VERSION__`, and browser-derived `platform_type` / `platform_version` when available.
+
+## A3. Current host-container parity surfaces **(S-M)**
+
+These are platform traits or host callbacks needed only because the current dotli bridge already exposes
+them to products through `@novasamatech/host-container`.
+
+- **Notifications:** `push_notification` must return the host-api notification id and `cancel` must be
+  exposed. Current `truapi-platform::Notifications` only returns `Result<(), GenericError>`, so it needs
+  the wire-visible id/cancel shape before dotli can drop `handlePushNotification` /
+  `handlePushNotificationCancel`.
+- **Theme:** expose a subscription that emits the current `{ name, variant }` and future changes. Current
+  dotli maps browser light/dark state into the host-api `Default` theme.
+- **Preimage:** keep preimage host-side for v1, but expose submit and lookup subscription through Rust so
+  the JS container handler can be removed.
+- **Resource allocation confirmation:** current dotli shows an allowance modal before sending the SSO
+  `resourceAllocationRequest` over SSO. The core owns the encrypted SSO session request, but calls a
+  dedicated host UI confirmation hook first and maps dismissal to the same typed error path. Do not overload
+  `Permissions::remote_permission`: allocation confirmation wraps an SSO round-trip and retry-capable
+  modal, while remote permission is just a permission decision.
+- **SessionStore:** persist one optional opaque core-encoded blob for the full `SessionInfo` in
+  host-global secret storage. Do not reuse product-scoped `Storage`: the SSO session is shared across
+  product runtimes and contains `ss_secret` plus ECDH/session-channel material. The host does not see
+  typed session fields, and v1 does not preserve host-papp's multi-session list shape. Rust does not add
+  blob-level encryption/MAC; confidentiality and tamper resistance are the host storage layer's
+  responsibility. It must also support current-then-changes change notifications for both same-runtime
+  writes/clears and cross-tab/process changes so logout or re-pair updates all live runtimes without a
+  read/subscribe race. Notifications are coarse: the core receives a tick and calls `read()` to fetch and
+  validate the current blob.
+
+**Proposed trait**:
+
+```rust
+pub trait SessionStore: Send + Sync {
+    fn read(&self) -> impl Future<Output = Result<Option<Vec<u8>>, GenericError>> + Send;
+    fn write(&self, value: Vec<u8>) -> impl Future<Output = Result<(), GenericError>> + Send;
+    fn clear(&self) -> impl Future<Output = Result<(), GenericError>> + Send;
+    /// Emits once immediately, then once per future local or cross-runtime change.
+    /// The core calls `read()` after each tick.
+    fn subscribe(&self) -> BoxStream<'static, Result<(), GenericError>>;
+}
+```
+
+Signing, transaction construction, alias, pairing, and statement-store operations are not in this list
+because they are core protocol over the statement store.
+
+## Not host primitives (core protocol over the statement store)
+
+Earlier drafts modeled a pairing transport, a wallet-signing proxy, and a ring-VRF proxy as host
+primitives. The real protocol ([H](<H - sso-pairing-protocol.md>)) makes them **core logic**, not
+platform traits:
+
+- **Transport** is the People-chain statement store, reached via the **existing `ChainProvider`** trait
+  (`connect(genesis_hash) -> JsonRpcConnection`, then `statement_submit` /
+  `statement_subscribeStatement`). No new transport primitive.
+- **`sign_payload` / `sign_raw` / legacy variants / `create_transaction`** are `signingRequest` messages
+  the core sends over the encrypted session channel; the wallet signs and replies ([B](<B - core-impls.md>)).
+- **`request_resource_allocation`** is likewise an SSO session-channel request in current dotli, with
+  host-side confirmation before send and secret stripping around the result.
+- **`get_account_alias`** is an `aliasRequest` message over the same channel. **`create_account_proof`**
+  needs a full ring-VRF proof and is a separate Tier-4 decision ([E3](<E - open-questions.md>)); current
+  dotli code only calls the alias path.
+- **Statement-store `create_proof` / `subscribe` / `submit`** are core-native: the core already speaks
+  the statement store for pairing, and signs proofs with its own session key.
+
+## Identity: no new primitive
+
+`get_user_id` / `get_legacy_accounts` answer from `SessionState` (the wallet account ids learned at
+pairing, [C](<C - session-contract.md>)) plus product runtime config. Current dotli's
+`get_legacy_accounts` returns the product-derived `(calling_product_id, 0)` account, not the root account.
+`get_user_id` is additionally gated by the product-scoped `UserId` permission. Usernames, if surfaced,
+come from an on-chain People-chain identity lookup over the same `ChainProvider` connection and are
+**not** part of the pairing handshake.
diff --git a/docs/design/host-contract-and-core-impl/B - core-impls.md b/docs/design/host-contract-and-core-impl/B - core-impls.md
new file mode 100644
index 00000000..e7fdec31
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/B - core-impls.md	
@@ -0,0 +1,289 @@
+# B - Core implementations (`truapi-server` wire methods)
+
+> Part of the [host-contract & core-impl spec](index.md).
+
+This page tracks the wire methods migrated onto `PlatformRuntimeHost<P>` (`runtime.rs`). The current Rust
+core implements the dotli parity surface for `Account`, `Signing`, `StatementStore`,
+`ResourceAllocation`, `Entropy`, `Theme`, `Notifications`, and `Preimage`. `Payment::*`, `Chat`,
+`CoinPayment`, and full `Account::create_account_proof` stay intentionally deferred because those
+handlers are not implemented in current dotli parity.
+
+Use the [override template + error-mapping rules in the annex](<G - annex.md>) for the per-method
+implementation shape (destructure `::V1`, UFCS-call the platform, map domain errors to
+`CallError::Domain`), where new in-core state and `host_logic/` modules go, and the
+`PermissionsService` pattern for multi-step logic.
+
+Strategy tags below: **pure-core** (no host help) · **core+session** (reads `SessionState`) · **core+chan**
+(a request/response over the SSO session channel, [H §5](<H - sso-pairing-protocol.md>)) · **core protocol**
+(the pairing handshake or the statement-store client).
+
+| Wire method (id)                                                            | Strategy                                                          | Status                                                  |
+| --------------------------------------------------------------------------- | ----------------------------------------------------------------- | ------------------------------------------------------- |
+| `get_legacy_accounts`(28), `get_user_id`(110)                               | core+session + runtime product config                             | implemented                                             |
+| `get_account`(22)                                                           | pure-core + crypto                                                | implemented                                             |
+| `request_login`(112)                                                        | core protocol (SSO handshake, [H](<H - sso-pairing-protocol.md>)) | implemented                                             |
+| `sign_payload`(116), `sign_raw`(114), `sign_*_with_legacy_account`(34/36)   | core+chan (signingRequest)                                        | implemented                                             |
+| `create_transaction`(30), `create_transaction_with_legacy_account`(32)      | core+chan (createTransactionRequest)                              | implemented                                             |
+| `create_proof`(60), `create_proof_authorized`(132)                          | core+session + crypto                                             | implemented                                             |
+| `get_account_alias`(24)                                                     | core+chan (aliasRequest)                                          | implemented                                             |
+| `subscribe`(56), `submit`(62)                                               | core-native (statement client)                                    | implemented                                             |
+| `ResourceAllocation::request`(130)                                          | host-confirm + core+chan (resourceAllocationRequest)              | implemented                                             |
+| `Entropy::derive`(108)                                                      | core+session + crypto                                             | implemented                                             |
+| `Theme::subscribe`(104)                                                     | host-side primitive/subscription                                  | implemented                                             |
+| `Notifications::send_push_notification`(4), `cancel_push_notification`(134) | host-side primitive                                               | implemented                                             |
+| `lookup_subscribe`(64), `submit`(68) [preimage]                             | host-side primitive/callback                                      | implemented                                             |
+| `create_account_proof`(26)                                                  | core+chan (full ring-VRF; needs new message)                      | deferred (unimplemented by dotli)                       |
+| `Payment::*`                                                                | intentionally unavailable                                         | deferred (dotli returns typed "not implemented" errors) |
+
+---
+
+## Tier 1: account reads + derivation
+
+### `get_legacy_accounts` (#28) · `get_user_id` (#110): core+session **(S)**
+
+Read `self.session_state.current()` (returns `Option<SessionInfo>`) and the runtime
+`calling_product_id` / label config. No session => `HostAccountGetError::NotConnected` /
+`HostGetUserIdError::NotConnected`.
+
+- `get_legacy_accounts` → `HostGetLegacyAccountsResponse { accounts: vec![LegacyAccount { public_key:
+product_public_key.to_vec(), name: info.lite_username }] }`. Current dotli returns the single
+  product-derived `(calling_product_id, 0)` account, not the wallet root
+  (`~/github/dotli/packages/ui/src/container.ts:222-233`).
+- `get_user_id` → `HostGetUserIdResponse { primary_username: info.full_username.or(info.lite_username)
+.ok_or(NotConnected)? }`, gated by the product-scoped `UserId` permission like current dotli
+  (`~/github/dotli/packages/ui/src/container.ts:242-261`).
+
+Both have **unit** versioned requests (no payload). **Acceptance:** with a session set,
+`get_legacy_accounts` returns the product-derived account and `get_user_id` returns the permitted
+username; without one, they match current dotli's not-connected/empty behavior.
+
+### `get_account` (#22): pure-core + crypto **(S–M)**
+
+```rust
+async fn get_account(&self, _cx, request: HostAccountGetRequest)
+    -> Result<HostAccountGetResponse, CallError<HostAccountGetError>>
+// req:  v01::HostAccountGetRequest  { product_account_id: ProductAccountId }
+//       ProductAccountId { dot_ns_identifier: String, derivation_index: u32 }
+// resp: v01::HostAccountGetResponse { account: ProductAccount { public_key: Vec<u8> } }
+// err:  NotConnected | Rejected | DomainNotValid | Unknown { reason }
+```
+
+Read the session root pubkey (`info.public_key`), derive the product public key per
+[D](<D - crypto-foundation.md>) (sr25519 soft-derivation over junctions `["product", dot_ns_identifier,
+String(derivation_index)]`), return it. No session => `NotConnected`; invalid dotNS => `DomainNotValid`.
+**Acceptance:** byte-identical to dotli's `deriveProductPublicKey` for shared `(root, dotNS, index)`
+golden vectors.
+
+---
+
+## Tier 2: pairing in the core
+
+### `request_login` (#112): core protocol (SSO handshake) **(L)**
+
+`request_login` runs the SSO pairing handshake over the People-chain statement store and establishes the
+session. The full protocol (QR payload, topic derivation, channel encryption, handshake messages) is in
+[H](<H - sso-pairing-protocol.md>); below is the wire contract + control flow.
+
+```rust
+async fn request_login(&self, cx, request: HostRequestLoginRequest)
+    -> Result<HostRequestLoginResponse, CallError<HostRequestLoginError>>
+// req:  v01::HostRequestLoginRequest { reason: Option<String> }
+// resp: enum { Success, AlreadyConnected, Rejected }
+// err:  HostRequestLoginError::Unknown { reason }
+```
+
+Control flow (see [H §1-§3](<H - sso-pairing-protocol.md>) for the byte-level steps):
+
+```
+  session already present? --> AlreadyConnected
+  mint session sr25519 + P-256 keypairs ; read RuntimeConfig ; build VersionedHandshakeProposal::V2 -> deeplink
+  A1.present(deeplink) ; subscribe(bootstrap topic) on the People-chain statement store
+  select! {
+     handshake statement -> verify sr25519 proof ; ECDH-decrypt the answer ;
+                            derive SessionState{ public_key = root_user_account_id, ss_secret,
+                                                 peer keys, session ids } ;
+                            persist (C) ; set_session -> Connected -> Success
+     A1 present resolves (user closed the QR) -> Rejected
+     cx.cancel() (product cancelled) -> abort
+  }
+```
+
+Depends on the Tier-2 statement-store client (submit/subscribe over `ChainProvider`) and the runtime
+pairing config ([A2](<A - host-primitives.md>)). The crypto byte contract is specified in
+[H](<H - sso-pairing-protocol.md>) + [D](<D - crypto-foundation.md>) and must be pinned by vectors before
+implementation. **Acceptance:** a real wallet pairs and `connection_status` flips to Connected carrying
+the wallet's `root_user_account_id`; a handshake statement with a bad proof or wrong signer is rejected;
+closing the QR aborts cleanly.
+
+---
+
+## Tier 3: message-exchange ops + statement proofs
+
+### `sign_payload` (#116) · `sign_raw` (#114) · legacy variants (#34/#36): core+chan (signingRequest) **(M)**
+
+```rust
+// sign_payload req: v01::HostSignPayloadRequest { account: ProductAccountId, payload: HostSignPayloadData }
+// sign_raw     req: v01::HostSignRawRequest     { account: ProductAccountId, payload: RawPayload }
+// resp (both):     v01::HostSignPayloadResponse { signature: Vec<u8>, signed_transaction: Option<Vec<u8>> }
+// err  (both):     FailedToDecode | Rejected | PermissionDenied | Unknown { reason }
+```
+
+Enforce product-account validity and the `ChainSubmit` remote permission via the existing `Permissions`
+trait first (denied => `CallError::Domain(PermissionDenied)`), then send a
+`signingRequest(transaction | rawPayload)` over the SSO session channel ([H §5](<H - sso-pairing-protocol.md>))
+and await the `signingResponse`. The wallet signs with its `/product/<dotNs>/<idx>` key and returns
+`Signature { raw_signature, signed_transaction? }`. Current dotli's host modal maps local cancel before
+dispatch to `Rejected`; `session.signPayload` / `session.signRaw` `Err(message)`, transport teardown, and
+host-papp's 180s queue timeout map to `Unknown { reason }`. dotli's modal also wraps the call in a 300s
+outer fallback, but the session-layer timeout should win for normal no-response cases. No active session
+maps to `Rejected` in the current signing handlers, and invalid product account / denied `ChainSubmit`
+maps to `PermissionDenied`. The legacy variants re-derive `(calling_product_id, 0)`, verify the provided
+legacy signer matches that derived account, and then route through the same product-account request.
+**Acceptance:** signature
+matches today's dotli path; ungranted `ChainSubmit` => `PermissionDenied`; host-modal cancel =>
+`Rejected`; SSO/session failure => `Unknown { reason }`; signer mismatch maps to `Unknown` like current
+dotli.
+
+### `create_transaction` (#30) · `create_transaction_with_legacy_account` (#32): core+chan **(M)**
+
+Current dotli implements both (`~/github/dotli/packages/ui/src/container.ts:413-461`,
+`:594-664`). Product-account `create_transaction` validates `signer`, checks `ChainSubmit`, then sends
+`createTransactionRequest` over the SSO channel. The legacy variant re-derives `(calling_product_id, 0)`,
+checks the raw signer public key, then sends the same SSO request with synthetic product signer
+`[calling_product_id, 0]`. **Acceptance:** returns the encoded signed transaction bytes from the wallet;
+permission denial, no-session rejection, host-modal cancel, signer mismatch, SSO/session failure, and the
+host-papp 180s queue timeout match current dotli behavior (`Rejected` for no session or local cancel,
+`PermissionDenied` for product/permission failure, `Unknown { reason }` for signer mismatch,
+session-channel failure, or timeout). The current UI wrapper also has a 300s outer fallback.
+
+### `create_proof` (#60) · `create_proof_authorized` (#132): core+session + crypto **(L)**
+
+```rust
+// create_proof            req: v01::RemoteStatementStoreCreateProofRequest { product_account_id, statement: Statement }
+// create_proof_authorized req: v01::Statement  (bare; uses a pre-allocated allowance account)
+// resp (both):                 RemoteStatementStoreCreateProofResponse { proof: StatementProof }
+// err  (both):                 UnableToSign | UnknownAccount | Unknown { reason }
+```
+
+Sign the `Statement` in-core with the session `ssSecret` (schnorrkel sr25519), producing
+`StatementProof::Sr25519 { signature:[u8;64], signer:[u8;32] }` where `signer` is the **session
+statement-store pubkey** (the core's own session sr25519 key, which the wallet granted statement-store
+allowance to during pairing, **not** the wallet root). dotli reads this same key as `ssSecret` via
+`secrets.read`. No session/secret => `UnableToSign`. The `Statement` field ordering fed to the proof is
+known from current `@novasamatech/sdk-statement`: encode the unsigned statement, strip the leading
+compact length prefix, and sign the remaining SCALE payload with the 64-byte expanded `ssSecret`
+([D3](<D - crypto-foundation.md>)).
+**Acceptance:** proof bytes match `createSr25519Prover(ssSecret).generateMessageProof(statement)` golden
+vectors.
+
+### `get_account_alias` (#24): core+chan (aliasRequest) **(M)**
+
+Send an `aliasRequest { product_account_id, calling_product_id }` over the SSO channel; the wallet
+derives the bandersnatch alias for `context = blake2b(utf8("/product/<dotNs>/<idx>"))` and replies
+`ContextualAlias { context:[u8;32], alias }` ([H §5](<H - sso-pairing-protocol.md>)). Map to
+`HostAccountGetAliasResponse { context, alias }`; on cross-domain alias requests the host shows the
+alias-permission prompt (today via dotli; in-core this is a `Permissions` check). Current dotli does not
+add a local timeout around `session.getRingVrfAlias`; no session maps to `NotConnected`, invalid product
+identifier to `DomainNotValid`, permission-prompt cancel to `Rejected`, and session-channel errors to
+`Unknown { reason }`. **Acceptance:** `get_account_alias` returns `{ context, alias }` matching today.
+
+### `ResourceAllocation::request` (#130): host-confirm + core+chan **(M)**
+
+Current dotli prompts, then calls `session.requestResourceAllocation`
+(`~/github/dotli/packages/ui/src/container.ts:666-724`). The core should send
+`resourceAllocationRequest { calling_product_id, resources, on_existing }` over the SSO channel only
+after a host UI confirmation callback accepts the request. Dismissal/cancel maps to the typed unknown
+error path dotli uses today. This is a dedicated confirmation trait/callback, not
+`Permissions::remote_permission`, because current dotli's modal owns retry behavior around the SSO
+round-trip: a failed allocation attempt leaves the modal open and lets the user retry. Dotli does not add
+a separate UI-level timeout around `requestResourceAllocation`; it relies on session-channel request
+machinery, which has the host-papp 180s queue timeout for this operation. No active session,
+host dismissal/cancel, and SSO/session errors all map to
+`ResourceAllocationErr.Unknown { reason }`. Map the host-api 0.8 `BulletinAllowance` tag to the SSO
+peer's current `BulletInAllowance` dialect if still required by vectors. Strip secret material from
+`Allocated` outcomes before returning to the product, as dotli does today. **Acceptance:** requesting
+statement/bulletin allowances shows host confirmation, allows retry after SSO failure, succeeds with the
+paired SSO peer after approval, and does not expose returned secrets to the product.
+
+---
+
+### `subscribe` (#56) · `submit` (#62) [statement-store]: core-native **(M, was XL)**
+
+These are part of current dotli feature parity because dotli wires `handleStatementStoreSubscribe` and
+`handleStatementStoreSubmit` through `@novasamatech/statement-store` today
+(`~/github/dotli/packages/ui/src/container.ts:981-1041`). They therefore block removing
+`statement-store` / `sdk-statement`, even though the heavy transport work is already done by the Tier-2
+statement-store client.
+
+```rust
+// subscribe req: RemoteStatementStoreSubscribeRequest = MatchAll(Vec<[u8;32]>) | MatchAny(Vec<[u8;32]>)
+//           item: RemoteStatementStoreSubscribeItem { statements: Vec<SignedStatement>, is_complete: bool }
+// submit    req: v01::SignedStatement (bare) ; resp: () ; err: v01::GenericError
+```
+
+These reuse the **same statement-store client** built for pairing (Tier 2): the core already submits and
+subscribes to statements on the People-chain connection. `submit` posts the `SignedStatement`; `subscribe`
+filters by topic and streams pages. **Paging contract** (RFC-0008) the implementation must preserve:
+
+```
+  is_complete:  false   false   false   |   true     true     true   ...
+                \___ historical dump ___/  ^first true = "synced"   \_ live, new statements only _/
+                (more pages follow)        (all subsequent pages are true)
+  topic limits: MatchAll <= 4, MatchAny <= 128 ; subscribe filters to statements with a proof
+```
+
+The on-chain `Statement` SCALE shape + the `statement_submit`/`statement_subscribeStatement` RPC are
+known from the iOS peer ([H](<H - sso-pairing-protocol.md>)). The implementation shares the statement
+client used by pairing and exposes the product-facing topic-filtered subscription plus dump-then-live
+paging in-core. [E1](<E - open-questions.md>) resolves this in-core.
+
+---
+
+## Tier 3.5: implemented host-side dotli behavior
+
+### `Entropy::derive` (#108): core+session + crypto **(S-M)**
+
+Current dotli main uses host-papp 0.8.6 / RFC-0007 entropy: successful SSO V2 pairing returns
+`rootEntropySource`, and product entropy is derived from that root source, the runtime product id, and the
+caller key. Rust must persist `rootEntropySource` in `SessionInfo` and update vectors from the V2 peer.
+No session/secret => `Unknown { reason:"Not connected" }` / `"Session secret missing"` parity unless the
+Rust error type is more specific.
+
+### `Theme::subscribe` (#104): host-side **(S)**
+
+Current dotli emits `{ name: Default, variant: Light|Dark }` and listens for
+`dotli:theme-changed` (`~/github/dotli/packages/ui/src/container.ts:1194-1214`). Rust delegates to the
+platform theme subscription so the host adapter owns the browser/UI source while the core preserves the
+typed TrUAPI stream.
+
+### Notifications (#4/#134): extend platform primitive **(M)**
+
+Current dotli schedules/cancels local notifications and returns a host-assigned id
+(`~/github/dotli/packages/ui/src/container.ts:929-975`). `truapi-platform::Notifications` exposes both
+`push_notification(...) -> HostPushNotificationResponse { id }` and `cancel_notification(...)`; Rust
+delegates scheduling/cancellation to the host adapter.
+
+### `lookup_subscribe` (#64) · `submit` (#68) [preimage]: host-side **(M)**
+
+Current dotli implements preimage submit/lookup with the selected content backend and local cache
+(`~/github/dotli/packages/ui/src/container.ts:1081-1192`). It does not use Nova packages, but it must still
+be exposed through the Rust host once `host-container` is removed. The v1 Rust implementation keeps this
+host-side ([E4](<E - open-questions.md>)): the platform callbacks own IPFS/Bulletin/cache behavior and
+the core exposes the typed TrUAPI subscription/request surface.
+
+---
+
+## Tier 4: remaining
+
+### `create_account_proof` (#26): core+chan (ring-VRF): deferred
+
+Req `RingLocation { genesis_hash, ring_root_hash, hints }` + `context`, resp `{ proof: Vec<u8> }`. This
+is a **full ring-VRF proof**, but the SSO channel exposes `deriveAlias` only today (the wallet's
+`BandersnatchKeyManaging.createProof` is not wired to a message). Carrying it needs a new message type or
+an in-core bandersnatch path ([E3](<E - open-questions.md>)).
+
+### `Payment::*`: intentionally unavailable
+
+Current dotli registers typed "not implemented" payment responses
+(`~/github/dotli/packages/ui/src/container.ts:1216-1243`). Leave Payment unavailable for this milestone;
+it only becomes relevant when another host/product needs real payment rails.
diff --git a/docs/design/host-contract-and-core-impl/C - session-contract.md b/docs/design/host-contract-and-core-impl/C - session-contract.md
new file mode 100644
index 00000000..37565847
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/C - session-contract.md	
@@ -0,0 +1,120 @@
+# C - Session / identity contract
+
+> Part of the [host-contract & core-impl spec](<index.md>).
+
+The core establishes the session by running pairing ([`request_login`](<B - core-impls.md>) /
+[H](<H - sso-pairing-protocol.md>)), so it owns `SessionState`. This doc covers the `SessionInfo`
+extension and core-owned persistence/restore.
+
+## C1. Extend `SessionInfo` for a core-run session **(S-M)**
+
+`SessionState` / `SessionInfo` live in `host_logic/session.rs`. Today:
+
+```rust
+pub struct SessionInfo { pub public_key: [u8; 32], pub lite_username: Option<String>, pub full_username: Option<String> }   // session.rs:15-23
+pub struct SessionState { /* Mutex<{ current: Option<SessionInfo>, subscribers: Vec<UnboundedSender<..>> }> */ }            // session.rs:27-36
+```
+
+`SessionState`'s machinery is already right: `set_session` broadcasts `Connected` only on a
+no-session->session transition; `clear_session` broadcasts `Disconnected` only if one was present;
+`subscribe()` emits current-then-transitions; `current()` snapshots (session.rs:46-93). This drives
+`connection_status_subscribe`(18) via the override at `runtime.rs:325-330`.
+
+Because the core now runs pairing, `SessionInfo` carries the material the handshake produces
+([H §3](<H - sso-pairing-protocol.md>)):
+
+```rust
+pub struct SessionInfo {
+    pub public_key: [u8; 32],           // wallet root_user_account_id; the product-account derivation root
+    pub ss_secret: [u8; 64],            // core's OWN expanded sr25519 statement-store secret (signs statement proofs)
+    pub enc_secret: [u8; 32],           // core's P-256 ECDH private key (channel encryption)
+    pub peer_enc_pubkey: [u8; 65],      // wallet persistent P-256 pubkey
+    pub identity_account_id: [u8; 32],  // wallet identity pubkey
+    pub session_id_own: [u8; 32],       // derived request/response topics
+    pub session_id_peer: [u8; 32],
+    pub lite_username: Option<String>,  // from on-chain identity, NOT the handshake
+    pub full_username: Option<String>,
+}
+```
+
+`ss_secret` is the core's own session statement-store key, **generated by the core** during pairing (the
+wallet never sends a secret, [H](<H - sso-pairing-protocol.md>)); it signs the core's statements and the
+product statement proofs ([B create_proof](<B - core-impls.md>)). None of these secrets leave the core.
+Account-only injection APIs such as `set_active_session(pubkey, lite, full)` are not part of this plan:
+they cannot rehydrate `ss_secret`, ECDH material, peer keys, or derived session ids. Real v1 restore uses
+the core-owned persisted session blob in C2. Usernames are filled by a separate on-chain People-chain
+identity lookup keyed by `public_key`.
+
+## C2. Persistence + restore **(M)**
+
+```
+  request_login succeeds                         core init (cold start)
+        |                                              |
+        v                                              v
+  SessionState.set_session(info)                 SessionStore.subscribe()
+        |  Connected broadcast                          |  first tick is current-state signal
+        v                                              v
+  SessionStore.write(encode(info))               SessionStore.read()
+        |                                             Some(blob) -> decode -> set/replace session
+        v                                             None       -> clear_session / stay Disconnected
+  (new successful pairing replaces old blob)     future ticks repeat read/decode
+        ...
+  logout: clear_session + SessionStore.clear()
+```
+
+The core writes opaque encoded bytes for the full `SessionInfo` via a dedicated host/global
+`SessionStore` capability on establish, and subscribes to the store on init to re-hydrate `SessionState`.
+Do **not** reuse the existing `Storage` trait: that is product-scoped local storage semantics, while the
+wallet session is host-global, secret-bearing, and shared across product runtimes. The host does not see
+typed session fields; Rust owns the schema, versioning, migration, and validation. V1 is **single-session
+only**: `SessionStore` exposes at most one blob and a new successful pairing replaces the old blob.
+If the blob is missing, unreadable, fails version/schema validation, or fails decode, the core
+clears `SessionStore`, logs/emits diagnostics, and stays `Disconnected`; it must not start with a partial
+session.
+Rust does not encrypt or MAC the persisted blob itself; confidentiality and tamper resistance are the
+host storage layer's responsibility. The core still validates the bytes before restoring a session.
+For dotli web, back `SessionStore` with the same shared host-origin storage path used by current auth
+(`host.<root-domain>` localStorage via the protocol iframe), but use a new Rust-owned key/prefix such as
+`TRUAPI_SESSION_<siteId>`. Do not reuse `PAPP_*` or `SsoSessions`; those names imply host-papp's
+multi-session `Vec<Session>` encoding.
+`SessionStore.subscribe()` emits one tick immediately, then future change ticks for both same-runtime
+writes/clears and cross-tab/process changes. The notification carries no session bytes; after each tick the
+core calls `read()` and validates the current blob. That avoids a read-then-subscribe race and keeps every
+runtime on the same path: a clear yields `None`, clears in-memory `SessionState`, and broadcasts
+`Disconnected`; a valid replacement blob is decoded, replaces in-memory `SessionState`, and broadcasts the
+normal connection transition. The core should dedupe equivalent blobs/session ids before rebroadcasting if
+the host emits after a local write that the core already applied. dotli web should implement this with the
+same local emit plus protocol-iframe BroadcastChannel-style shared-storage notifications it uses today.
+The persisted format is **core-defined**; the cutover from `@novasamatech` sessions intentionally
+requires a one-time re-pair ([E5](<E - open-questions.md>)). Logout clears both in-memory state and the
+persisted blob through the same core-owned session store.
+
+## C3. Public logout / disconnect API **(S)**
+
+dotli UI needs a direct host->core logout action. Expose a public core API such as `disconnect()` /
+`logout()` through WASM, UniFFI, and the JS worker package. Hosts should call this API, not
+`SessionStore.clear()` directly.
+
+Core behavior:
+
+- best-effort send SSO session-channel `disconnected` over the People-chain statement-store protocol if
+  the session channel is currently usable; do not wait indefinitely and do not fail logout if this send
+  fails;
+- stop/tear down active session-channel subscriptions and pending request waiters; in-flight
+  request/response operations must resolve as failures rather than hanging. Current dotli delegates this
+  to `host-papp`'s session manager (`adapter.sessions.disconnect(session)`), whose debug contract reports
+  channel teardown as `session:host_action_failed`; the Rust core should make that lifecycle explicit.
+- clear in-memory `SessionState` and broadcast `Disconnected`;
+- clear the single persisted session blob through `SessionStore.clear()`;
+- tolerate repeated logout when already disconnected.
+
+Peer-originated `disconnected` messages over the SSO session channel route through the same internal
+cleanup path, including `SessionStore.clear()`. Do not keep a persisted session after the SSO peer says the
+session is disconnected.
+
+Current host-papp has a 180s session request-queue timeout for `signPayload`, `signRaw`,
+`createTransaction`, and `requestResourceAllocation`; dotli's signing/transaction UI wrappers add a 300s
+outer fallback after the user confirms the modal. `getRingVrfAlias` does not add a separate timeout in the
+current checkout. Preserve the same user-visible failure shape in Rust: peer decline maps to the method's
+domain rejection/unknown path, transport teardown maps to `Unknown { reason }` where the host-api type
+lacks a dedicated disconnected variant, and no operation waits forever after local or peer disconnect.
diff --git a/docs/design/host-contract-and-core-impl/D - crypto-foundation.md b/docs/design/host-contract-and-core-impl/D - crypto-foundation.md
new file mode 100644
index 00000000..605ee858
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/D - crypto-foundation.md	
@@ -0,0 +1,161 @@
+# D - Crypto & dependency foundation
+
+> Part of the [host-contract & core-impl spec](index.md).
+
+`truapi-server` has no crypto deps today (grep for `schnorrkel`/`blake2` in the workspace `Cargo.toml`s
+returns nothing). This doc specifies the deps, the one fully-portable algorithm (`get_account`
+derivation), the proof scheme that must be extracted from source, and the golden-vector harness that
+gates all of it.
+
+Implementation shape: use `~/github/useragent-kit` as implementation precedent only, especially
+`crates/host-wallet/src/crypto.rs`, `crates/host-encoding/src/statement_store.rs`, and
+`crates/host-wallet/tests/pinned_vectors.rs`: keep pure protocol crypto in a narrow WASM-safe
+module/crate, use existing Rust crypto crates for primitives, provide deterministic helpers for vectors
+(for example fixed AES-GCM nonces), and test the same vectors on native and wasm. Do **not** hand-roll
+crypto primitives. `useragent-kit` has broader scope and is not a protocol source of truth for TrUAPI
+SSO bytes; consult it when we need examples of similar Novasama-codepath migrations to Rust.
+
+## D0. Tier 1.5 crypto/vector gate
+
+Before Tier 2 pairing I/O starts, add a focused crypto module/crate and pinned vectors for:
+
+- `get_account` public HDKD derivation.
+- Statement signing payload encoding and sr25519 proof sign/verify.
+- QR handshake SCALE encoding and deeplink bytes.
+- P-256 ECDH -> HKDF -> AES-GCM encrypt/decrypt with fixed inputs/nonces.
+- Topic/channel/session-id derivation.
+
+This gate produces tests, not the full `request_login` flow. Tier 2 starts only after those tests pass on
+native and `wasm32-unknown-unknown`.
+
+`useragent-kit` is a dependency/style reference, not a protocol source of truth. Its scope is broader and
+may include a different pairing dialect. The vector capture must compare against the pinned
+`@novasamatech/host-papp` package and the wallet peer.
+
+## D1. Dependencies (must build for `wasm32-unknown-unknown`)
+
+Two crypto layers, with constants read from the current dotli-installed `@novasamatech` packages and
+locked by the Tier 1.5 vectors ([H](<H - sso-pairing-protocol.md>)):
+
+- **Statements + accounts (sr25519):** `schnorrkel` for statement-proof sign/verify and `get_account`
+  HDKD soft derivation. SCALE (`parity-scale-codec`, already a dep) for chain-code + statement encoding.
+- **The SSO channel (P-256 ECIES):** NIST P-256 ECDH + HKDF-SHA256 + AES-GCM. RustCrypto stack:
+  `p256` (key agreement), `hkdf` + `sha2`, `aes-gcm`. Current dotli uses HKDF-SHA256 with empty
+  `salt`/`info`, `dkLen=32`, AES-GCM with a random 12-byte nonce prepended to ciphertext+tag.
+- **Topic / channel / session-id derivation:** keyed **BLAKE2b-256** (`blake2`, keyed mode). Current
+  dotli's `khash(secret, message)` is `blake2b(message, { dkLen: 32, key: secret })`; it is used for the
+  handshake topic, session ids, and request/response channels.
+- `bandersnatch_vrfs` / `ark-*`: only if `create_account_proof` / ring-VRF moves in-core
+  ([E3](<E - open-questions.md>)); the alias itself is proxied to the wallet.
+
+Add behind the existing wasm build and confirm `make wasm` + `cargo build -p truapi-server
+--target wasm32-unknown-unknown` succeed (schnorrkel + p256 need `getrandom`'s `js` feature on wasm).
+
+## D2. `get_account` product-account derivation: fully specified, portable now
+
+This is pure (no secret) and is the cleanest in-core port. Current dotli's reference is
+`~/github/dotli/packages/auth/src/account.ts` using `@scure/sr25519` `HDKD.publicSoft`. Reproduce
+exactly:
+
+```
+ root_pk = SessionInfo.public_key      (= session.remoteAccount.accountId, 32 bytes)
+ junctions = ["product", dot_ns_identifier, String(derivation_index)]   // always these 3, in order
+
+   root_pk --publicSoft(cc("product"))--> pk1 --publicSoft(cc(dotNS))--> pk2 --publicSoft(cc(idxStr))--> product_pk
+   (left fold: junctions.reduce((pk, j) => HDKD.publicSoft(pk, cc(j)), root_pk))
+```
+
+Chain code `cc(code)`: a **32-byte buffer, zero-initialised**, after encoding/compression:
+
+```
+  if code matches /^\d+$/: encoded = SCALE u64(BigInt(code))
+  else:                    encoded = SCALE str(code)  (compact-length byte + UTF-8)
+
+  if encoded.len > 32:     bytes = blake2b(encoded, dkLen=32)
+  else:                    bytes[0..encoded.len] = encoded; remaining bytes stay zero
+```
+
+So `"product"` and the dotNS go through the `str` branch; `String(derivation_index)` (always numeric)
+goes through the `u64` branch. In Rust: build the `[u8;32]`, use schnorrkel public soft derivation
+(`PublicKey` soft-derive with that chain code), fold over the three junctions. This must be vector-tested
+against current dotli because `u32` would produce the wrong product account for every numeric derivation
+index.
+
+**Note:** product accounts have no per-product secret today; the matching `deriveProductSecretKey`
+(`HDKD.secretSoft`) is intentionally disabled in dotli (`account.ts:28-42`) because derived accounts have
+no People-chain allowance yet. The core derives the product **public** key for `get_account` but signs
+statement proofs with the **session statement-store** key (`ss_secret`, see D3), not a product key.
+
+**Acceptance:** golden vectors: for fixed `(root_pk, dotNS, index)` tuples, the Rust output equals
+`HDKD.publicSoft`-folded output byte-for-byte.
+
+## D3. Statement-proof signing
+
+Current dotli signs with `createSr25519Prover(ssSecret).generateMessageProof(statement)` in
+`~/github/dotli/packages/ui/src/container.ts` (`handleStatementStoreCreateProof`). `ssSecret` is the
+core's session statement-store sr25519 secret; the output is
+`StatementProof::Sr25519 { signature:[u8;64], signer:[u8;32] }` with `signer` = the session statement
+pubkey (allowance-granted by the wallet).
+
+The **message framing is known** from current dotli packages: `@novasamatech/sdk-statement` encodes the
+unsigned `Statement`, strips the leading compact length prefix from the encoded bytes, and signs the
+remaining SCALE payload. `@novasamatech/statement-store` then sets
+`proof = sr25519 { signature, signer }`. The secret passed to the signer is the 64-byte
+Ed25519-expanded/scure HDKD secret returned by `createSr25519Secret`; the package's substrate sr25519
+wrapper calls `@polkadot-labs/schnorrkel-wasm` `sr25519_sign(publicKey, secret, message)` with no
+explicit context parameter.
+
+**Acceptance:** for a fixed `(ssSecret, statement)`, the Rust `{signature, signer}` equals
+`generateMessageProof`'s output (signatures are randomised, so verify with the public key + compare
+`signer`, or seed the RNG when capturing vectors).
+
+## D4. SSO channel crypto (host-papp + wallet-peer vectors)
+
+Current dotli main uses host-papp 0.8.6 SSO V2. The vector gate must cover:
+
+- `VersionedHandshakeProposal::V2` SCALE with `Device { statementAccountId, encryptionPublicKey }`.
+- Metadata entries for `HostName`, `HostVersion`, `HostIcon`, `PlatformType`, and `PlatformVersion`.
+- V2 pairing topic and channel:
+  `blake2b256_keyed(encryptionPublicKey || "topic", key=statementAccountId)` and the same for
+  `"channel"`.
+- `VersionedHandshakeResponse` / encrypted V2 response variants (`Pending`, `Success`, `Failed`).
+- `HandshakeSuccessV2` fields, especially `rootAccountId`, `identityAccountId`, `ssoEncPubKey`,
+  `deviceEncPubKey`, and `rootEntropySource`.
+
+The current dotli web path is explicit:
+
+- `createEncrSecret(entropy)`: convert entropy to a mini-secret, zero-extend to a 48-byte seed, then
+  `p256.keygen(seed).secretKey`.
+- `getEncrPub(secret)`: uncompressed P-256 public key, 65 bytes.
+- `createSharedSecret(secret, publicKey)`: `p256.getSharedSecret(secret, publicKey).slice(1, 33)`, i.e.
+  the X coordinate from the uncompressed ECDH output.
+- bootstrap decrypt: `createSharedSecret(core_encr_secret, wallet_tmp_key)`.
+- steady-state shared secret: `createSharedSecret(core_encr_secret, shared_secret_derivation_key)`, where
+  `shared_secret_derivation_key` is the SSO peer's persistent P-256 public key from the sensitive
+  handshake response.
+- encryption: `createEncryption(sharedSecret)` derives `aesKey = HKDF-SHA256(sharedSecret, salt=[], info=[], len=32)`;
+  encrypt prepends a random 12-byte nonce to AES-GCM ciphertext+tag; decrypt splits the first 12 bytes as
+  nonce.
+- handshake topic: `khash(ss_public_key, encr_public_key || "topic")`.
+- session id: `khash(sharedSecret, "session" || accountA.accountId || accountB.accountId || pinA || pinB)`,
+  where each missing pin contributes the separator byte/string `"/"`.
+- request/response channels: `khash(session_id, "request")` and `khash(session_id, "response")`.
+
+The vector gate remains mandatory because it catches byte-order/SCALE/nonce mistakes, not because these
+choices are still open.
+
+## D5. Golden-vector harness
+
+The `@novasamatech` packages are pinned in current dotli main at `0.8.6` for `host-api`, `host-papp`,
+`statement-store`, and `storage-adapter` (`sdk-statement` remains `^0.6.0`). To capture vectors: use
+`hosts/dotli` `origin/main` or a scratch workspace with the same package versions, then snapshot into a
+Rust test fixture:
+
+- `HDKD.publicSoft` fold outputs for several `(root, dotNS, index)` tuples (D2).
+- `createSr25519Prover(secret).generateMessageProof(statement)` `{signature, signer}` for fixed inputs (D3).
+- SSO V2 QR proposal SCALE/deeplink bytes for fixed public keys + host metadata entries.
+- P-256 ECDH -> HKDF -> AES-GCM round-trip + topic/session-id derivation for fixed inputs (D4),
+  cross-checked against the iOS `SsoTestData` fixtures and host-papp outputs.
+
+Commit the vectors as test data and assert the Rust implementations reproduce them. This harness is the
+acceptance gate for Tiers 1-3; do it before, not after, implementing the crypto.
diff --git a/docs/design/host-contract-and-core-impl/E - open-questions.md b/docs/design/host-contract-and-core-impl/E - open-questions.md
new file mode 100644
index 00000000..d89f0ede
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/E - open-questions.md	
@@ -0,0 +1,167 @@
+# E - Decision log / deferred questions
+
+> Part of the [host-contract & core-impl spec](index.md).
+
+Resolved branches from the plan audit, plus deferred items that are not required for current dotli parity.
+The rest of the spec assumes these decisions for v1.
+
+## E1. StatementStore `subscribe`/`submit` transport: RESOLVED
+
+The core builds a minimal People-chain statement submit/subscribe client for pairing anyway
+([H](<H - sso-pairing-protocol.md>), Tier 2), so the product-facing `subscribe`/`submit` reuse it rather
+than being a fresh pallet port. The resolved choice is where the **product-facing paging semantics**
+(topic-filtered subscription, historical-dump-then-live driving `is_complete`) live. **Decision:**
+in-core now that the client exists; the on-chain `Statement`
+SCALE is known from the iOS peer. This is part of the `@novasamatech` removal critical path because
+dotli exposes product-facing statement-store callbacks through `@novasamatech/statement-store` today.
+Gates [B subscribe/submit](<B - core-impls.md>).
+
+## E2. Wallet channel ownership (signing model): RESOLVED
+
+Resolved by [H](<H - sso-pairing-protocol.md>): there is no separate wallet channel. Signing, ring-VRF
+alias, and create-transaction are request/response messages the **core** sends over the encrypted SSO
+session channel on the People-chain statement store; the wallet signs and replies. So the wallet
+sign-protocol is **core-owned**, and `host-papp` has no residual client to keep. Sub-decision retained:
+the `ChainSubmit` permission gate is enforced in the core via the existing `Permissions` trait before the
+`signingRequest` is sent.
+
+## E3. `create_account_proof` ring-VRF (full proof)
+
+The alias (`get_account_alias`) is an `aliasRequest` the wallet answers with `deriveAlias` over the SSO
+channel ([H §5](<H - sso-pairing-protocol.md>)). `create_account_proof` (#26) needs a **full ring-VRF
+proof**, which the channel does not expose today (the wallet has `BandersnatchKeyManaging.createProof` but
+no message routes to it). Options: add a new SSO message type the wallet answers, or compute it in-core
+(`bandersnatch_vrfs`/`ark-*` + ring membership from the Chain runtime, XL). **Recommendation:** add an SSO
+message (keeps the ring secret in the wallet). This is not a current dotli parity blocker because current
+dotli does not implement `handleAccountCreateProof`, and the host-papp remote-message surface audited for
+this plan has no full ring-VRF proof request/response variant.
+
+## E4. Preimage: RESOLVED
+
+Keep host-side (dotli polls an IPFS/Helia gateway; no `@novasamatech`), or move CID compute + poll
+in-core with a content-fetch host callback. **Decision:** host-side for v1. Because current dotli does
+implement preimage submit/lookup through the `host-container` bridge, Rust must still expose host-side
+preimage callbacks before `host-container` can be removed; the IPFS/Bulletin implementation itself stays
+out of `truapi-server`.
+
+## E5. Session-persistence encoding: RESOLVED
+
+The core defines its own persisted `SessionInfo` format (forces a one-time re-pair on cutover), or
+matches `@novasamatech` byte-for-byte (the `SsoSessions` / `PAPP_<siteId>_<key>` keys and the
+`EMPTY_SHARED_AUTH_SESSION_LIST = "0x00"` SCALE `Vec<Session>` sentinel, `auth-storage.ts:10,16,53-55`) so
+already-logged-in users survive. The full `Vec<Session>` layout is host-papp-internal.
+**Decision:** core-defined. A one-time re-pair on cutover is acceptable, so the implementation does not
+need to reverse-engineer or preserve host-papp's internal session list encoding. Gates
+[C persistence](<C - session-contract.md>) and the `auth-storage.ts` cleanup in [F](<F - novasamatech-removal.md>).
+
+## E6. Relay endpoint + deeplink format: RESOLVED
+
+There is no relay endpoint: the transport is the People-chain statement store reached via `ChainProvider`,
+and the deeplink is `polkadotapp://pair?handshake=<hex(SCALE VersionedHandshakeProposal::V2)>`
+([H §1](<H - sso-pairing-protocol.md>)). Both are core-owned protocol constants; the only host input is the
+People-chain genesis hash for `ChainProvider::connect` plus the SSO V2 host metadata fields in
+`RuntimeConfig`.
+
+## E7. Resource allocation confirmation: RESOLVED
+
+Current dotli shows a dedicated allowance modal before calling `session.requestResourceAllocation`; errors
+from the SSO allocation attempt keep the modal open for retry. **Decision:** model this as a dedicated
+host confirmation callback/trait before the core sends the encrypted `resourceAllocationRequest` over the
+SSO session channel. Do not overload `Permissions::remote_permission`, which is a permission decision
+surface rather than retry-capable operation UI.
+
+## E8. Nested dApps: RESOLVED
+
+Current dotli can create extra JS host-container bridges for nested iframe sources. **Decision:** do not
+model nested dApps as separate Rust runtimes, sessions, product identities, or storage namespaces for v1.
+Nested traffic, if forwarded at all, uses the shared top-level product core. Track the usefulness and any
+future independent nested-product model in [I](<I - nested-dapps.md>).
+
+## E9. Account-only session injection: RESOLVED
+
+Existing `setActiveSession(pubkey, lite, full)`-style APIs cannot restore a channel-capable core session:
+they omit `ss_secret`, P-256 key material, peer keys, and derived session ids. **Decision:** remove
+`setActiveSession`/`clearActiveSession` worker-plumbing from the migration plan. Real restore/logout uses
+the core-owned persisted `SessionInfo` store; cutover still requires one-time re-pair.
+
+## E10. Session persistence storage surface: RESOLVED
+
+The existing `Storage` trait is product-scoped local storage. A wallet session is host-global,
+secret-bearing, and shared across product runtimes. **Decision:** add/use a separate host-global
+`SessionStore` capability for opaque core-encoded bytes. Rust owns the `SessionInfo` schema/versioning;
+the host only implements `read()`, `write(Vec<u8>)`, and `clear()`. Do not persist `ss_secret` or ECDH
+material through product-scoped `Storage`, and do not expose typed session fields to JS/UniFFI.
+
+## E11. Session cardinality: RESOLVED
+
+Current dotli reads host-papp's `sessions` list but effectively restores the first session
+(`sessions[0]`). **Decision:** v1 `SessionStore` is single-session only: one optional opaque blob, replaced
+on successful pairing and cleared on logout. Do not preserve host-papp's multi-session `Vec<Session>` shape
+as part of the migration.
+
+## E12. Corrupted persisted sessions: RESOLVED
+
+If `SessionStore.read()` returns bytes that are unreadable, schema/version-invalid, or fail decode,
+the core clears the store, logs/emits diagnostics, and remains disconnected. **Decision:** invalid
+persisted session data behaves like no session; it must not brick startup or create a partial connected
+state.
+
+## E13. Persisted-session encryption: RESOLVED
+
+The persisted session blob contains secret material, but v1 relies on host storage security rather than
+adding Rust-side encryption/MAC around the blob. **Decision:** `SessionStore` is a host trust boundary:
+the host is responsible for confidentiality and tamper resistance. Rust owns schema encoding and restore
+validation, but writes the opaque encoded blob as-is.
+
+## E14. dotli web SessionStore key/path: RESOLVED
+
+Current dotli routes host-papp storage through the shared host-origin path
+(`host.<root-domain>` localStorage via the protocol iframe) using `PAPP_<siteId>_<key>` keys such as
+`SsoSessions`. **Decision:** reuse the shared host-origin storage route for dotli web, but use a new
+Rust-owned key/prefix such as `TRUAPI_SESSION_<siteId>`. Do not reuse `PAPP_*` or `SsoSessions`, because
+the Rust session blob is single-session and core-defined.
+
+## E15. SessionStore cross-tab updates: RESOLVED
+
+Current dotli's storage adapter preserves cross-tab updates through `subscribeSharedAuthStorage` /
+BroadcastChannel behavior. **Decision:** v1 `SessionStore` supports current-then-changes coarse change
+notifications for both same-runtime writes/clears and cross-tab/process changes. The first tick tells the
+core to call `read()` for startup state; future ticks do the same. Clear therefore maps to
+`read() == None` -> in-memory `clear_session` + `Disconnected`; valid write replaces the current in-memory
+session. Invalid read follows E12. The core may dedupe equivalent blobs/session ids before rebroadcasting.
+
+## E16. Logout API ownership: RESOLVED
+
+Hosts need a direct UI action for disconnect/logout. **Decision:** expose a public core logout/disconnect
+API through WASM, UniFFI, and JS worker surfaces. The core owns lifecycle policy: tear down session-channel
+subscriptions and pending request waiters, clear in-memory `SessionState`, clear `SessionStore`, broadcast
+`Disconnected`, and tolerate idempotent logout. Hosts should not call `SessionStore.clear()` directly as
+the public logout path.
+
+## E17. SSO logout message: RESOLVED
+
+The SSO message enum already has `disconnected`. There is no separate wallet channel or connection:
+pairing and post-pairing peer communication happen only through the SSO session protocol over the
+People-chain statement store. **Decision:** local public logout best-effort sends an SSO session-channel
+`disconnected` message before teardown when the session channel is usable, but local cleanup must not hang
+or fail if the SSO send fails.
+
+## E18. Peer-originated SSO disconnect cleanup: RESOLVED
+
+When the SSO peer sends `disconnected`, the core should not preserve the persisted session. **Decision:**
+peer-originated SSO disconnect routes through the same cleanup path as local logout: tear down SSO channel
+state, clear in-memory `SessionState`, clear `SessionStore`, and broadcast `Disconnected`.
+
+## E19. Pending SSO requests on disconnect: RESOLVED
+
+Current dotli does not maintain a separate UI-level cancel token for session-channel work. Local logout
+calls `adapter.sessions.disconnect(session)` and then sets auth state to idle; dotli's debug contract says
+session-channel teardown produces `session:host_action_failed` for host-originated actions and
+`session:terminated` stops further peer/host actions for that session. The host-papp session wrapper
+also applies a 180s queue timeout to signing, raw signing, create-transaction, and
+resource-allocation requests; dotli's signing/transaction modals add a 300s outer fallback. Alias adds no
+separate timeout in current dotli. Resource allocation keeps its modal open for retry after an SSO
+failure. **Decision:** Rust owns this lifecycle explicitly: local logout or peer `disconnected` tears down
+subscriptions and pending waiters so no operation can hang forever; per-method errors preserve current
+dotli's typed shape (`Rejected` for local signing/transaction modal cancel, `Unknown { reason }` for
+session-channel failure where no narrower host-api error exists).
diff --git a/docs/design/host-contract-and-core-impl/F - novasamatech-removal.md b/docs/design/host-contract-and-core-impl/F - novasamatech-removal.md
new file mode 100644
index 00000000..402823d8
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/F - novasamatech-removal.md	
@@ -0,0 +1,116 @@
+# F - `@novasamatech` removal checklist (dotli side)
+
+> Part of the [host-contract & core-impl spec](index.md).
+
+Source of truth for the original audit was the dotli checkout at `~/github/dotli` (`85c9733`, dirty
+worktree ignored). The latest refresh uses `hosts/dotli` `origin/main` at `4611008` (2026-06-09), where
+host-papp has moved to 0.8.6 and SSO V2. Implementation status below tracks the migrated `hosts/dotli`
+submodule on this branch.
+
+Current dotli depends on:
+
+- `@novasamatech/host-api` `0.8.6`
+- `@novasamatech/host-container` `0.8.6`
+- `@novasamatech/host-papp` `0.8.6`
+- `@novasamatech/statement-store` `0.8.6`
+- `@novasamatech/sdk-statement` `^0.6.0`
+- `@novasamatech/storage-adapter` `0.8.6`
+
+Handlers that current dotli explicitly leaves unimplemented, such as payment and full
+`create_account_proof`, are not blockers for this removal. They stay unavailable until another host needs
+them.
+
+## Order of removal
+
+```
+  Tier 1-3.5 land  ->  all Nova packages drop together:
+                       host-api + host-container                         (Rust host wire + generated
+                          TrUAPI codecs replace the JS container)
+                       host-papp                                          (pairing, signing,
+                          transaction construction, alias, resource
+                          allocation, entropy move to core/session channel)
+                       statement-store + sdk-statement                    (submit/subscribe/proof and
+                          mappings move to core + @parity/truapi types)
+                       storage-adapter                                    (local shared-auth storage
+                          interface becomes dotli/core-defined)
+```
+
+## Checklist (exact refs)
+
+- [x] `packages/ui/src/container.ts`: replace `createIframeProvider`, `createContainer`,
+      `createRateLimiter`, `deriveProductEntropy`, `Container`, `Provider`, and all `host-api` error/type
+      imports with the Rust worker bridge and generated TrUAPI codecs. The migrated submodule no longer
+      has `container.ts`; `packages/ui/src/bridge.ts` uses the Rust worker bridge.
+- [x] Nested dApps: do not port `setupNestedBridgeDetector` as separate Rust runtimes/sessions/product
+      identities for v1. If nested message forwarding remains, route it through the shared top-level Rust
+      core. Track future nested-product usefulness in [I](<I - nested-dapps.md>).
+- [x] Preserve current `container.ts` handler coverage in Rust before removing the JS handlers:
+      account get/legacy/user-id/login/alias, signing, legacy signing, `create_transaction`, resource
+      allocation, local storage, entropy, navigation, device/product permissions, notifications,
+      statement-store submit/subscribe/proof, preimage submit/lookup, theme subscription, feature support,
+      and chain connection/status. Evidence: product-visible core methods are implemented on
+      `PlatformRuntimeHost` in `rust/crates/truapi-server/src/runtime.rs`; host-owned primitives are
+      exposed as platform traits in `rust/crates/truapi-platform/src/lib.rs`; WASM/TS callback coverage is
+      generated and adapted in `js/packages/truapi-host-wasm/src/generated/host-callbacks.ts`,
+      `js/packages/truapi-host-wasm/src/runtime.ts`, and
+      `js/packages/truapi-host-wasm/src/typed-callbacks.ts`; dotli wires the concrete host callbacks
+      through `packages/ui/src/host-callbacks/handlers.ts`. Payment and full `create_account_proof` remain
+      explicit `Unsupported` per the separate deferred checklist item below.
+- [x] `js/packages/truapi-host-wasm`: delete transitional raw callback routes for methods now owned by
+      Rust (`accountGet`, `accountGetAlias`, `accountCreateProof` if still unavailable, `getLegacyAccounts`,
+      `getUserId`, `signPayload`, `signRaw`, `statementStoreSubscribe`, `statementStoreSubmit`,
+      `statementStoreCreateProof`, and any preimage route that has moved behind the final host-side
+      primitive). The final bridge should expose only true platform callbacks plus `chainConnect` and
+      frame transport.
+- [x] `truapi-server` WASM/UniFFI surfaces: remove `setActiveSession` / `clearActiveSession` as product
+      lifecycle APIs after core-owned SSO restore/logout lands. They are account-only PR-104 scaffolding
+      and cannot restore `ss_secret`, P-256 key material, peer keys, or session topics.
+- [x] Keep explicit unavailable behavior for current dotli-unimplemented handlers: payment and full
+      `create_account_proof`.
+- [x] `packages/auth/src/auth.ts`: remove `createPappAdapter`, `PappAdapter`, `PairingStatus`,
+      `Identity`, `UserSession`, `createLazyClient`, `createPapiStatementStoreAdapter`,
+      `StatementStoreAdapter`, `Statement`, and `toHex` once pairing/session restore/statement-store are
+      core-owned. The migrated submodule deletes `packages/auth`.
+- [x] dotli logout/disconnect UI: call the Rust core public logout/disconnect API. Do not clear the
+      `SessionStore` directly from UI code; core owns teardown, storage clear, and `Disconnected`
+      broadcast. `packages/ui/src/topbar.ts` emits `dotli:truapi-disconnect-request`,
+      `packages/ui/src/bridge.ts` routes that to `coreProvider.disconnect()`, and
+      `packages/ui/tests/topbar.test.ts` locks the topbar event path.
+- [x] `packages/auth/src/signing.ts`: remove `UserSession` and `host-api` error/type imports once signing,
+      legacy signing, and `create_transaction` are core session-channel requests. Keep or rewrite only the
+      dotli confirmation modals if they remain host UI around core calls. The migrated submodule deletes
+      `packages/auth`; confirmation UI lives in Rust host callbacks.
+- [x] `packages/auth/src/account.ts`: port product account derivation to Rust and vector-test it. Match the
+      current chain-code rule exactly: numeric junctions use SCALE `u64`, string junctions use SCALE `str`,
+      values longer than 32 bytes are `blake2b(..., dkLen=32)`, and shorter values are right-padded to 32.
+      The migrated submodule deletes `packages/auth`; product derivation is in `truapi-server`.
+- [x] `packages/auth/src/shared-storage.ts`: replace the type-only `StorageAdapter` import with a local or
+      core-owned storage interface. Core session persistence is not host-papp session-list compatible and
+      cutover requires one-time re-pair ([E5](<E - open-questions.md>)). The migrated submodule deletes
+      `packages/auth` and uses the Rust-owned `SessionStore`.
+- [x] SSO V2 parity: use host-papp 0.8.6's `VersionedHandshakeProposal::V2`, including host metadata
+      entries, platform type/version, V2 pairing topic/channel, V2 response envelope handling, and
+      `rootEntropySource` persistence.
+- [x] `packages/ui/src/statement-store-mapping.ts`: delete the SDK<->host mapping once Rust emits/accepts
+      the final TrUAPI statement-store wire types directly.
+- [x] `packages/ui/src/permissions.ts`, `packages/ui/src/allocation-modal.ts`, and any modal code importing
+      `@novasamatech/host-api`: replace SDK enum/error/types with generated Rust/TrUAPI-facing types.
+- [x] `packages/ui/src/topbar.ts`: remove type-only `Identity`, `__NOVASAMATECH_VERSIONS__`, and the
+      `NOVASAMATECH_ALLOWLIST` diagnostics once auth/debug data comes from the Rust bridge.
+- [x] `packages/truapi-debug`: replace `onHostApiDebugMessage` and `onHostPappDebugMessage` with Rust
+      bridge debug events, then drop the debug package dependencies on `host-api`, `host-container`, and
+      `host-papp`. The migrated submodule no longer has this package or runtime Nova debug imports.
+- [x] `apps/host/vite.config.ts`: delete `define.__NOVASAMATECH_VERSIONS__` and the `manualChunks` branch
+      that returns `"nova-scale"` for `@novasamatech/scale`.
+- [x] `packages/protocol/src/auth-storage.ts`: delete `EMPTY_SHARED_AUTH_SESSION_LIST = "0x00"` and
+      host-papp session-list compatibility notes; the core uses its own persisted `SessionInfo` through a
+      host-global `SessionStore`, not product-scoped local storage. dotli web should keep the shared
+      host-origin storage route but move to a Rust-owned key/prefix such as `TRUAPI_SESSION_<siteId>`,
+      not `PAPP_*` / `SsoSessions`, and preserve cross-tab change notifications for logout/re-pair.
+- [x] `package.json` deps: remove `@novasamatech/host-api`, `host-container`, `host-papp`,
+      `sdk-statement`, `statement-store`, and `storage-adapter` from `packages/ui`, `packages/auth`, and
+      `packages/truapi-debug` when no `rg "@novasamatech"` value/type imports remain.
+- [x] Docs and README: update `README.md` host-container/debug descriptions and any dotli migration notes
+      to describe the Rust bridge and core-owned SSO/session protocol. `hosts/dotli/README.md` now
+      describes the `@parity/truapi-host-wasm` worker bridge, core-owned SSO/session lifecycle, and nested
+      dApp cutover decision; `docs/local-e2e-testing.md` documents the `truapi:logLevel` Rust bridge toggle.
diff --git a/docs/design/host-contract-and-core-impl/G - annex.md b/docs/design/host-contract-and-core-impl/G - annex.md
new file mode 100644
index 00000000..f0d815f9
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/G - annex.md	
@@ -0,0 +1,173 @@
+# G - Annex: conventions & wiring reference
+
+> Part of the [host-contract & core-impl spec](index.md). Shared mechanics referenced by
+> [A](<A - host-primitives.md>) (host primitives) and [B](<B - core-impls.md>) (wire methods). Read the
+> relevant spec first; come here for the recipe.
+
+## Platform trait conventions
+
+`truapi-platform` currently defines seven capability traits (`Storage`, `Navigation`, `Notifications`,
+`Permissions`, `Features`, `ChainProvider`, `JsonRpcConnection`) plus a `Platform` supertrait
+blanket-impl'd over the first six (`truapi-platform/src/lib.rs:31-130`). This plan adds more traits,
+including host-global `SessionStore`. A new capability trait must:
+
+- **Be RPITIT async, not `async-trait`:** `fn name(&self, ...) -> impl Future<Output = Result<T, E>> + Send;`.
+- **Be bound `: Send + Sync`** and added to the `Platform` supertrait + its blanket impl (lib.rs:122-130).
+- **Use concrete `truapi::v01` / `versioned` error types** (re-exported at lib.rs:25-27), never
+  `CallError`; the runtime maps them to `CallError`.
+- **Reuse existing `v01` payload types** where one fits, so the byte bridge needs no new SCALE type.
+
+## Adding a host primitive: the five layers
+
+Use this recipe only for capabilities the Rust core **cannot** perform itself: UI presentation, OS
+services, persistence, and chain connections. Do **not** use it for account reads, signing, transaction
+construction, alias, product statement-store, or SSO pairing internals; those are core methods in
+[B](<B - core-impls.md>) and should remove the transitional raw JS callbacks that PR 104 shipped.
+
+```
+ (1) truapi-platform/src/lib.rs        trait method  + add to Platform supertrait (lib.rs:122-130)
+ (2) truapi-server/src/runtime.rs      PlatformRuntimeHost calls it via UFCS alias, maps -> CallError
+ (3a) truapi-server/src/wasm.rs        JsBridge field + from_js("camelName") + WasmPlatform impl + invoker
+ (3b) truapi-server/src/native.rs      HostCallbacks method + CallbackPlatform impl   (run `make uniffi`)
+ (4) js .../truapi-host-wasm           WasmRawCallbacks field + createUnavailableCallbacks stub
+                                       + worker-protocol CallbackName + worker-runtime forward + main dispatch
+ (5) host (dotli)                      supply the callback in the object passed to the core
+```
+
+Callback round-trip across the Web Worker boundary (trace of `localStorageRead`):
+
+```
+ WASM core (in worker)              worker-runtime.ts            main thread (create-worker-host-runtime)
+   raw.localStorageRead(key) --> callbackRequest(name,args) --> { kind:"callbackRequest", id, name, args }
+        ^                            stores resolver in                       |
+        |                            pendingCallbacks[id]            state.rawCallbacks[name](...args)
+   Promise resolves <-- pendingCallbacks[id].resolve <-- { kind:"callbackResponse", id, ok, value/error }
+```
+
+PR 104's JS package still exposes byte-oriented `WasmRawCallbacks`, including transitional
+`accountGet`/`signPayload`/`statementStore*`/`preimageLookupSubscribe` callbacks. Treat those as
+scaffolding for unsupported methods, not the destination. For any method moved into the Rust core, delete
+the corresponding raw callback name from:
+
+- `js/packages/truapi-host-wasm/src/runtime.ts` (`WasmRawCallbacks`, `createUnavailableCallbacks`);
+- `js/packages/truapi-host-wasm/src/worker-protocol.ts` (`CallbackName` / `SubscriptionName`);
+- `js/packages/truapi-host-wasm/src/worker-runtime.ts` forwarding;
+- `js/packages/truapi-host-wasm/src/web/create-worker-host-runtime.ts` main-thread dispatch;
+- dotli's callback object.
+
+For genuine host primitives, request callbacks pass/return raw SCALE bytes (`Uint8Array`) or `boolean`;
+the typed->raw SCALE adapter is intentionally **not** in the JS package (`runtime.ts:3-11`), so a host
+currently supplies byte-oriented callbacks directly. Rust invokers today include `invoke_unit` (bytes in /
+void), `invoke_bool` (bytes in / bool), `invoke_local_storage_read` (key in / `Option<Vec<u8>>`), and the
+`chainConnect` bridge for bidirectional JSON-RPC. Add only the minimum invoker shape required by the new
+primitive.
+
+Per-primitive checklist:
+
+- [x] Trait in `truapi-platform/src/lib.rs`; add to `Platform` supertrait + blanket impl.
+      Current traits cover `SessionStore`, `UserConfirmation`, `ThemeHost`, `PreimageHost`, notification
+      id/cancel, and the existing storage/navigation/permission/feature/chain surfaces.
+- [x] `WasmPlatform` impl + `JsBridge` field + `from_js` key + invoker.
+      `truapi-server/src/wasm.rs` now extracts the callback keys, invokes optional stream callbacks, and
+      maps notification ids, session store, theme, preimage, and confirmation callbacks.
+- [x] `HostCallbacks` method + `CallbackPlatform` impl; native shells expose the same host primitive set.
+      `truapi-server/src/native.rs` has UniFFI callback methods plus `CallbackPlatform` delegation for
+      notification id/cancel, session store, theme, preimage, confirmation, feature, and storage callbacks.
+- [x] `WasmRawCallbacks` field + `createUnavailableCallbacks` stub.
+      `js/packages/truapi-host-wasm/src/runtime.ts` exposes only platform callbacks plus chain/frame
+      transport; removed product-owned account/signing/statement raw routes stay deleted.
+- [x] `CallbackName`/`SubscriptionName` + `worker-runtime.ts` forward + main-thread callback dispatch.
+      `js/packages/truapi-host-wasm/src/worker-protocol.ts`,
+      `js/packages/truapi-host-wasm/src/worker-runtime.ts`, and
+      `js/packages/truapi-host-wasm/src/web/create-worker-host-runtime.ts` forward request and subscription
+      callbacks that cannot run inside the worker.
+- [x] Update both test stubs (`runtime.rs`, `core.rs`, plus `wire_result_shape.rs`) so they still satisfy
+      `Platform`.
+- [x] Wire the `truapi::api::*` method to the new trait in `runtime.rs` (the [B](<B - core-impls.md>) side).
+      Product-visible methods call platform traits only for host-owned primitives; account, signing,
+      statement-store, pairing/session, entropy, and chain runtime logic remain core-owned.
+
+## Implementing a core-owned wire method
+
+For account/signing/statement-store methods, the work is different from adding a host primitive:
+
+1. Add core state or helpers under `truapi-server/src/host_logic/` (`sso`, `statement_store`,
+   `message_exchange`, `proofs`, `key_derivation`, etc.).
+2. Add fields to `PlatformRuntimeHost<P>` for the shared state/service handles, not JS callbacks.
+3. Override the relevant `truapi::api::*` trait method in `runtime.rs`, preserving versioned request/response
+   wrappers and domain error mapping.
+4. If the method needs host UI or storage, call a small platform capability from [A](<A - host-primitives.md>)
+   (`PairingPresenter`, `SessionStore`, resource allocation confirmation), then continue protocol logic
+   in Rust.
+5. Remove the matching transitional `WasmRawCallbacks`/worker/dotli callback route.
+
+This is the path for `request_login`, `get_account`, signing, create transaction, alias,
+statement-store submit/subscribe/proof, entropy, and core-owned logout.
+
+## Adding runtime configuration
+
+Static values that are known when the host runtime is constructed are not platform traits. Thread them as
+constructor/config state instead:
+
+- `truapi-server/src/runtime.rs`: add a config field to `PlatformRuntimeHost<P>` and pass it through
+  `new` / `TrUApiCore::from_platform`.
+- `truapi-server/src/wasm.rs`: accept the config from JS when constructing the WASM core; validate byte
+  lengths and URL invariants at the boundary.
+- `truapi-server/src/native.rs`: expose equivalent UniFFI constructor/config fields.
+- `js/packages/truapi-host-wasm`: add the config to in-process, Node, and worker runtime creation options;
+  forward it in the worker init frame.
+- dotli: create one runtime per top-level product iframe/container. Pass `calling_product_id`
+  (`labelToProductIdentifier(label)` parity), `product_label`, `pairing_metadata_url` computed from the
+  current origin using the existing host-papp rule, the People-chain genesis hash, and the production/dev
+  deeplink scheme. Nested dApps are not separate Rust runtime instances for v1; if the host keeps nested
+  message forwarding, route those messages through the same core/product context. Track the usefulness and
+  any future independent nested-product model in [I](<I - nested-dapps.md>).
+
+Current-parity host-container surfaces ([A3](<A - host-primitives.md>)) use the five-layer primitive
+recipe above rather than runtime config:
+
+- SessionStore is a host-global secret persistence capability for opaque core-owned bytes encoding the
+  full `SessionInfo`; keep it separate from product-scoped `Storage` and do not expose typed session
+  fields across JS/UniFFI. It includes a current-then-changes coarse notification stream for same-runtime
+  writes/clears and cross-tab/process logout/re-pair propagation; each tick causes the core to call
+  `read()`, with core-side dedupe for equivalent blobs/session ids. Wire it like other host-to-core
+  streams rather than as a one-shot callback.
+- Notifications need a response id plus cancel support, so the existing `Notifications` trait shape must
+  change.
+- Theme needs a subscription callback/channel.
+- Preimage submit/lookup should stay host-side but be routed through Rust once the JS container is gone.
+- Resource allocation needs a dedicated host confirmation UI callback before the core sends the
+  SSO session request. Keep it separate from `Permissions::remote_permission`; it is approval UI around a
+  retry-capable SSO operation, not a cached permission decision.
+
+## Implementing a wire method: the override template
+
+Wire methods are implemented on `PlatformRuntimeHost<P>` (`runtime.rs`). Copy this shape (from
+`LocalStorage::read`, `runtime.rs:269-281`): destructure the versioned request, call the platform via the
+UFCS alias, wrap the response `V1`, map the error.
+
+```rust
+async fn read(
+    &self, _cx: &CallContext, request: HostLocalStorageReadRequest,
+) -> Result<HostLocalStorageReadResponse, CallError<HostLocalStorageReadError>> {
+    let HostLocalStorageReadRequest::V1(v01::HostLocalStorageReadRequest { key }) = request;
+    PlatformStorage::read(self.platform.as_ref(), key)
+        .await
+        .map(|value| HostLocalStorageReadResponse::V1(v01::HostLocalStorageReadResponse { value }))
+        .map_err(|err| CallError::Domain(HostLocalStorageReadError::V1(err)))
+}
+```
+
+Rules:
+
+- Platform traits are imported under aliases (`Storage as PlatformStorage`, etc., runtime.rs:68-71) to
+  avoid clashing with `truapi::api::*`.
+- Domain errors map to `CallError::Domain(Err::V1(inner))`; infra failures to
+  `CallError::HostFailure { reason }`; not-yet-wired to `CallError::unavailable()`.
+- For multi-step host logic, follow `PermissionsService` (a struct over `&` platform borrows,
+  permissions.rs:36) and the `request_remote_permission` override (runtime.rs:241-258).
+- New in-core state goes on `PlatformRuntimeHost<P>` (runtime.rs:75-84) + `new` (runtime.rs:90-100); new
+  host-logic modules under `host_logic/` declared in `host_logic/mod.rs`.
+- The `Foo::V1(inner)` destructure is irrefutable while a domain stays single-version. Multi-version
+  envelopes (post-merge `versioned_type!`) use `Versioned`/`IntoLatest`/`FromLatest`; out of scope for
+  the v0.1 tickets here.
diff --git a/docs/design/host-contract-and-core-impl/H - sso-pairing-protocol.md b/docs/design/host-contract-and-core-impl/H - sso-pairing-protocol.md
new file mode 100644
index 00000000..363cdffa
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/H - sso-pairing-protocol.md	
@@ -0,0 +1,231 @@
+# H - SSO pairing & message-exchange protocol
+
+> Part of the [host-contract & core-impl spec](index.md). Foundational: `request_login`, signing,
+> transaction construction, resource allocation, ring-VRF alias, and the product statement store all ride
+> this one mechanism. Read this before
+> [A](<A - host-primitives.md>) / [B](<B - core-impls.md>).
+>
+> Source of truth for the current protocol is dotli main's pinned
+> `@novasamatech/host-papp@0.8.6` / `@novasamatech/statement-store@0.8.6` web
+> code plus the iOS wallet. Current-dotli parity uses SSO V2.
+> (`~/github/polkadot-app-ios-v2`), the peer that implements the other side in readable Swift. We define
+> the **web/core** side.
+
+## Why (before the what)
+
+A sandboxed web product must act for a user whose signing keys live in a phone wallet, with **no shared
+backend** between them. The solution: both sides rendezvous on the **People-chain statement store** (a
+gossip pallet that distributes signed SCALE `Statement`s P2P) and talk over it with an
+application-layer-encrypted channel. A QR code bootstraps the rendezvous.
+
+```
+   web product  <--- encrypted SCALE statements on derived topics --->  phone wallet
+                     (People-chain statement-store pallet, P2P gossip)
+                            ^ no relay server, no shared backend
+```
+
+Three consequences shape the core API:
+
+1. **There is exactly one transport.** Pairing, transaction/raw signing, ring-VRF alias, resource
+   allocation, and the product-facing statement store are all carried as statements on the same
+   People-chain connection. The core reaches it through the **existing `ChainProvider`** platform trait
+   (connect to People-chain, then `statement_submit` / `statement_subscribeStatement` JSON-RPC). No new
+   transport primitive is needed.
+2. **The wallet keeps every signing key and only ever signs on request.** During the handshake it sends
+   _public_ keys + account ids, never a secret (confirmed in the iOS source). Transaction signing and
+   ring-VRF run as request/response messages over the channel: the core asks, the wallet signs, the
+   wallet replies. So signing is **not** a host primitive that "reaches the wallet"; it is core protocol.
+3. **It is a cryptographic protocol, so the core owns it.** Challenge keys, ECDH, channel encryption,
+   topic derivation, and proof verification are protocol logic. The host's only job is to **render the
+   QR** ([A1](<A - host-primitives.md>)) and provide the chain connection (`ChainProvider`). The core
+   cannot be lied to about identity because it verifies the statements itself.
+
+Net effect on the SSO host contract: the only new protocol primitive is the QR presenter. `host-papp` is
+fully replaceable by core message-exchange logic, which resolves [E2](<E - open-questions.md>). Separate
+host-container parity surfaces such as notifications, theme, and preimage are covered in
+[A3](<A - host-primitives.md>).
+
+## What the core holds vs. what the wallet holds
+
+| Generated/held by the **core** (web side)                                                                            | Generated/held by the **wallet**                                                                          |
+| -------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------- |
+| session **sr25519 statement-store keypair** (signs all the core's outgoing statements; its secret is the `ssSecret`) | root + identity **sr25519 keypairs** (sign transactions; never leave the device)                          |
+| **P-256 (secp256r1) ECDH keypair** (channel encryption; `encryptionPublicKey` = X9.63 uncompressed, 65 bytes)        | persistent **P-256 chat keypair** (`sharedSecretDerivationKey`, the public half is sent in the handshake) |
+| derived session ids + channel ids; the peer's public keys + account ids                                              | the ring (bandersnatch) secret (ring-VRF alias derivation)                                                |
+
+The wallet grants the core's statement-store account **allowance** to submit (a `resourceAllocation`
+message), which is why the core can submit product statement proofs signed by its own session key.
+
+## The protocol
+
+### Statement wire format (People-chain statement store)
+
+A `Statement` is a SCALE struct of indexed `StatementField`s, sorted by index before signing:
+`proof`(0) = `Sr25519 { signature:[u8;64], signer:[u8;32] }`, `expiry`(2):u64, `channel`(3):[u8;32],
+`topic1..4`(4..7):[u8;32], `scaleEncodedPayload`(8):bytes. The `proof` is an sr25519 signature over the
+SCALE of every field except the proof; `signer` is the submitter's 32-byte sr25519 public key. `expiry`
+doubles as priority (`0xFFFF_FFFF_0000_0000 | (unixSecs - EPOCH)`, monotonic) so a newer statement
+replaces an older one on the same topic+channel. RPC: `statement_submit(hex)` /
+`statement_subscribeStatement({topic_filter:{matchAll:[topic]}})` / `statement_unsubscribeStatement`.
+
+### 1. Handshake bootstrap (the QR)
+
+The core mints a session statement-store sr25519 keypair and a P-256 ECDH keypair, reads the static
+pairing runtime config ([A2](<A - host-primitives.md>)), then builds the deeplink the QR encodes:
+
+```
+VersionedHandshakeProposal::V2 {   # SCALE enum, index 1
+    device: {
+        statement_account_id: [u8;32]     # core session sr25519 account id
+        encryption_public_key: [u8;65]    # core P-256 pubkey, X9.63 uncompressed
+    }
+    metadata: Vec<(MetadataKey, String)>  # HostName required; HostVersion, HostIcon,
+                                          # PlatformType, PlatformVersion optional
+}
+deeplink = runtime_config.scheme + "pair?handshake=" + hex(SCALE(VersionedHandshakeProposal))
+```
+
+The bootstrap topic is keyed BLAKE2b-256 with key = the core's statement-store pubkey. The V2 channel
+uses the same inputs with suffix `"channel"`; the Rust request-login path currently subscribes by topic and
+tracks the remote subscription slot:
+
+```
+topic = blake2b_256_keyed(key = ss_pubkey, msg = enc_pubkey ++ b"topic")
+channel = blake2b_256_keyed(key = ss_pubkey, msg = enc_pubkey ++ b"channel")
+```
+
+The core renders the QR via [A1 `PairingPresenter`](<A - host-primitives.md>) and subscribes to `topic`.
+
+### 2. Wallet answer
+
+The wallet scans, decodes `VersionedHandshakeProposal::V2`, displays the embedded metadata, and submits
+V2 responses to `(topic, channel)`, signed by its sr25519 statement account. Pending status can arrive
+before success while allowance allocation is in progress:
+
+```
+VersionedHandshakeResponse::V2 {   # SCALE enum, index 1
+    encrypted_message: bytes       # AES-GCM(ephemeral ECDH) of EncryptedHandshakeResponseV2
+    public_key:        [u8;65]     # the wallet's ephemeral P-256 pubkey (X9.63)
+}
+
+EncryptedHandshakeResponseV2 =
+    Pending(AllowanceAllocation)
+  | Success {
+        identity_account_id:        [u8;32]
+        root_account_id:            [u8;32]  # product-account derivation root
+        identity_chat_private_key:  [u8;32]
+        sso_enc_pub_key:            [u8;65]  # wallet persistent P-256 pubkey
+        device_enc_pub_key:         [u8;65]
+        root_entropy_source:        [u8;32]
+    }
+  | Failed(String)
+}
+```
+
+The core receives the statement (verifying its sr25519 proof), runs ECDH(`core_enc_priv`,
+`ephemeral_pubkey`) -> HKDF-SHA256 -> AES-GCM to decrypt. It skips `Pending`, maps `Failed(reason)` to the
+login error path, and on `Success` stores the wallet's persistent SSO P-256 key, root account id,
+identity account id, and root entropy source. The current web construction is in [D4](<D - crypto-foundation.md>): ECDH uses the
+X coordinate from P-256 `getSharedSecret`, HKDF-SHA256 uses empty `salt`/`info` and `len=32`, and
+AES-GCM prepends a 12-byte nonce to ciphertext+tag.
+
+### 3. Session establishment
+
+A steady-state shared secret is derived by ECDH between the persistent P-256 keys
+(`core_enc_priv` x `sso_enc_pub_key`). From it, directional 32-byte session ids and the channel ids:
+
+```
+session_id.own  = H(key = shared_secret, msg = b"session" ++ own_acct ++ peer_acct ++ pin(own) ++ pin(peer))
+session_id.peer = H(key = shared_secret, msg = b"session" ++ peer_acct ++ own_acct ++ pin(peer) ++ pin(own))
+request_channel  = H(key = session_id.own,  msg = b"request")    # core -> wallet
+response_channel = H(key = session_id.own,  msg = b"response")   # wallet ACK / response to core request
+peer_request_ch  = H(key = session_id.peer, msg = b"request")    # wallet -> core (filter)
+```
+
+`H` is keyed BLAKE2b-256 (`blake2b(message, { dkLen: 32, key })`). A missing pin contributes the
+separator string `"/"` in current dotli's `createSessionId`.
+
+The core subscribes `topic1 == session_id.peer` (filtered to the wallet's account id as the only valid
+signer) for inbound, and submits with `topic1 == session_id.own`.
+
+### 4. Encrypted message framing
+
+Steady-state messages are AES-GCM encrypted under the session key and wrapped:
+
+```
+inner   = SCALE(StatementData)                 # enum: 0=request{request_id:String, messages:[Msg]}, 1=response{request_id:String, code:u8}
+sealed  = AES_GCM_seal(inner)                  # = nonce(12) ++ ciphertext ++ tag(16)
+payload = SCALE(sealed as bytes)               # length-prefixed -> the statement's scaleEncodedPayload(8)
+```
+
+The application messages are `PolkadotHostRemoteMessage { message_id: String, content: V1(ContentV1) }`
+where `ContentV1` is a SCALE-tagged enum: `disconnected`(0), `signingRequest`(1)/`signingResponse`(2),
+`aliasRequest`(3)/`aliasResponse`(4), `resourceAllocationRequest`(5)/`response`(6),
+`createTransactionRequest`(7)/`response`(8). Responses carry `request_message_id` + `HostResult<T>`
+(`success(T)`=0 / `failure(String)`=1).
+
+### 5. Operations after pairing (mapped to wire methods)
+
+| Wire method                                                         | Message                                                                                                     | Notes                                                                                                                                                                                                                                                                          |
+| ------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
+| `sign_payload`(116)                                                 | `signingRequest(transaction(SignTransactionPayload))` -> `Signature { raw_signature, signed_transaction? }` | wallet resolves `/product/<dotNs>/<idx>`, signs sr25519                                                                                                                                                                                                                        |
+| `sign_raw`(114)                                                     | `signingRequest(rawPayload(SigningRawPayload))`                                                             | `.bytes` or `.payload` (string wrapped `<Bytes>…</Bytes>`)                                                                                                                                                                                                                     |
+| `sign_payload_with_legacy_account` / `sign_raw_with_legacy_account` | same signing messages with product-derived account tuple                                                    | current dotli validates the legacy signer/address against `(calling_product_id, 0)` before forwarding                                                                                                                                                                          |
+| `create_transaction`(30)                                            | `createTransactionRequest`                                                                                  | wallet assembles + signs the extrinsic                                                                                                                                                                                                                                         |
+| `create_transaction_with_legacy_account`                            | same create-transaction message with product-derived signer tuple                                           | current dotli implements this and should remain parity                                                                                                                                                                                                                         |
+| `get_account_alias`(24)                                             | `aliasRequest { product_account_id, calling_product_id }` -> `ContextualAlias { context:[u8;32], alias }`   | bandersnatch `deriveAlias`, auto-handled (no prompt)                                                                                                                                                                                                                           |
+| `create_account_proof`(26)                                          | (full ring-VRF proof)                                                                                       | current dotli has no full-proof message; the SSO channel exposes `deriveAlias` only today                                                                                                                                                                                      |
+| `create_proof`(60) / `_authorized`(132)                             | none (in-core)                                                                                              | core signs the product `Statement` with its session sr25519 key (`ssSecret`); signer = the allowance-granted session account                                                                                                                                                   |
+| `subscribe`(56) / `submit`(62)                                      | none (in-core)                                                                                              | product statements over the same People-chain store the core is already on                                                                                                                                                                                                     |
+| `request_resource_allocation`                                       | `resourceAllocationRequest` -> response                                                                     | current dotli prompts, sends `callingProductId`, maps allowance dialects, and strips secret material from allocated results                                                                                                                                                    |
+| public logout/disconnect                                            | `disconnected`                                                                                              | best-effort send SSO peer message over the statement-store session channel, then tear down local session regardless of send result; peer-originated `disconnected` clears memory + `SessionStore`; any pending request/response waiters fail instead of waiting for a response |
+
+### Full sequence
+
+```
+ Web product / Core                 People-chain statement store              Wallet
+   request_login()
+   mint session sr25519 kp + P256 kp
+   build VersionedHandshakeProposal::V2; A1.present(QR) ------ scan ------------->| decode; show metadata
+   subscribe(topic = H(ss_pub, enc_pub++"topic"))                                 | approve
+                            <--- submit(topic, channel, VersionedHandshakeResponse::V2{enc, ephPub}) ---|
+   verify proof; ECDH(enc_priv, ephPub)->decrypt; skip Pending until Success
+     -> wallet persistent P256 pub, root_acct, identity_acct, root_entropy_source
+   shared_secret = ECDH(enc_priv, sso_enc_pub_key)
+   session_id.own/peer = H(shared_secret, "session"++..)
+   SessionState{ public_key=root_acct, ss_secret, root_entropy_source, ... }; persist; broadcast Connected
+   request_login -> Success
+ ---- steady state (signing) ----
+   sign_payload: submit(topic1=own, request_channel, enc(signingRequest)) ------>| sign /product/..
+                            <--- submit(topic1=wallet_own, response_channel, enc(signingResponse)) ---|
+   disconnect: best-effort submit(enc(disconnected)); stop subscriptions; fail pending waits; clear store
+```
+
+## What `SessionState` must hold (-> [C](<C - session-contract.md>))
+
+session sr25519 statement keypair (pub + secret = `ssSecret`); P-256 ECDH keypair; the wallet's
+`root_user_account_id` (= `public_key`, the product-account derivation root) and `identity_account_id`;
+the persistent peer P-256 pubkey; derived `session_id.own/peer`; and the SSO V2 `rootEntropySource` used
+for product entropy derivation. Usernames are **not** in the handshake; they come from a separate on-chain
+People-chain identity lookup keyed by `root_user_account_id`.
+
+## Crypto inventory (-> [D](<D - crypto-foundation.md>))
+
+sr25519 (schnorrkel): statement proof sign + peer-proof verify, product-account HDKD. **P-256
+(secp256r1) ECDH + HKDF-SHA256 + AES-GCM**: the channel. **Keyed BLAKE2b-256**: handshake topic,
+session ids, and request/response channels. `useragent-kit` is useful implementation precedent for
+similar Rust migrations, not a protocol authority for this byte contract. All must build for `wasm32`.
+
+## Vector-gated items
+
+These are no longer design questions for current dotli parity, but they still need golden vectors before
+implementation to catch byte-level mistakes:
+
+1. QR handshake SCALE/deeplink bytes, including optional host metadata fields.
+2. P-256 key generation from entropy-derived seed, ECDH X-coordinate extraction, HKDF-SHA256
+   empty-salt/info AES-GCM key derivation, and nonce+ciphertext framing.
+3. Keyed BLAKE2b-256 handshake topic, session id, and request/response channel derivation.
+4. Statement proof signing bytes: unsigned statement SCALE with compact length prefix stripped, 64-byte
+   expanded `ssSecret`, and `sr25519_sign(publicKey, secret, message)`.
+5. `create_account_proof`(26) remains deferred: current `RemoteMessageCodec` has alias request/response
+   messages only, not a full ring-VRF proof message.
diff --git a/docs/design/host-contract-and-core-impl/I - nested-dapps.md b/docs/design/host-contract-and-core-impl/I - nested-dapps.md
new file mode 100644
index 00000000..011cbc0f
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/I - nested-dapps.md	
@@ -0,0 +1,39 @@
+# I - Nested dApps note
+
+> Part of the [host-contract & core-impl spec](<index.md>). This is a non-blocking design note, not a v1
+> parity gate.
+
+Current dotli has a nested bridge detector in `~/github/dotli/packages/ui/src/container.ts`
+(`setupNestedBridgeDetector`). When a child iframe posts host-container bytes to `window.top`, dotli
+creates another JS `Container` for that source window.
+
+Observed current behavior:
+
+- The nested bridge gets a synthetic debug/container id like `<label>:nested-<n>`.
+- Handler wiring still receives the parent `label`, so account derivation, signing, aliases, entropy,
+  resource allocation, and permission prompts all use the parent product identity.
+- Local storage is the exception: nested bridges get a separate prefix,
+  `dotli:<label>:nested-<n>:`.
+
+## V1 Rust Migration Decision
+
+Nested dApps should use the shared Rust core. Do not create separate nested Rust runtimes, sessions,
+product identities, or storage namespaces as part of the `@novasamatech` removal milestone.
+
+If dotli keeps nested message forwarding during the migration, route nested messages into the same
+top-level product core/provider context. This preserves the important security property that nested
+content cannot silently become a different product identity, and avoids treating current JS storage-prefix
+behavior as a protocol contract.
+
+## Why Track It Separately
+
+The nested bridge may still be useful later:
+
+- product marketplaces embedding other products;
+- widgets that expect `window.top` host API access;
+- migration compatibility for existing products that already embed dApps;
+- future per-embedded-product permission and storage isolation.
+
+Those are broader product/runtime-policy questions, not prerequisites for current dotli feature parity.
+A future design can define an explicit nested-product identity model, including storage ownership,
+permission prompts, origin checks, and whether nested products get their own wallet-derived account path.
diff --git a/docs/design/host-contract-and-core-impl/J - implementation-plan.md b/docs/design/host-contract-and-core-impl/J - implementation-plan.md
new file mode 100644
index 00000000..d30330f0
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/J - implementation-plan.md	
@@ -0,0 +1,84 @@
+# J - Implementation plan
+
+> Part of the [host-contract & core-impl spec](<index.md>). This is the concrete build order for turning
+> PR 104's shared-core runtime substrate into a dotli-compatible Rust core with no `@novasamatech`
+> runtime dependencies.
+
+## Dependency graph
+
+```
+PR 104 runtime substrate
+  |
+  v
+RuntimeConfig + host primitive deltas
+  |
+  v
+Crypto/vector gate -----> product-account derivation
+  |                              |
+  v                              v
+Statement-store client ----> account reads
+  |
+  v
+SSO pairing + SessionStore restore/logout
+  |
+  v
+Session-channel request/response ops
+  |
+  +--> signing / create_transaction / alias / resource allocation
+  +--> statement-store proof / submit / subscribe
+  +--> entropy
+  |
+  v
+dotli bridge deletion + Nova dependency removal
+```
+
+## Work packages
+
+| WP | Scope | Deliverables | Verification |
+|---|---|---|---|
+| 0 | Lock the transition boundary from PR 104 | Mark `setActiveSession` / `clearActiveSession` and raw account/signing/statement callbacks as transitional; no new feature should depend on them | `rg "setActiveSession|clearActiveSession"` shows only compatibility/removal notes until WP 3 removes the APIs |
+| 1 | Runtime construction config | Add `RuntimeConfig` to `PlatformRuntimeHost`, WASM constructors, UniFFI constructors, and JS worker init; dotli passes product id/label, site id, SSO V2 host metadata, platform type/version, People genesis, deeplink scheme | Unit tests for config validation; worker protocol test proves config reaches WASM |
+| 2 | Host primitive deltas | Add `PairingPresenter`, `SessionStore`, resource allocation confirmation, theme subscription, preimage callbacks, notification id/cancel shape | `truapi-platform` bounds tests; WASM/native callback tests; generated TS/Kotlin/Swift bindings updated; same capability surface exists for WASM and UniFFI |
+| 3 | Crypto/vector gate | Add narrow WASM-safe crypto module/crate; capture JS/iOS vectors for HDKD, statement proof, QR SCALE, P-256/HKDF/AES-GCM, keyed BLAKE2b topics/session ids | Native + `wasm32-unknown-unknown` vector tests pass before pairing I/O starts |
+| 4 | Statement-store client | Implement People-chain `statement_submit`, `statement_subscribeStatement`, query/dump/live subscription plumbing over `ChainProvider` | Mock JSON-RPC tests for submit, historical dump, live stream, unsubscribe, topic limits |
+| 5 | SSO pairing, restore, logout | Implement `request_login`, QR presentation, host-papp 0.8.6 SSO V2 proposal/response handling, `rootEntropySource` persistence, `SessionInfo` persistence through `SessionStore`, current-then-change restore, public logout/disconnect | Pairing integration test with captured fixtures or wallet test peer; corrupted blob clears; cross-runtime store tick updates; logout clears store and pending waiters |
+| 6 | Account + identity methods | Implement `get_account`, `get_legacy_accounts`, `get_user_id`, connection status from real restored session | Dotli parity vectors for product account derivation; permission-gated user id tests |
+| 7 | Session-channel operations | Implement sign/raw sign, legacy signing, create transaction, alias, resource allocation; preserve current dotli error mapping and 180s request timeout semantics | Mock SSO peer tests for success/failure/timeout/disconnect; signer mismatch and permission denial tests |
+| 8 | Product statement-store methods | Implement `create_proof`, `create_proof_authorized`, `subscribe`, `submit` using the same client/session key | Proof vectors match `createSr25519Prover`; subscription paging preserves `is_complete` semantics |
+| 9 | Tier 3.5 dotli parity | Implement entropy, notification id/cancel, theme subscription, preimage host callbacks | Dotli handler parity tests for each currently implemented handler |
+| 10 | dotli integration + dependency removal | Replace `packages/ui/src/container.ts` bridge with Rust worker bridge; remove Nova packages, mappings, debug hooks, auth/session adapter, raw callback routes | `rg "@novasamatech"` has no runtime value/type imports in dotli packages; dotli login/sign/statement/preimage/manual flows pass |
+
+## Review slicing
+
+Keep each PR independently useful and reviewable:
+
+1. **Config + primitive surfaces:** WPs 1-2, no SSO crypto yet.
+2. **Crypto vectors:** WP 3 only; no network I/O.
+3. **Statement client + pairing:** WPs 4-5; core can pair/restore/logout but not yet sign.
+4. **Account/signing/message exchange:** WPs 6-7.
+5. **Statement-store + Tier 3.5 parity:** WPs 8-9.
+6. **dotli cutover:** WP 10, deleting JS/Nova code after the Rust path is proven.
+
+## Acceptance gates for the milestone
+
+- `make check`.
+- `cargo test --workspace --features ws-bridge`.
+- `cargo check -p truapi-server --target wasm32-unknown-unknown`.
+- `./scripts/codegen.sh && git diff --exit-code` for generated dispatcher/client/callback artifacts.
+- Native and wasm crypto vector tests pass.
+- dotli web can pair through SSO, restore across reload, logout, sign payload/raw, create transaction,
+  derive alias/account, submit/subscribe statements, create statement proofs, request resource allocation,
+  derive entropy, use preimage, receive/cancel notifications, and receive theme updates.
+- `truapi-server` has no dotli package imports, browser-global assumptions, host storage-key constants, or
+  UI component dependencies; dotli-specific behavior is confined to the dotli adapter/runtime config.
+- WASM and UniFFI expose the same core lifecycle: construct with `RuntimeConfig`, provide the same host
+  primitive set, restore through `SessionStore`, pair through `PairingPresenter`, and logout through the
+  core API.
+- dotli no longer has runtime dependencies on `@novasamatech/host-api`, `host-container`, `host-papp`,
+  `statement-store`, `sdk-statement`, or `storage-adapter`.
+
+## Deferred by design
+
+- Payment, Chat, CoinPayment, and full `create_account_proof` remain unavailable for current dotli parity.
+- Independent nested-product runtimes/sessions remain deferred; nested traffic, if kept, uses the shared
+  top-level Rust core for v1.
diff --git a/docs/design/host-contract-and-core-impl/index.md b/docs/design/host-contract-and-core-impl/index.md
new file mode 100644
index 00000000..6b616e91
--- /dev/null
+++ b/docs/design/host-contract-and-core-impl/index.md
@@ -0,0 +1,212 @@
+# TrUAPI host-contract additions & core-implementation spec
+
+**Status:** draft for review · **Goal:** run dotli on the Rust core with current dotli feature parity and
+no `@novasamatech` dependency, by defining the host primitives, core implementations, and package changes
+that close the gap. "Feature parity" here means the handlers implemented in current dotli main
+(`hosts/dotli` `origin/main` audited at `4611008` on 2026-06-09, with the older `~/github/dotli`
+checkout at `85c9733` used as implementation precedent where useful); handlers dotli currently leaves
+unimplemented stay out of scope until other hosts need them.
+
+This is the high-level overview. Each detail doc is written so a senior Rust engineer can pick it up as
+a ticket: exact signatures, file anchors, an implementation sketch, and acceptance criteria.
+
+## Relationship to PR 104
+
+PR 104 lands the shared-core **runtime substrate**: generated product clients, Rust dispatcher,
+`truapi-platform` traits, WASM/UniFFI/native bridges, and the first dotli architecture notes. It
+intentionally leaves account management, signing, statement-store, and preimage business logic
+unsupported or bridged through transitional byte callbacks.
+
+This spec is the follow-up implementation plan that turns that runtime substrate into the final shared
+Rust core used by dotli:
+
+- remove account-only session injection (`setActiveSession` / `clearActiveSession`) as a real lifecycle
+  path;
+- remove JS-owned account/signing/statement-store/raw preimage callback shims from the final dotli bridge;
+- add the missing host primitives the core genuinely cannot perform itself (`PairingPresenter`,
+  `SessionStore`, theme, notification id/cancel, preimage host content backend, allocation confirmation);
+- implement current-dotli parity inside `truapi-server` so `@novasamatech/host-container`,
+  `host-papp`, `statement-store`, `sdk-statement`, `host-api`, and `storage-adapter` can all disappear.
+
+The older PR docs (`docs/design/dotli-rust-core-proposal.md` and
+`docs/design/dotli-architecture-change.md`) describe the broad shared-core topology. Where they still
+show `(D1*)` account/signing/statement callbacks or session handoff as transitional steps, this directory
+is the more specific successor: those callbacks are removed once the core implementations in [B](<B - core-impls.md>)
+land.
+
+| Doc                                                              | Covers                                                                                                                                                                      |
+| ---------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| [H - SSO pairing protocol](<H - sso-pairing-protocol.md>)        | **Foundational.** The one transport (People-chain statement store) that pairing + signing + transaction construction + resource allocation + ring-VRF + statements all ride |
+| [A - Host primitives](<A - host-primitives.md>)                  | The new SSO callback (QR presenter), runtime product config, and host-container parity surfaces                                                                             |
+| [B - Core implementations](<B - core-impls.md>)                  | The migrated wire methods, current deferred set, per-method tickets + diagrams                                                                                              |
+| [C - Session contract](<C - session-contract.md>)                | `SessionState` extension, persistence/restore, the JS package gap                                                                                                           |
+| [D - Crypto foundation](<D - crypto-foundation.md>)              | wasm32 deps, the `get_account` derivation, the proof scheme, golden vectors                                                                                                 |
+| [E - Decision log / deferred questions](<E - open-questions.md>) | Resolved audit decisions plus non-parity deferred items                                                                                                                     |
+| [F - `@novasamatech` removal](<F - novasamatech-removal.md>)     | dotli-side cleanup, exact file:line list                                                                                                                                    |
+| [G - Annex](<G - annex.md>)                                      | Shared mechanics: trait conventions, the 5-layer wiring recipe, the override template                                                                                       |
+| [I - Nested dApps note](<I - nested-dapps.md>)                   | Current nested bridge behavior, usefulness, and why it is non-blocking for v1                                                                                               |
+| [J - Implementation plan](<J - implementation-plan.md>)          | Ordered work packages, review slicing, and acceptance gates                                                                                                                 |
+
+---
+
+## Architecture
+
+```
+  Product (sandboxed page / iframe / worker)
+     |  SCALE wire frames  (versioned v0.1 / v0.2)
+     v
+  +-------------------------------------------------------------+
+  | truapi-server  (the core; ships as WASM and via UniFFI)     |
+  |   generated dispatcher  ->  api::{Account,Signing,            |   <- protocol authority:
+  |                               StatementStore,Preimage,...}    |      pairing handshake + verify,
+  |   host_logic/  session . sso-pairing . message-exchange .     |      channel encryption, proof
+  |                proofs . key-derivation                        |      signing, session state
+  +----------------------+--------------------------------------+
+       platform traits   |  (truapi-platform, RPITIT async)
+                         v
+  +-------------------------------------------------------------+
+  | host shell  (dotli: web worker / electron / iOS / Android)  |
+  |   Storage Navigation Notifications Permissions Features      |   <- OS/UI primitives
+  |   ChainProvider Theme Preimage SessionStore                   |
+  |   PairingPresenter (QR UI)                                    |
+  |   ResourceAllocationConfirm                                   |
+  |   RuntimeConfig { calling_product_id, pairing inputs }        |
+  +----------------------+--------------------------------------+
+                         |  ChainProvider connection
+                         v
+            People-chain statement store  (statement_submit / _subscribe)
+                         ^  encrypted SCALE statements on derived topics (P2P gossip)
+                         v
+                 SSO peer / phone wallet  (holds root signing key + ring secret; signs on request)
+```
+
+The core is the protocol authority; the host is reduced to OS primitives. The load-bearing
+consequences:
+
+1. **One transport for the SSO session protocol.** Pairing, transaction/raw signing, transaction
+   construction, resource allocation, ring-VRF alias, and the product statement store are all SCALE
+   statements on the People-chain statement store, reached through the existing `ChainProvider` trait. The
+   core runs the SSO + message-exchange protocol itself ([H](<H - sso-pairing-protocol.md>)); there is no
+   relay server and no separate wallet socket.
+2. **Signing authority stays in the wallet, but signing is core protocol, not a host primitive.** The
+   wallet keeps the root key and signs on request; the core sends `signingRequest`/`aliasRequest`
+   messages over the encrypted SSO session channel and the wallet replies through the same protocol. This
+   resolves the old "who holds the wallet channel" question: there is no separate wallet channel; the core
+   owns the SSO protocol over the statement store ([E2](<E - open-questions.md>)).
+3. **Pairing is core-verified.** The core mints the session keys, builds the QR, verifies the wallet's
+   signed handshake statement, and derives the session. The host only renders the QR
+   ([A1](<A - host-primitives.md>)); it cannot assert a false identity.
+4. **The core owns `SessionState`, including the session `ssSecret`.** The `ssSecret` is the core's own
+   session statement-store key (the wallet never sends a secret); the core signs statement proofs and
+   derives product-account public keys in-core, no host round-trip.
+5. **All wire types already exist** (`truapi/src/v01` + `versioned`). The gap is implementations, never
+   type definitions.
+
+6. **Nested dApps share the Rust core in v1.** Do not introduce separate nested runtime/session/product
+   identities as part of this migration. The current dotli nested bridge behavior is documented as a
+   future-design note in [I](<I - nested-dapps.md>).
+
+The only new SSO protocol primitive is the QR presenter ([A1](<A - host-primitives.md>)). Separately,
+removing dotli's current `host-container` bridge and restoring core-owned sessions requires platform
+surfaces for notifications, theme, preimage, host-global session persistence, resource-allocation
+confirmation, and product runtime config ([A3](<A - host-primitives.md>)). The pairing/signing crypto
+internals are read from current dotli's pinned `@novasamatech` package sources plus the iOS peer, then
+vector-gated; see [H](<H - sso-pairing-protocol.md>) and [D](<D - crypto-foundation.md>).
+
+---
+
+## Host portability contract
+
+dotli is the first migration target, not the architecture boundary. The reusable boundary is:
+
+- `truapi-server` owns protocol and product-visible behavior: SSO pairing, channel encryption,
+  request/response routing, account derivation, statement-store proof/submit/subscribe, error mapping,
+  timeout behavior, session restore/logout, and wire method dispatch.
+- `truapi-platform` plus `RuntimeConfig` owns host-specific capabilities: storage, chain connection,
+  navigation, notifications, theme, preimage backend, resource allocation confirmation UI, QR/deeplink
+  presentation, and opaque session persistence.
+- The same core APIs and crypto vectors must pass on WASM hosts (dotli web/Electron worker) and UniFFI
+  hosts (iOS/Android). Host bindings may differ, but they cannot fork SSO, signing, statement-store,
+  derivation, or session semantics.
+- dotli-specific details such as `localStorage` route names, modal
+  components, and product-label lookup live in the dotli adapter/runtime config. They are not allowed to
+  leak into `truapi-server`.
+
+Adding another host should mean implementing the platform traits, providing `RuntimeConfig`, and wiring the
+embedding transport. It must not mean reimplementing pairing, wallet signing proxy messages, statement
+proof signing, or session persistence semantics outside Rust.
+
+---
+
+## The gap at a glance
+
+| Domain               | Deferred/unsupported in current dotli parity                                     | Implemented in Rust core today                                                                                                                                                           |
+| -------------------- | -------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
+| `Account`            | `create_account_proof`(26)                                                       | `connection_status_subscribe`(18), `get_account`(22), `get_account_alias`(24), `get_legacy_accounts`(28), `get_user_id`(110), `request_login`(112), logout/disconnect                    |
+| `Signing`            | none                                                                             | `create_transaction`(30), `create_transaction_with_legacy_account`(32), `sign_payload`(116), `sign_payload_with_legacy_account`(36), `sign_raw`(114), `sign_raw_with_legacy_account`(34) |
+| `StatementStore`     | none                                                                             | `subscribe`(56), `submit`(62), `create_proof`(60), `create_proof_authorized`(132)                                                                                                        |
+| `ResourceAllocation` | none                                                                             | `request`(130)                                                                                                                                                                           |
+| `Entropy`            | none                                                                             | `derive`(108)                                                                                                                                                                            |
+| `Theme`              | none                                                                             | `subscribe`(104)                                                                                                                                                                         |
+| `Notifications`      | none                                                                             | `send_push_notification`(4), `cancel_push_notification`(134)                                                                                                                             |
+| `Preimage`           | none                                                                             | `lookup_subscribe`(64), `submit`(68)                                                                                                                                                     |
+| `Payment`            | `balance_subscribe`(118), `top_up`(122), `request`(124), `status_subscribe`(126) | none, and dotli intentionally returns typed "not implemented" errors                                                                                                                     |
+
+`Chat` and `CoinPayment` remain outside this milestone and keep generated trait defaults until another
+host/product requires them. `Payment` and full `create_account_proof` deliberately return
+`Unsupported`; handlers that are unimplemented in dotli can stay that way until the other hosts need them.
+The current Rust core owns the dotli parity paths: SSO-only pairing/restore/logout, product-account
+derivation, signing and transaction SSO proxying, statement-store submit/subscribe/proofs, allocation
+requests, entropy, theme, notifications, and preimage callbacks.
+
+Latest-dotli audit note: dotli main and the Rust pairing path use the host-papp 0.8.6 SSO V2 proposal.
+The QR carries `VersionedHandshakeProposal::V2` with host metadata entries (`HostName`, `HostVersion`,
+`HostIcon`, `PlatformType`, `PlatformVersion`); the core parses the V2 response envelope and persists the
+returned `rootEntropySource`.
+
+Current dotli backs its host bridge with `@novasamatech/host-api` + `host-container`, and auth/session
+flows with `host-papp`, `statement-store`, `sdk-statement`, and `storage-adapter`. The packages are **not
+part of the Rust repo**, but current `~/github/dotli/node_modules/.bun` contains the pinned JS sources.
+Pairing, message-exchange, proof, and derivation internals are therefore extract-from-source/vector tasks;
+see [D](<D - crypto-foundation.md>).
+
+---
+
+## Roadmap
+
+| Tier | Scope                                                                                                                                                                                                                                                                                                                                                                                    | Detail                                                                                                                      |
+| ---- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------- |
+| 0    | Runtime construction plumbing (S): pass `RuntimeConfig` through Rust, WASM, UniFFI, and JS worker creation; no account-only session injection APIs. Zero crypto.                                                                                                                                                                                                                         | [A](<A - host-primitives.md>), [G](<G - annex.md>)                                                                          |
+| 1    | Pure-core accounts (S–M): add the crypto baseline + golden vectors; `get_account` (in-core sr25519 derivation); `get_legacy_accounts`, `get_user_id` (read `SessionState`).                                                                                                                                                                                                              | [B](<B - core-impls.md>), [D](<D - crypto-foundation.md>)                                                                   |
+| 1.5  | Protocol crypto/vector gate (M): build the narrow WASM-safe crypto module/crate, leaning on existing Rust crypto crates and using `useragent-kit` only as implementation precedent for similar migrations; capture vectors for HDKD, statement proof, handshake/channel encryption, and topic/session derivation. No pairing I/O yet.                                                    | [D](<D - crypto-foundation.md>)                                                                                             |
+| 2    | Statement-store client + pairing (L): a minimal People-chain statement submit/subscribe client over `ChainProvider`, then the `request_login` SSO handshake ([H](<H - sso-pairing-protocol.md>)) + the `PairingPresenter` (A1); extend `SessionInfo`; persist/restore through `SessionStore`; expose public logout/disconnect. The keystone.                                             | [H](<H - sso-pairing-protocol.md>), [A](<A - host-primitives.md>), [B](<B - core-impls.md>), [C](<C - session-contract.md>) |
+| 3    | Message-exchange ops + statement-store parity: `sign_payload`/`sign_raw`, `create_transaction`, and legacy signing/create-transaction over the SSO session channel; `create_proof`/`_authorized` (in-core, session `ssSecret`); product statement `subscribe`/`submit` (same client as Tier 2); `get_account_alias` (aliasRequest); resource allocation host confirmation + SSO request. | [H](<H - sso-pairing-protocol.md>), [B](<B - core-impls.md>)                                                                |
+| 3.5  | Non-Nova but implemented dotli host behavior needed once host-container is gone: preimage host callbacks, scheduled/cancellable notifications, theme subscription, and entropy derivation from the SSO V2 `rootEntropySource`.                                                                                                                                                           | [B](<B - core-impls.md>), [A](<A - host-primitives.md>)                                                                     |
+| 4    | Remaining TrUAPI surface not required for current dotli parity: full `create_account_proof`, Payment, Chat, CoinPayment, and any future move of preimage fully in-core.                                                                                                                                                                                                                  | [B](<B - core-impls.md>), [E](<E - open-questions.md>)                                                                      |
+
+The protocol crypto/vector gate (Tier 1.5) keeps byte-level compatibility failures out of the pairing
+I/O path. The statement-store client (Tier 2) is the keystone: it unlocks pairing, signing-proxy,
+ring-VRF, and the product statement store, all over one People-chain connection. After Tier 3.5, the dotli
+bridge no longer depends on any Nova package: `host-api`, `host-container`, `host-papp`,
+`statement-store`, `sdk-statement`, and `storage-adapter` all drop. Full checklist in
+[F](<F - novasamatech-removal.md>); concrete work packages and review slices are in
+[J](<J - implementation-plan.md>).
+
+## Landing checklist
+
+Use this checklist to review whether the spec is complete enough to implement:
+
+- The architecture has one protocol owner: `truapi-server`; hosts provide only OS/UI/storage/chain
+  capabilities.
+- Current dotli parity is defined from `~/github/dotli`, not from the stale submodule.
+- Every currently implemented dotli handler is either assigned to an in-core implementation, assigned to a
+  true host primitive, or explicitly deferred because dotli does not implement it today.
+- PR 104 transitional surfaces are named and have a removal path: raw account/signing/statement callbacks
+  and account-only session injection cannot become permanent architecture.
+- SSO pairing, signing, transaction construction, alias, resource allocation, statement proofs, and
+  product statement-store all use the same People-chain statement-store protocol.
+- Session persistence is core-owned, single-session, host-global, and not host-papp compatible; cutover
+  requires one-time re-pair.
+- Crypto constants are sourced from current dotli package code and gated by native + wasm vectors before
+  pairing I/O lands.
+- The dotli removal checklist ends with no runtime dependency on any `@novasamatech/*` package.
diff --git a/docs/local-e2e-testing.md b/docs/local-e2e-testing.md
index c832bfc3..af523494 100644
--- a/docs/local-e2e-testing.md
+++ b/docs/local-e2e-testing.md
@@ -25,6 +25,21 @@ The chain below is also automated:
 The doc below is still the canonical narrative and the source of truth
 for failure modes — both the skills and CI cite it.
 
+`make e2e-dotli` is the end-to-end dotli + playground diagnosis harness. It
+starts the local dotli preview and playground, opens Chromium, signs out any
+restored host session, signs in through the signer-bot SSO service, runs the
+playground Diagnosis screen, and writes
+`hosts/dotli/test-results/e2e-dotli/diagnosis-report.md`. Full automation
+requires `SIGNER_BOT_SVC_TOKEN`; `SIGNER_BOT_BASE_URL` and
+`SIGNER_BOT_NETWORK` default to dotli CI's signer-bot service and
+`paseo-next-v2`. Without the token, use
+`E2E_DOTLI_SMOKE=1 make e2e-dotli` to verify the local stack, browser launch,
+login click, TrUAPI debug logs, and QR/deeplink extraction without a phone.
+In root CI, the job also needs `DOTLI_CHECKOUT_TOKEN` to read the private
+dotli submodule. Without dotli access it reports a warning and skips the e2e
+job; with dotli access but without `SIGNER_BOT_SVC_TOKEN`, it runs the smoke
+path only.
+
 The order matters: each layer assumes the layer below it builds clean.
 Skip a step only if you are certain the change cannot affect that layer.
 
@@ -164,12 +179,28 @@ method from the UI.
 ```bash
 cd hosts/dotli
 bun run preview            # → http://localhost:5173
-# or, for the TrUAPI debug panel:
-bun run preview:debugger   # = VITE_APP_DEBUG=true bun run preview
 ```
 
-`preview:debugger` is recommended whenever you're investigating a wire
-issue — the debug panel logs every host↔product TrUAPI frame.
+When investigating a wire issue, raise the Rust core's log level in the
+host origin before reloading dotli:
+
+```js
+localStorage.setItem("truapi:logLevel", "debug"); // off|error|warn|info|debug|trace
+location.reload();
+```
+
+The WASM worker bridge forwards core `tracing` output to the browser
+console, mapping each level to the matching `console` method. To tune the
+level live without reloading, call the dev helper the worker runtime
+publishes:
+
+```js
+window.__truapi.setLogLevel("trace");
+```
+
+`debug` and `trace` are emitted via `console.debug`, which Chrome hides
+unless the console **Default levels ▾** dropdown includes **Verbose**;
+`info`/`warn`/`error` always render.
 
 ### Start the playground dev server
 
@@ -225,9 +256,9 @@ failing. Check:
   stale; redo step 4).
 
 If a method call hangs, the host either didn't receive the frame
-(check dotli's debug panel or console) or didn't respond. The bridge
-auto-responds to `host_handshake_request` only; everything else is on
-the host implementation.
+(check dotli's console with `truapi:logLevel` set to `debug`) or didn't respond.
+The bridge auto-responds to `host_handshake_request` only; everything
+else is on the host implementation.
 
 ## 7. Codegen tests