> ## Documentation Index > Fetch the complete documentation index at: https://docs.walletwall.org/llms.txt > Use this file to discover all available pages before exploring further. # Custody legal boundaries # WalletWall Custody & Legal Boundaries **Status:** Canonical reference — adopted 2026-06-18 **Applies to:** `sirmrdrgod/walletwall` (app repo) and all WalletWall-branded copy, docs, and marketing material > **One-line summary:** WalletWall is a read-only wallet intelligence product and a > testnet research prototype. It has no custody, no key storage, no production > deposits, no income-generating product or promised returns, no insurance, and no > guarantee of quantum resistance. The public vault is a testnet simulator only. This document is the single canonical source for what WalletWall is and is not allowed to claim. Every future feature, copy change, docs update, or investor conversation must be checked against it. The public-facing counterpart is [`docs/vault/boundaries.mdx`](../vault/boundaries.mdx) (served at `/vault/boundaries` in the Mintlify docs site). The repo doc (this file) adds contributor-specific rules — forbidden language, app/vault repo boundary, write-flow gating, ABI versioning, and disclosure requirements — that are not appropriate for the public page. *** ## 1 — Current product posture WalletWall today is a **read-only wallet intelligence product** and a **testnet research prototype**. Its surfaces are: | Surface | Route / subdomain | What it does | What it is NOT | | ------------------------ | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------- | | **Holder Wall** | `/holder-wall` | On-chain wallet / entity profile intelligence — holder type, asset concentration, movement. Routes valid EVM wallets to Stablecoin Vault readiness. | Not custody, not portfolio management, not financial advice | | **Stable Seer** | `/stable-seer` · `stable.walletwall.org` | Stablecoin intelligence — peg metrics, liquidity, holder/flow analysis. Feeds Stablecoin Vault readiness. | Not an income source, not a trading platform, not financial advice | | **Quantum Intelligence** | `/quantum` | Exposed-signature and migration-readiness analysis. Routes vault candidates to Stablecoin Vault. | Not a quantum-proof security product, not an audit, not a guarantee | | **Stablecoin Vault** | `/stablecoin-vault` · `vault.walletwall.org` | Flagship vault readiness journey — four-outcome readiness assessment (Monitor / Prepare / Testnet Rehearsal / Not Enough Data) | Not a live wallet, not custody, not a production vault, not audited | | **Vault Simulator** | `/vault` | Mock-USDC deposit/withdraw rehearsal on Ethereum Sepolia. Surfaced only from the Testnet Rehearsal outcome. No subdomain — not a peer flagship product. | Not mainnet, not real funds, no monetary value, not production-grade quantum verification | The app is the **intelligence / readiness layer**. The vault is a **testnet research prototype and destination simulator**. No surface today involves real assets, real custody, production quantum security, or any financial action. As of this document, production WalletWall app surfaces display **Vault Readiness** and **Simulator Status** only. The connected vault simulator is limited to local Hardhat or Sepolia rehearsal/dev flows; those simulator writes are not production product behavior and must never target mainnet, real stablecoins, deposits, withdrawals, or custody. *** ## 2 — Custody boundary **WalletWall takes no custody of user funds. Ever.** Specifically: * **No key storage.** WalletWall never stores, receives, transmits, or logs private keys, seed phrases, mnemonic words, or any key material. There is no input field, API endpoint, database column, or log sink that accepts them. * **No discretionary control.** WalletWall never has authority to move, freeze, or recover a user's funds without an explicit, per-action user signature through the user's own wallet provider. * **No signing authority.** WalletWall constructs unsigned, human-readable intents (EIP-712 typed messages) for the user's review; the user's wallet signs. WalletWall holds no signing key. * **No custodial vaults.** The WalletWall Vault is a testnet research prototype (see Section 5). No mainnet custody path is implemented or implied. * **No seed phrase requests.** WalletWall never asks for a seed phrase. Any surface that requests mnemonic material is not WalletWall. These are **hard invariants**, not policy preferences. Code, copy, and marketing must never contradict them. *** ## 3 — Financial and yield boundary **WalletWall provides no financial product and gives no financial advice.** * **No yield.** No WalletWall surface produces, promises, or simulates a yield on assets. There is no mechanism that grows a balance over time. * **No interest.** No interest accrual — real, synthetic, or simulated-as-real. * **No APY / APR.** No annualized rate, rate-of-return, payout countdown, or reward multiplier is shown or implied. * **No returns.** WalletWall does not project, display, or imply any financial return on a user's holdings. * **No financial advice.** All signals, scores, and recommendations are research intelligence and migration-readiness indicators — not investment, tax, legal, or financial advice. Users must consult qualified advisors for those needs. * **No rewards with monetary value.** Proof-of-Readiness campaign points are readiness attestations, not tokens, currency, or securities. They carry no monetary value and no redemption right. * **No insurance.** WalletWall makes no insurance claim on any user deposit, testnet or otherwise. No FDIC, SIPC, or any other deposit-insurance analogue applies. Copy that uses the words *yield*, *interest*, *APY*, *APR*, *returns*, *rewards* (in a financial sense), *earn*, *payout*, *dividends*, or *insured* in relation to WalletWall is disallowed. *** ## 4 — Security and quantum boundary **WalletWall does not guarantee quantum resistance. The PQ verifier is a research prototype.** * **No "quantum-proof" claim.** WalletWall must not state or imply that any user wallet, vault, or asset is quantum-proof, quantum-safe today, or protected against quantum attacks. * **No "audited" claim (until independently audited).** The vault contracts and the attestation service are research prototypes. No independent security audit has been completed. Copy must not say "audited" until a completed, published audit exists. * **Trusted attestation, not trustless on-chain PQ.** Post-quantum authorization in the vault prototype uses a **trusted attestation path**: an authorized attestor verifies ML-DSA-65 off-chain, then publishes a signed EIP-712 attestation. ML-DSA is **not** verified on-chain in the current prototype. Any reference to PQ authorization must describe it as a trusted-attestor model. * **Experimental verifier hooks.** The `IPQCVerifier` interface, `MockMLDSAVerifier`, and `AttestationPQCVerifier` are experimental. They are not production-grade and must not be presented as final security primitives. * **Mock verifier is structural only.** `MockMLDSAVerifier` is a mock used for simulator structure and tests. It must be described as structural/mock only and must never be described as real on-chain ML-DSA verification. * **Quantum Intelligence scores are exposure indicators, not guarantees.** The Quantum Exposure Score tells a user how much signature-exposure risk their wallet has accumulated on-chain — it is not a certification of safety. * **Migration Readiness is advisory.** The deterministic migration-readiness engine produces an urgency recommendation (`monitor` / `plan` / `prioritize` / `vault-prototype`). It is informational guidance, not a security guarantee. *** ## 5 — Testnet and mock-token boundary **The WalletWall Vault operates on testnet only. Mock tokens have no monetary value.** * **Testnet-only.** All vault writes are gated to local Hardhat (chain ID `31337`), Ethereum Sepolia (chain ID `11155111`), or another explicitly named testnet. Any deploy or app write path that targets a non-testnet chain must hard-fail before submission. * **Mock USDC-style test token.** The stablecoin vault MVP uses `MockUSDC` (`mUSDC`), a freely-mintable ERC-20 test token with no monetary value. It is not real USDC. It is obtained via a testnet faucet; no purchase path exists. * **Sepolia simulator deployment.** The recorded Sepolia deployment is a research/testnet simulator, not production custody and not mainnet readiness. * **No real stablecoin deposits.** Real USDC, USDT, DAI, or any other mainnet stablecoin is never deposited into any WalletWall-surfaced vault. Real funds must never appear in any WalletWall vault flow. * **No mainnet references in the vault module.** No mainnet network name, RPC endpoint, production contract address, or real-stablecoin token address may appear in the vault integration code. This is enforced by grep-based hygiene checks. * **"Rehearsal" framing only.** The testnet experience is a migration rehearsal — it teaches the deposit/withdraw/governance flow, not custody of real value. All copy for the simulator must use language like *rehearsal*, *testnet*, *prototype*, or *mock* — never *production*, *live*, *real funds*, or *custody*. * **Mandatory disclosures.** Every surface that exposes vault writes must show: > **TESTNET — RESEARCH PROTOTYPE.** This vault holds a **mock USDC-style test > token with no monetary value** on a test network. It is **not audited**, **not > production custody**, and **not protection for real funds**. WalletWall does > **not** take custody, never stores keys, and never accepts mainnet or > real-stablecoin deposits. and for PQ authorization: > **Trusted attestation, not trustless PQ.** Post-quantum authorization in this > prototype relies on a **trusted attestor** verifying ML-DSA-65 off-chain. ML-DSA > is **not** verified on-chain. This is a research migration path, not a > quantum-proof guarantee. *** ## 6 — App repo vs. vault repo boundary Two repos; two sets of responsibilities. They must not blur. | Responsibility | App repo (`sirmrdrgod/walletwall`) | Vault repo (`Wallet-Wall/walletwall-vault`) | | ---------------------------------------------------------------------------- | ---------------------------------- | ------------------------------------------- | | **Product UI** | ✓ | — | | **Intelligence signals** (Holder Wall, Stable Seer, Quantum Intelligence) | ✓ | — | | **Migration Readiness engine** | ✓ | — | | **Vault Readiness workflow + simulator entry** | ✓ | — | | **Docs links to vault repo** | ✓ | — | | **Pinned ABI / EIP-712 schema / deployment config** (consumed, not authored) | ✓ (reference only) | ✓ (owned) | | **Smart contracts** | — | ✓ | | **Mock ERC-20 test token** | — | ✓ | | **PQ verifier interfaces + implementations** | — | ✓ | | **Attestation service** | — | ✓ | | **Testnet deployment scripts** | — | ✓ | | **`SECURITY.md` / threat model** | — | ✓ | **Hard rules enforced by this boundary:** 1. The app repo must never copy contract source, ABIs (except pinned consume-only references), deployment artifacts, or secrets from the vault repo as a canonical source. The vault repo owns; the app references. 2. The vault repo's `WALLETWALL_APP_BOUNDARY.md`, `SECURITY.md`, and `docs/Deployments.md` are the sources of truth for their respective domains. 3. `VAULT_SOURCE_OF_TRUTH` in `src/lib/vaultDeploymentManifest.js` is the runtime enforcement of this boundary — it must stay current and accurate. *** ## 7 — No wallet write flow without explicit approval **No write path (transaction, signature request, or state mutation) ships to the app without passing all of the following:** 1. **Feature flag gate.** Any write-capable surface must sit behind a feature flag that defaults to off. Two independent flags are required for the vault module: one for surfacing the entry point, one for enabling any on-chain write. 2. **Runtime `chainId` testnet assertion.** The app must check at runtime that the connected chain ID matches an explicitly allowlisted testnet. A non-testnet chain must block all write actions unconditionally. 3. **Deploy-time testnet hard-fail.** The vault contract deploy scripts must assert that the target network is testnet-only and must abort otherwise. 4. **Security review gate.** Any Phase C (write-capable testnet) or later write path requires a documented security review before merging, signed off by at least one reviewer who is not the implementing author. 5. **Explicit user intent at every step.** No batched, silent, or "convenience" actions. Each destructive or value-moving action requires a clear, per-action confirmation modal. **No mainnet write path exists.** Even after all testnet gates pass, a mainnet path requires a completely separate spec, threat model, and the six gates in Section 9. *** ## 8 — ABI and contract versioning policy **ABIs and deployment artifacts are consumed from the vault repo, never authored here.** * **Pinned only.** Any ABI or deployment config imported into the app must be an explicitly versioned snapshot (tagged commit, release artifact, or manually promoted copy). Floating imports from vault repo source are not allowed. * **No contract source copies.** Solidity source files, compiled bytecode, or deployment scripts must not be copied into the app repo as a canonical source. If they are included for reference, they must be marked as snapshots and not used directly by the build. * **ABI drift check.** When a vault repo release changes the ABI or EIP-712 schema, the pinned snapshot in the app must be explicitly updated and the change reviewed. The update is never automatic. * **`VAULT_SOURCE_OF_TRUTH`** (`src/lib/vaultDeploymentManifest.js`) is the single runtime location for vault deployment metadata. It must be kept current with the active testnet deployment and must never reference a mainnet deployment. *** ## 9 — Gates before any production or mainnet custody path **No production custody path exists. The following gates must all pass before any could be considered.** These are sequential hard gates, not optional milestones: | Gate | What it requires | Current status | | ----------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | ----------------------- | | **G1 — Independent security audit** | A completed, published audit of the vault contracts and attestation service by an independent third party | Not started | | **G2 — On-chain PQ verification** | ML-DSA (or equivalent FIPS 204-compliant) verification performed on-chain, not via a trusted attestor | Research prototype only | | **G3 — Legal review** | Legal analysis of custodial money-transmission and securities law for the target jurisdiction(s), with appropriate licensing or exemptions | Not started | | **G4 — Operational controls** | Production key management, incident response, SLA, and continuity documentation | Not started | | **G5 — Regulatory clearance** | Any required regulatory approval or sandbox participation | Not started | | **G6 — Separate mainnet spec** | A completely separate product spec, threat model, and audit for the mainnet path | Not started | **Until every gate above is completed and documented, no WalletWall copy, pitch deck, or investor communication may imply that a production or mainnet custody path is live, imminent, or approved.** The testnet simulator exists to demonstrate the migration UX concept — not to preview an upcoming production launch. *** ## 10 — Disclosure requirements The following disclosures are **mandatory** and must appear verbatim (or as an approved paraphrase matching the substance) on the surfaces listed. ### Vault readiness surfaces (scanner, result view, readiness workflow) Must show the `ResearchDisclosure` component or equivalent before any vault-readiness result. The disclosure must state: * This is a research prototype. * The readiness scanner is read-only and does not store keys. * The connected dashboard is testnet-only. * No production-grade quantum resistance is implied. The constant `VAULT_PROTOTYPE_DISCLOSURE` in `src/lib/migration-readiness.js` is the authoritative copy. Do not paraphrase in ways that weaken the prototype / testnet framing. ### Simulator status surfaces (deployment cards, empty states, and status copy) Must state all of the following whenever the app displays simulator deployment or availability status: * The Sepolia deployment is a research/testnet simulator, not production custody. * `MockUSDC` is not real USDC and has no monetary value. * `MockMLDSAVerifier` is structural/mock only and does not perform real on-chain ML-DSA verification. * The current app surface is status/readiness display only unless a later approved write-flow gate explicitly changes that. * No production mainnet readiness, audit status, or quantum-proof protection is implied. ### Simulator entry surfaces (any surface that opens a vault write path) Must show a blocking acknowledgement modal before the first write action. The modal must include: > **TESTNET — RESEARCH PROTOTYPE.** This vault holds a **mock USDC-style test > token with no monetary value** on a test network. It is **not audited**, **not > production custody**, and **not protection for real funds**. WalletWall does > **not** take custody, never stores keys, and never accepts mainnet or > real-stablecoin deposits. A persistent banner with the same framing must remain visible throughout the simulator session. ### PQ attestation surfaces Any surface that describes or shows PQ authorization must include: > **Trusted attestation, not trustless PQ.** Post-quantum authorization in this > prototype relies on a **trusted attestor** verifying ML-DSA-65 off-chain. ML-DSA > is **not** verified on-chain. This is a research migration path, not a > quantum-proof guarantee. The constant `PQC_ALGORITHM_NOTE` in `src/lib/migration-readiness.js` must be used or quoted; do not weaken the "trusted attestor" framing. *** ## 11 — Language quick-reference ### Always allowed (accurate) * quantum-resistant vault *readiness* · migration readiness · testnet prototype · research prototype · mock test token · trusted attestor model · stablecoin vault *concept* · on-chain holder intelligence · non-custodial · self-custodial wallet ### Never allowed (overclaim) * custody · custodial · key storage · seed phrase storage · guaranteed quantum-proof · quantum-safe today · quantum-secure · audited *(until audited)* · insured · FDIC-insured · yield · interest · APY · APR · returns · earn · payout · dividends · financial advice · investment advice · production deposit · mainnet deposit · real funds · live funds ### Requires explicit qualification * "quantum-resistant" → must follow with: *testnet prototype, not audited, not production custody* * "PQ attestation" → must clarify: *trusted-attestor path, ML-DSA not verified on-chain* * "vault" → must be paired with *testnet* or *prototype* in any user-facing context until G1–G6 are cleared * "rewards" → must clarify: *readiness attestation only, no monetary value* *** ## Related documents * [Public boundary page](../vault/boundaries.mdx) — Mintlify-served public version of this boundary statement (user-facing) * [Vault-first positioning](vault-first-positioning.md) — product thesis and copy/nav changes; uses these guardrails * [Stablecoin Vault MVP](stablecoin-vault-mvp.md) — testnet MVP spec; all in-scope/out-of-scope boundaries defer here for the canonical statement * [Key Management & Recovery Model](../security/key-management-recovery-model.md) — non-custodial hard rules and recovery-path design constraints * Vault repo: `docs/WALLETWALL_APP_BOUNDARY.md`, `SECURITY.md`, `docs/THREAT_MODEL.md` — vault-side boundary, threat model, and security assumptions (source of truth for vault security claims)