> ## 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.
# Proof-of-Readiness Campaign Roadmap
> Product-strategy view of readiness campaign primitives, marketing themes, and the sponsor model path. Internal reference — not a financial product.
# Proof-of-Readiness Campaign Roadmap
This document is an internal product-strategy reference for readiness campaign development. It maps campaign primitives to marketing launch themes and future sponsor model progressions.
Campaigns are informational scaffolding only. Nothing here implies custody, payouts, staking, APY, or any financial product. All campaigns require `custodyRequired: false`, `payoutImplemented: false`, and `protocolRoutingImplemented: false`.
## Campaign primitives (Phase 3)
Phase 3 ships six campaigns as preview/model-only. Each is a structured set of readiness actions targeting a specific wallet audience and security goal.
| Campaign id | Launch theme | Audience | Phase status |
| -------------------------------- | ------------------------------ | ----------------- | ------------ |
| `quantum_exposure_reduction` | Quantum Exposure Reduction | Whale Wallet | Preview |
| `dormant_whale_readiness` | Dormant Whale Readiness | Whale Wallet | Preview |
| `vault_readiness` | Vault Readiness | Individual Wallet | Preview |
| `watchlist_monitoring` | Watchlist Monitoring | Individual Wallet | Preview |
| `dao_treasury_migration` | DAO Treasury Migration | DAO Treasury | Preview |
| `proof_of_readiness_attestation` | Proof-of-Readiness Attestation | Individual Wallet | Preview |
## Marketing launch themes
Each theme pairs a target audience with what qualifies for the campaign and — just as importantly — what must never be claimed about it. Expand a theme for its full guardrails.
**Core message:** The post-quantum window is closing for high-value exposed wallets. Verified migrations earn non-custodial readiness attestations that become coordination primitives for the ecosystem.
**Target audience:** Whale wallets with signature exposure and estimated value ≥ \$100,000.
**What qualifies:** Verified on-chain migration to a previously-inactive address. Eligibility is determined from Dune Analytics data, not self-attestation.
**What to avoid claiming:** Any implication that WalletWall guarantees migration safety, controls the destination wallet, or earns yield from the migration.
**Core message:** Dormant whale wallets are the most exposed assets in a post-quantum world — unmonitored, unrecovered, and unaware. This campaign brings them into the migration path before the window closes.
**Target audience:** Wallets inactive for ≥ 365 days with estimated value ≥ \$100,000.
**What qualifies:** Enabling watchlist monitoring, configuring a recovery path, and publishing a readiness attestation.
**What to avoid claiming:** Any implication that WalletWall contacts wallet owners, manages dormant assets, or provides custodial protection for dormant value.
**Core message:** Vault-ready wallets are reference implementations for quantum-safe migration. This campaign demonstrates the migration path without moving funds.
**Target audience:** Programmable wallets that meet the vault-candidate classification threshold.
**What qualifies:** Vault prototype simulation on testnet, guardian configuration, or recovery policy setup. No mainnet fund movement required.
**What to avoid claiming:** Any implication that the vault prototype is production-ready, that funds are being moved or managed, or that vault readiness guarantees post-quantum safety.
**Core message:** Every unmonitored wallet is a blind spot. Monitoring is the lowest-effort, highest-coverage readiness action.
**Target audience:** All wallets without active watchlist coverage.
**What qualifies:** Enabling watchlist monitoring with alerting thresholds configured.
**What to avoid claiming:** Any implication that monitoring prevents exposure, guarantees alert timeliness, or provides real-time chain state.
**Core message:** DAO treasuries are the most concentrated, least-protected assets at post-quantum risk. Governance-native coordination is the only viable migration path for multi-sig and programmatic treasury structures.
**Target audience:** DAOs and protocol teams with observable on-chain governance participation.
**What qualifies:** Governance votes on migration standards, treasury readiness attestations, or configured migration paths.
**What to avoid claiming:** Any implication that campaign participation grants financial authority over treasury assets, or that governance votes are binding without a dedicated governance contract.
**Future sponsor model:** DAO sponsors may fund this campaign's coordination infrastructure. No payout model is defined or implemented.
**Core message:** Your readiness work deserves a verifiable record. Attestations are portable, off-chain proof of security-positive actions — the coordination layer for future non-custodial reward routing.
**Target audience:** Any wallet that has completed at least one readiness action.
**What qualifies:** Issuing a verified off-chain readiness attestation (Phase 2 schema) for any completed readiness action.
**What to avoid claiming:** Any implication that attestations are signed on-chain (Phase 2 is schema-only), that they grant financial rights, or that they represent a payout claim.
## Sponsor model progression
`walletwall_native_preview` (Phase 3, current): WalletWall surfaces campaigns as an informational preview. No sponsor funds are involved.
Three sponsor models are structurally defined but not built, and not ordered relative to one another: `dao_sponsored_future` (a DAO funds coordination infrastructure for a targeted campaign), `protocol_sponsored_future` (a protocol funds readiness coordination for its ecosystem), and `ecosystem_sponsored_future` (broad ecosystem sponsors — foundations, grants — fund cross-protocol campaigns). All three remain non-custodial.
| Sponsor model | Phase | Description |
| ---------------------------- | ----------------- | -------------------------------------------------------------------------------------------- |
| `walletwall_native_preview` | Phase 3 (current) | WalletWall surfaces campaigns as informational preview. No sponsor funds involved. |
| `dao_sponsored_future` | Future | A DAO funds coordination infrastructure for a targeted campaign. Non-custodial. |
| `protocol_sponsored_future` | Future | A protocol funds readiness coordination for its ecosystem. Non-custodial. |
| `ecosystem_sponsored_future` | Future | Broad ecosystem sponsors (foundations, grants) fund cross-protocol campaigns. Non-custodial. |
Sponsor models are structurally defined in the readiness-campaigns module. No sponsor marketplace UI is implemented.
## What Protocol Reward Routing is not
Protocol Reward Routing (future optional scope) is non-custodial routing of readiness attestations to a protocol that handles reward distribution. WalletWall would not:
* Hold assets
* Determine validator selection
* Control reward payouts
* Define a token or APY
This is not implemented in Phase 3 or any current phase. It is documented here only so that product and engineering teams understand what it means before scoping it.
## Deferred items
| Item | Decision | When |
| ------------------------------------- | -------------------------------------------------------------- | ----------------------------- |
| Cryptographic signing of attestations | Defer — needs clear user flow + threat model | Phase 4+ |
| On-chain attestation anchoring | Defer — contract/audit territory | Much later |
| Sponsor marketplace UI | Defer — needs sponsor partnership structure | After sponsor model validated |
| Evidence hash generation helpers | **Shipped in Phase 3.5** — deterministic evidence-hash helpers | Phase 3.5 ✓ |
| Token reward distribution | Out of scope | Not planned |
| APY or staking integration | Out of scope | Not planned |
## Phase 3.5: Evidence hashes in campaigns
Phase 3.5 ships deterministic evidence payload helpers. Campaigns can reference an evidence hash to verify that a wallet completed a specific readiness action without exposing raw wallet strategy.
Evidence hashes are:
* **Privacy-safe** — only allowlisted, non-sensitive signals are included in the payload before hashing.
* **Deterministic** — the same semantic signals always produce the same hash, regardless of key-insertion order.
* **Off-chain** — no on-chain write, no custody, no financial entitlement.
A future campaign verification flow could require a caller to present an evidence object whose hash matches the `evidenceHash` on their readiness attestation. That comparison proves the readiness action was observed and normalized — without revealing the raw wallet data behind it.
No campaign currently enforces this verification flow; the helpers are available as building blocks for Phase 4+.
## Legal and security review items
Before any campaign is promoted outside of preview:
* Legal review of "readiness reward" framing in any jurisdiction where financial product rules apply
* Security review of attestation schema for phishing surface (fake attestations, replay)
* Threat model for evidence hash construction (what can and cannot be in an evidence payload)
* Governance review of `dao_sponsored_future` sponsor model before any DAO is approached
## Related
The action categories, eligibility model, reward ledger, attestation schema, and evidence-hash mechanics that these campaigns are built from.
Custody, financial, testnet, and quantum-security boundaries that apply to every campaign and sponsor model on this page.