Educational claim-boundary explorer only. No cryptography runs, no prover or contract is
called, no repository is fetched, and no wallet is connected. The right-hand column is
permanent: no combination of these controls can ever move a red-line claim into the
supported column.
;
};
# Stablecoin Vault & Vault Simulator
WalletWall ships two related but distinct vault surfaces. Keep them separate in all copy and docs.
* **Route:** `/stablecoin-vault`
* **Subdomain:** `vault.walletwall.org`
* **Role:** Flagship vault readiness and migration journey — the destination the intelligence layer feeds
* **Route:** `/vault`
* **Subdomain:** none — no subdomain, not a peer flagship product
* **Role:** Sepolia testnet rehearsal detail — post-quantum authorization simulation, no mainnet, no custody
Both surfaces are research prototypes. Neither involves real funds, real custody, mainnet deposits, or production-grade quantum verification. See the [Vault Boundaries & Disclosures](/vault/boundaries) page for the full statement.
***
## Stablecoin Vault (flagship)
The Stablecoin Vault is the destination the WalletWall intelligence layer feeds — the action layer a wallet arrives at once Quantum Intelligence, Stable Seer, and Holder Wall have assessed its readiness. It is reachable at `/stablecoin-vault` and at `vault.walletwall.org`.
The Stablecoin Vault surfaces a **readiness journey** with four outcomes:
| Recommendation | When | What the app offers |
| --------------------- | ------------------------------------------------------------- | ---------------------------------------------------------------------------------------------- |
| **Monitor** | Low exposure / low urgency; no action needed yet | Keep watching; no simulator entry |
| **Prepare** | Meaningful exposure; migration feasible but not urgent | Show recommended migration path + readiness checklist; simulator offered as optional rehearsal |
| **Testnet Rehearsal** | Exposure + structure make the wallet a strong vault candidate | Prominent "Open the testnet vault simulator" entry |
| **Not Enough Data** | Insufficient signals to recommend | Provisional copy; **no** simulator entry; invite a fuller scan |
These map onto existing Migration Readiness engine outputs (`monitor` / `plan` / `prioritize` urgency and the `vault-prototype` recommended path) — they are a presentation layer, not new math.
```mermaid theme={null}
flowchart TD
accTitle: Stablecoin Vault four-outcome readiness journey
accDescr: A wallet's readiness signals feed a presentation-layer verdict with four possible outcomes: Monitor, Prepare, Testnet Rehearsal, or Not Enough Data. Only Testnet Rehearsal, and optionally Prepare, surface an entry into the Vault Simulator; Monitor and Not Enough Data never do. This is a read-only assessment, not an action or transaction.
R["Wallet readiness signals"]:::input --> V{"Readiness verdict"}:::decision
V -->|"low exposure / low urgency"| M["Monitor keep watching, no simulator entry"]:::process
V -->|"meaningful exposure, not urgent"| P["Prepare migration path + checklist; simulator optional"]:::process
V -->|"exposure + structure = strong candidate"| T["Testnet Rehearsal prominent simulator entry"]:::output
V -->|"insufficient signals"| N["Not Enough Data no simulator entry, invites fuller scan"]:::risk
P -.->|"optional rehearsal entry"| S(["Vault Simulator /vault, Sepolia testnet"]):::external
T -->|"testnet rehearsal entry"| S
classDef input fill:#FAFAF0,stroke:#B87333,color:#2B2118,stroke-width:1.5px;
classDef process fill:#B84923,stroke:#6B2412,color:#FFF7E8,stroke-width:1.5px;
classDef decision fill:#D6A85A,stroke:#8A5A1F,color:#2B2118,stroke-width:1.5px;
classDef output fill:#9AAB89,stroke:#526246,color:#172014,stroke-width:1.5px;
classDef risk fill:#8F2F1D,stroke:#5E1D12,color:#FFF7E8,stroke-width:1.5px;
classDef external fill:#A7B0B5,stroke:#59646A,color:#172014,stroke-width:1.5px;
```
*This diagram visualizes the table above; it adds no new inputs. The readiness assessment is read-only — Testnet Rehearsal (and optionally Prepare) is the only intended entry point into the Vault Simulator from the product journey; Monitor and Not Enough Data never surface a simulator entry.*
### Readiness signals
The readiness verdict is supported by four read-only **readiness signals**, kept as **separate gates** — none implies the others, and none is a protection guarantee:
A hash-only, read-only record that the open ML-DSA-65 verifier accepted a test vector. Not custody, not on-chain verification.
Whether documented Sepolia/testnet simulator metadata is present and safe to surface — mock assets only.
Read-only metadata for a reproducible proof-artifact example **generated outside the app**. **SP1 proving remains gated** in this app.
Research/disclosure status only — no ZK proof runs behind any readiness state. This is **not production quantum protection**.
These signals are read-only and **generated outside the app**: WalletWall does not fetch the reference repo at runtime, run SP1, or call any verifier service. See [PQ Evidence, Testnet Rehearsal & ZK/SP1 Status](/vault/pq-evidence-and-rehearsal) for the full statement.
### Handoffs into Stablecoin Vault
When a valid EVM wallet is open in the Holder Wall drawer, the app can route to Stablecoin Vault readiness with the wallet address in context.
When Quantum Intelligence has assessed a wallet's signature and migration exposure, a Stablecoin Vault readiness link is surfaced if the `vault-prototype` path is recommended.
Stable Seer's stablecoin exposure signals (peg health, concentration, flows) are inputs to the Stablecoin Vault readiness assessment.
### Stablecoin Vault → Vault Simulator
From the **Testnet Rehearsal** recommendation (and optionally **Prepare**), the Stablecoin Vault surfaces an entry into the Vault Simulator at `/vault`. This is the only intended entry point into the Vault Simulator from the product journey; the Vault Simulator is a technical detail, not a standalone flagship.
***
## Vault Simulator (Sepolia testnet detail)
The Vault Simulator is a **research prototype** that demonstrates a hybrid classical + post-quantum authorization model for Ethereum wallet migration. It is reachable at `/vault` only — it has no subdomain and is not a peer flagship product.
The Vault Simulator is a research prototype. The readiness scanner is read-only. The connected dashboard is testnet-only and can request EIP-712 signatures and submit testnet transactions. The current verifier is not production-grade post-quantum verification, and no live native PQ precompile support is claimed.
### Current implementation boundary
The Vault Simulator's UI is a compatibility/prototype surface. The readiness scanner is read-only and the migration path panel is driven by the shared wallet-security profile when available, with a migration-only fallback. WalletWall does not store private keys, does not ask for seed phrases, and does not implement recovery flows in this UI.
The shared wallet-security orchestration layer supplies the security state, vault eligibility, and recovery readiness rendered in the Wallet Security and Migration Path panels. The canonical boundary and guarantees live in the [Key Management & Recovery Model](/security/key-management-recovery-model) — recovery flows are **not implemented yet**.
#### Which readiness signal is which
PQ evidence, proof artifact status, and testnet rehearsal are **separate gates** — a positive state in one never implies another. The matrix below makes that boundary interactive; the full explanation lives in [PQ Evidence, Testnet Rehearsal & ZK/SP1 Status](/vault/pq-evidence-and-rehearsal).
### Deployment status
Ethereum Sepolia is the validated active deployment:
| Field | Value |
| ---------------------- | -------------------------------------------------------------------- |
| Status | `active-testnet` |
| Chain ID | `11155111` |
| Vault | `0x210ceD9C12AF27b10B06eB5506b24a51E11506E9` |
| Verifier | `0x832E223c6D889A96bCFF434a609e8a5782C706e9` |
| Deploy transaction | `0x8f15e6c99ee4ac789836716c75d26a8dc8df240dad731cbc8a7c9515e91cc3e1` |
| Live runtime | `20,508` bytes |
| Reported source commit | `828bf219c0e2612fcd1aba5f085c4abeba29de88` |
The reported source commit is absent from public Vault history, and current public HEAD recompiles to `22,138` runtime bytes, not the active deployment runtime of `20,508` bytes. This deployment is **not reproducible from public HEAD yet** — in the public repo its reproducibility is **remediation-gated** and recorded in a machine-checkable manifest (`deployments/reproducibility/walletwall-vault-sepolia.json`, enforced by `npm run validate:reproducibility`). The committed remediation path is to redeploy from public HEAD or publish the exact source tag and artifact manifest. Do not claim that current public HEAD reproduces the active Sepolia deployment.
The prior Sepolia deployment identified as `0x8c5B…CF24` is `deprecated` because it has a stale runtime and uses the incompatible legacy 32-byte PQ-key vault format. Do not use it for new vaults or reference it as active.
The public [Wallet-Wall/walletwall-vault](https://github.com/Wallet-Wall/walletwall-vault) repository owns contracts, security assumptions, verifier design, tests, and deployment records. The private app consumes pinned ABI, custom errors, events, EIP-712 schema, and deployment configuration only. No full public-repository mirror should be added.
The Stablecoin Vault page surfaces this trust state in a read-only **Vault Trust Status** panel. It reports the public reference path as `remediation-gated`, states that the active Sepolia deployment is not reproducible from public HEAD yet, lists the two remediation paths, and links to the public reproducibility manifest at `deployments/reproducibility/walletwall-vault-sepolia.json`. The panel is presentational only — it performs no runtime fetch, deploy, or transaction, implies no custody, deposits, wallet connection, or signing, and makes no mainnet-readiness claim.
### Page flow
#### Entry phase
The entry page explains the three concepts (Quantum Exposure, Migration Readiness, WalletWall Vault), shows the research disclosure, and presents a read-only scan form. Users can enter any Ethereum address or ENS name. A deep-link param `?vw=` triggers the scan automatically on load. Scanning does not require a wallet connection, signature, or transaction.
The connected Vault dashboard is separate from the readiness scanner. It is testnet-only, with Ethereum Sepolia as the validated active deployment. Ethereum Mainnet and Base Mainnet writes remain blocked.
#### Result phase
After scanning, the result phase renders, top to bottom:
Displays the vault readiness band (`unknown`, `weak`, `moderate`, `strong`, `resilient`) and the scanned address.
Always visible; states the prototype is read-only in the scanner and does not store keys.
Recovery readiness breakdown, findings, recommendations, controls, and migration path panel.
Shows which readiness campaigns the scanned wallet is eligible for, and an evidence hash derived deterministically from the wallet's security profile signals.
Collapsed by default; see below.
Links to the WalletWall Vault GitHub repo.
The `← New scan` button resets to entry without navigating away.
### Recovery Readiness Score
The score is computed by the recovery-readiness scorer. It starts from a base of 62 and applies deltas for:
| Signal | Effect |
| ------------------------------------------------- | ------ |
| Outgoing transactions (public key may be exposed) | −18 |
| Address reuse pattern | −8 |
| Very high value concentration (≥ \$1 M) | −18 |
| High value concentration (≥ \$100 K) | −12 |
| Dormant wallet with meaningful balance | −10 |
| Sampled / partial data | −5 |
| Multisig / Safe detected | +18 |
| Timelock detected | +12 |
| Guardian recovery detected | +10 |
| Fresh wallet pattern detected | +6 |
#### Score bands
| Band | Score range |
| ----------- | ----------------------------------- |
| `resilient` | ≥ 90 |
| `strong` | 70–89 |
| `moderate` | 40–69 |
| `weak` | \< 40 |
| `unknown` | Insufficient data (score is `null`) |
When no wallet signals are available the score is `null` and status is `insufficient_data`. A heuristic-only baseline is never shown as wallet-specific intelligence.
### Simulate: Authorization flow panel
The Simulate: Authorization flow panel is a collapsible research illustration — **not** an interactive signing flow. It renders in the result phase below the Quantum Vault Readiness Card, collapsed by default.
It shows a static, deterministic narrative of what a hybrid ECDSA + ML-DSA authorization step would look like for this wallet. Steps are neutral-gray (not success/fail colored) and labeled as a conceptual illustration.
| Step | Content |
| --------------------------------------------------------- | ----------------------------------------------------------------------------- |
| **Step 1 — Wallet classification** | Detected wallet type from `readiness.controls.multisig` |
| **Step 2 — Classical authorization (ECDSA)** | Signer language derived from multisig status |
| **Step 3 — Post-quantum authorization (ML-DSA FIPS 204)** | Always static — co-sign with new ML-DSA key pair (off-chain, conceptual only) |
| **Step 4 — On-chain verification (research placeholder)** | Always static — WalletWall Vault verifier contract, NOT production-grade |
```mermaid theme={null}
%%{init: {'theme': 'base', 'themeVariables': {'actorBkg': '#B84923', 'actorBorder': '#6B2412', 'actorTextColor': '#FFF7E8', 'actorLineColor': '#8A5A1F', 'signalColor': '#2B2118', 'signalTextColor': '#2B2118', 'labelBoxBkgColor': '#A7B0B5', 'labelBoxBorderColor': '#59646A', 'labelTextColor': '#172014', 'loopTextColor': '#2B2118', 'noteBkgColor': '#D6A85A', 'noteBorderColor': '#8A5A1F', 'noteTextColor': '#2B2118', 'activationBkgColor': '#FAFAF0', 'activationBorderColor': '#B87333', 'sequenceNumberColor': '#FFF7E8'}}}%%
sequenceDiagram
accTitle: Simulate Authorization flow panel — conceptual hybrid ECDSA plus ML-DSA illustration
accDescr: A static, deterministic four-step narrative shown collapsed by default in the result phase. It illustrates wallet classification, a classical ECDSA step, a conceptual off-chain ML-DSA co-signature, and a research-placeholder on-chain verification step. No wallet connection, no signature request, and nothing is submitted on-chain.
participant W as Scanned wallet (illustrative)
participant P as Panel narrative
participant E as Step 2: ECDSA (classical)
participant M as Step 3: ML-DSA FIPS 204 (off-chain, conceptual)
participant V as Step 4: Verifier contract (research placeholder)
Note over W,V: Static, deterministic narrative — not an interactive signing flow
W->>P: Step 1 — wallet classification (readiness.controls.multisig)
P->>E: Step 2 — signer language derived from multisig status
E->>M: Step 3 — conceptual co-sign with new ML-DSA key pair
M->>V: Step 4 — WalletWall Vault verifier contract
Note over V: NOT production-grade. Nothing submitted on-chain. No keys accessed.
```
*This renders the table above as a sequence, nothing more. Every step is illustration only — the panel is collapsed by default and colored neutral-gray rather than success/fail; it represents no real signature request, no key access, and no on-chain submission.*
Use careful labels such as "research simulation", "conceptual flow", "illustration", "not a real authorization", "no keys accessed", "nothing submitted on-chain", and "monitor only". Avoid absolute safety, recovery, or asset-control claims.
***
## Product registration
The product navigation registry defines the two surfaces (as of PR #1005). The Stablecoin Vault appears as item 05 in `PRODUCT_NAV_ITEMS`, the primary homepage journey. The Vault Simulator is a detail route and does not appear in the primary nav.
```js theme={null}
// Flagship stablecoin vault — vault.walletwall.org / /stablecoin-vault
stablecoinVault: {
id: 'stablecoinVault',
label: 'Stablecoin Vault',
subdomain: 'vault',
canonicalHost: 'vault.walletwall.org',
legacyPath: '/stablecoin-vault',
componentRoute: '/stablecoin-vault',
canonicalPath: '/stablecoin-vault',
description: 'Testnet research prototype — quantum-resistant stablecoin vault readiness journey',
iconKey: 'vault',
},
// Vault Simulator — /vault only, no subdomain
vault: {
id: 'vault',
label: 'Vault Simulator',
subdomain: null,
canonicalHost: null,
legacyPath: '/vault',
componentRoute: '/vault',
canonicalPath: '/vault',
description: 'Sepolia testnet vault simulator — post-quantum authorization rehearsal. No mainnet, no custody.',
iconKey: 'vault',
},
```
***
## Cryptographic research context
The vault prototype models hybrid authorization using:
* **ML-DSA (FIPS 204)** — formerly CRYSTALS-Dilithium; the primary post-quantum signature scheme.
* **SLH-DSA (FIPS 205)** — formerly SPHINCS+; referenced as related signature research.
* **ECDSA / secp256k1** — the current Ethereum signature scheme, retained in the hybrid flow.
The hybrid proof binds both an ECDSA signature and an ML-DSA signature to the migration transaction. The on-chain verifier is an architectural placeholder — it does not perform production-grade cryptographic verification.
Connected-dashboard withdrawals use EIP-712 typed-data signing. Before transaction submission, the app runs a `staticCall` preflight and surfaces decoded custom errors when revert data matches the pinned ABI. Mock PQ key and signature material is prototype/testnet-only.
***
## Approved framing
| Use | Do not use |
| ---------------------------------- | ----------------------------------- |
| Post-quantum migration research | Quantum-proof |
| Hybrid authorization prototype | Quantum-secure |
| Experimental migration path | Protects real funds |
| Research-backed prototype | Guaranteed quantum resistance |
| Conceptual illustration | Seed phrase recovery |
| Not a real authorization | Deploy vault now |
| Stablecoin Vault readiness journey | Vault is production-ready |
| Vault Simulator (for /vault) | vault.walletwall.org is a simulator |
***
## Related
The scoring model and Dune feeds that power vault readiness.
The four-tier engine behind the Stablecoin Vault recommendation.
Full custody, testnet, and quantum-security boundary statements.
The flagship vault readiness and migration journey, at vault.walletwall.org.
Owns contracts, security assumptions, verifier design, tests, and deployment records.