Skip to main content

​
Migration Readiness

Migration Readiness is the recommend step in WalletWall’s workflow. Where the Quantum Exposure Score answers how urgent is the risk, Migration Readiness answers how feasible is it to move safely, and what should be done first. It does not introduce a second score. It reuses existing wallet signals — value at risk, signature exposure, dormancy, and wallet structure — to recommend one path and place the wallet in a shared risk tier.
Keep three ideas distinct in all copy: Quantum Exposure = how urgent the wallet-level risk is. Migration Readiness = how feasible it is to move safely (this page). WalletWall Vault = one experimental post-quantum migration path, monitor only in the private app.

​
The shared risk tiers

Every assessment normalizes into one of four tiers. These are the common language across modules and reports.
TierMeaningWhat it suggests
MonitorLow urgency — nothing to act on yet.Keep watching signature exposure; re-check on schedule. No migration action needed.
ReviewWorth a closer look and a plan.Review the wallet and plan a migration approach — e.g. moving long-term holdings to a fresh wallet or splitting concentration.
MigratePrioritize concrete action.Begin a real migration path: distribute signing across a multisig with an upgrade path, or coordinate a signer-led treasury plan.
Vault CandidateResearch path surfaced — conditional.Review the WalletWall Vault research prototype as one experimental option. Monitor only in the private app.

​
How recommendations should be interpreted

  • Tiers are prioritization bands, not verdicts. “Migrate” means near the top of your migration queue, not unsafe today.
  • Recommendations are starting points. They suggest a direction; the right migration for a given wallet depends on operational context WalletWall cannot see (signer availability, governance, and internal controls).
  • Confidence matters. A recommendation made from partial or stale data carries caveats. Treat low-confidence recommendations as prompts to gather more information, not as final answers.
  • “Vault Candidate” is always conditional. It is surfaced as a research path, never as a deployable recovery flow.

​
Tier-by-tier actions

​
Monitor

Low exposure or low value at risk; often a wallet whose public key may not yet be revealed.
  • Action: Keep monitoring. No migration step is needed yet.
  • Re-check when value, activity, or exposure changes.

​
Review

Moderate-to-high exposure with meaningful value, or growing concentration.
  • Action: Review the wallet and plan an approach. Candidate paths:
    • fresh-wallet — move long-term holdings to a fresh wallet to reduce public-key exposure.
    • split-wallet — split holdings across wallets to reduce single-address concentration.

​
Migrate

High exposure or “Migration priority” — high value in a classical EOA with a feasible path.
  • Action: Begin a concrete migration. Candidate paths:
    • multisig — distribute signing across a multisig (e.g. Safe) with an upgrade path.
    • treasury-custody — coordinate a signer-led treasury migration path with the wallet’s signers.

​
Vault Candidate

Long-horizon, high-value, quantum-exposed wallets where experimental migration approaches are relevant.
  • Action: Review the WalletWall Vault research prototype as one option, alongside the disclosure below. This never enables recovery flows, private key handling, seed phrase inputs, wallet writes, or mainnet interactions.

​
Why the Vault Candidate tier is conditional

The WalletWall Vault is a Phase 2 research prototype that demonstrates a hybrid classical + post-quantum authorization model — an Ethereum ECDSA signature plus an ML-DSA (FIPS 204, formerly CRYSTALS-Dilithium) signature, with related research into SLH-DSA (FIPS 205, formerly SPHINCS+). It is surfaced as a research path because:
  • The on-chain verifier is an architectural placeholder, not production-grade cryptographic verification.
  • The connected dashboard is testnet-only (Ethereum Sepolia); mainnet writes are blocked.
  • It demonstrates a migration direction, not a deployable product.
This is why “Vault Candidate” is a conditional, research-oriented tier rather than a recommendation to move funds today. See WalletWall Vault for full detail.

​
Read-only / no key-storage disclaimer

WalletWall does not store keys and does not write to any wallet. Migration-readiness scanning is read-only: no wallet connection, no private keys, no seed phrases, no signing, no transactions. Recovery flows are not implemented yet. Recommendations are informational guidance for planning, not actions performed on your behalf, and not investment advice. The WalletWall Vault is a research prototype and must not be used for real funds.
The full non-custodial boundary — including the contract/guardian/passkey/MPC recovery model and the experimental post-quantum verifier status — is defined in the canonical Key Management & Recovery Model.