> ## 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 Rewards > WalletWall's security-native incentive model for verified wallet readiness actions, quantum migration governance, and non-custodial attestations. # Proof-of-Readiness Rewards Proof-of-Readiness Rewards is WalletWall's security-native incentive layer. It rewards verified wallet readiness actions — not deposits, not staking, and not any form of asset custody. WalletWall does not custody assets, promise returns, or pay yield of any kind. Proof-of-Readiness Rewards reflect verified security-positive actions only. This is not a financial product. ## What this is Proof-of-Readiness Rewards recognizes wallets that take concrete steps to reduce quantum exposure risk, configure recovery, enable monitoring, and participate in migration governance. The incentive structure is aligned with security outcomes, not with the size of a deposit or the duration of a lock-up. ## What this is not | Not this | Why | | ------------------ | ------------------------------------------------------ | | Staking or yield | No deposits, no lock-ups, no APY promises | | Custodial rewards | WalletWall never holds assets on your behalf | | Guaranteed returns | No financial guarantees of any kind | | Bank-like product | No FDIC-equivalent coverage, no fund-like structure | | Token distribution | No on-chain reward token is defined or distributed yet | ## Why quantum migration is a governance coordination problem Quantum-safe migration is not a solo action. The Ethereum ecosystem cannot migrate atomically — it requires: * Shared standards for what counts as a quantum-safe migration path * Coordination across wallet providers, protocol teams, and key holders * Reference implementations and verifiable migration records Individual wallets that complete readiness reviews, publish attestations, and participate in governance decisions make the migration path safer for the entire ecosystem. Proof-of-Readiness Rewards creates an incentive for those contributions. ## Reward action categories Each category is evaluated independently against a wallet's observable signals. Expand a category for its eligibility signal, verification source, and custody posture — every category requires no custody. Wallets that complete a verified migration away from a public-key-exposed address reduce the concentration of value behind that exposed key. This is the most direct, measurable readiness action. **Eligibility signal:** signature exposure observed AND estimated value ≥ \$100,000\ **Verification:** on-chain migration transaction observed by Dune Analytics\ **Custody required:** no Wallets that demonstrate readiness for a post-quantum vault migration — through programmable wallet structure, guardian configuration, or recovery policy simulation — serve as reference implementations for the ecosystem. **Eligibility signal:** vault-candidate classification (programmable wallet with meaningful value)\ **Verification:** WalletWall Vault prototype (testnet) and Dune wallet classification\ **Custody required:** no Wallets with no configured recovery path represent the highest concentration risk for unrecoverable value loss. Configuring a recovery path — multisig threshold, guardian designation, or emergency withdrawal policy — is a verifiable readiness action. **Eligibility signal:** recovery classification of `should-configure-recovery` or `needs-urgent-migration`\ **Verification:** WalletWall recovery readiness classifier\ **Custody required:** no Enabling active monitoring on a wallet generates richer signal data for the whole ecosystem. It is a low-effort, high-impact readiness action. **Eligibility signal:** watchlist not enabled\ **Verification:** WalletWall watchlist configuration\ **Custody required:** no Voting on quantum migration readiness standards, flagging exposure patterns for community review, and contributing to governance proposals creates shared coordination that makes migration safer at scale. **Eligibility signal:** active governance context detected\ **Verification:** on-chain or off-chain snapshot records\ **Custody required:** no Non-custodial attestations — EIP-712 typed signatures or off-chain records — create verifiable, portable proof of completed readiness actions without moving funds or revealing keys. **Eligibility signal:** any completed readiness review\ **Verification:** attestation signature and source action\ **Custody required:** no ## Eligibility model The eligibility helper (`getProofOfReadinessRewardActions`) accepts a plain object of wallet signals and returns the subset of actions that are relevant for that wallet. Rules are deterministic and conservative: ```js theme={null} // Proof-of-Readiness eligibility helper const actions = getProofOfReadinessRewardActions({ hasSignatureExposure: true, estimatedValueUsd: 500_000, vaultEligible: true, watchlistEnabled: false, recoveryConfigured: false, governanceContext: null, }); // → [ exposure_reduction, vault_readiness, monitoring, recovery_setup ] ``` Signals are derived from already-computed on-chain facts (Dune, quantum exposure scores, migration readiness classifier). No new derivation is performed. ## Future scope: Protocol Reward Routing Protocol-native reward routing — non-custodial staking routing, validator selection, or on-chain attestation anchoring — is future optional scope only. If implemented, it will be non-custodial routing only: WalletWall would route readiness attestations to a protocol that handles reward distribution. WalletWall would not hold assets, determine validator selection, or control reward payouts. **Not yet implemented:** routing, staking integration, APY display, validator selection, wallet connection for rewards, transaction flows, or any on-chain reward token. ## Non-custodial guarantees The Proof-of-Readiness Rewards model is constrained by the same guardrails as the rest of WalletWall: * WalletWall never stores private keys * WalletWall never asks for seed phrases * WalletWall never moves funds on your behalf * Eligibility is determined from publicly observable on-chain facts only * No action requires a deposit or a lock-up See [Key Management & Recovery Model](/security/key-management-recovery-model) for the full non-custodial boundary. ## Phase 2: Local reward ledger and attestation schema Phase 2 adds a local, off-chain reward ledger model and a Proof-of-Readiness attestation schema. Neither introduces custody, payouts, database persistence, or any on-chain writes. Wallet signals are evaluated against the reward action rules described above (`getProofOfReadinessRewardActions`). A reward event moves through the local ledger statuses below: `eligible` → `suggested` → `completed_local` → `attestation_ready`. A deterministic hash of redacted, allowlisted signals is computed — described later in Phase 3.5. An off-chain attestation references the evidence hash. It is not signed on-chain, not a payout, and not a reward claim. ### Local reward ledger The local reward ledger tracks readiness reward events in memory only — no database, no chain interaction, no server persistence. #### Readiness statuses | Status | Meaning | | ------------------- | ----------------------------------------------------- | | `eligible` | Wallet signals qualify this action for tracking | | `suggested` | Action has been surfaced and is pending user review | | `completed_local` | Action has been marked completed locally | | `attestation_ready` | Evidence provided; an attestation can now be prepared | ```mermaid theme={null} stateDiagram-v2 accTitle: Local reward ledger status progression accDescr: A reward event starts eligible when wallet signals qualify it for tracking, moves to suggested when the action is surfaced for user review, moves to completed local when the user marks the action complete, and moves to attestation ready once evidence is provided so an attestation can be prepared. This is a local, in-memory record only, not a payout and not a blockchain transaction status. [*] --> eligible eligible --> suggested: surfaced for review suggested --> completed_local: marked complete locally completed_local --> attestation_ready: evidence provided attestation_ready --> [*] eligible: eligible (signals qualify this action) suggested: suggested (surfaced, pending review) completed_local: completed_local (marked complete locally) attestation_ready: attestation_ready (evidence provided; attestation can be prepared) class eligible input class suggested,completed_local process class attestation_ready output 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 output fill:#9AAB89,stroke:#526246,color:#172014,stroke-width:1.5px; ``` *This is a local, in-memory reward-event record, not a payout and not a blockchain transaction status — it mirrors the status table above.* #### Reward event shape A reward event is a plain object with no financial fields: ```json theme={null} { "id": "por_ab12cd34_1_exposure_reduction_1718000000000", "walletAddress": "0xab12cd34...", "chainId": 1, "actionId": "exposure_reduction", "status": "eligible", "evidenceHash": null, "rewardUnits": 0, "createdAt": "2026-01-01T00:00:00.000Z", "updatedAt": "2026-01-01T00:00:00.000Z", "custody": "none", "disclaimer": "This readiness event is a local record only..." } ``` `rewardUnits` is a non-monetary counter that may inform future non-custodial governance weight. It is not a token balance, not a payout, and not a financial entitlement of any kind. ### Proof-of-Readiness attestation schema The attestation schema defines the structure of an off-chain readiness attestation. Phase 2 is schema-only: no cryptographic signing, no wallet connection, no on-chain write. #### Evidence hash concept The `evidenceHash` field is an opaque string representing a hash of the evidence that supports a readiness action. For example: * For an on-chain migration: a hash of the transaction hash and target address * For a vault readiness check: a hash of the readiness score snapshot * For watchlist monitoring: a hash of the wallet address and configuration timestamp The evidence hash format is determined by the calling context. WalletWall does not verify the hash against external sources in Phase 2. #### Replay prevention and nonce The `nonce` field prevents replay of an attestation across different contexts. It must be a unique string per attestation issuance — typically a UUID, a random hex string, or a timestamped value. WalletWall does not enforce a specific nonce format. #### Attestation shape ```json theme={null} { "type": "walletwall.proofOfReadiness", "version": "0.1", "chainId": 1, "walletAddress": "0xab12cd34...", "actionType": "exposure_reduction", "actionId": "exposure_reduction", "evidenceHash": "0xdeadbeef1234...", "issuedAt": "2026-01-01T00:00:00.000Z", "expiresAt": "2026-04-01T00:00:00.000Z", "nonce": "a1b2c3d4-e5f6-7890-abcd-ef1234567890", "attestor": "walletwall", "custody": "none", "disclaimer": "This attestation confirms a readiness action only..." } ``` #### Attestations are not payouts Attestations in Phase 2 are schema-only records. They are not financial instruments, not payouts, not reward claims, and do not represent a claim on any asset. They are not written on-chain. They do not require wallet connection. They are not signed cryptographically in Phase 2. WalletWall does not custody assets and this attestation is not a guarantee of any reward. ## Phase 3: Readiness campaigns Phase 3 introduces readiness campaigns — structured sets of security-positive actions that help wallets, DAOs, and protocols coordinate quantum migration readiness. Campaigns are informational scaffolding only: no custody, no payouts, no staking, no protocol reward routing, and no on-chain writes. ### What a readiness campaign is A readiness campaign bundles: * A targeted wallet audience (individual wallet, whale wallet, DAO treasury, protocol team) * A clear security goal (migrate, monitor, attest, configure recovery) * A set of eligible Phase 1 readiness action IDs * A sponsor model (native preview or future sponsor) * Structural invariants: `custodyRequired: false`, `payoutImplemented: false`, `protocolRoutingImplemented: false` Campaigns do not create new custody, payout, or staking mechanics. They are a way to communicate which combinations of readiness actions are most relevant for a given wallet type, and why. ### Campaign table | Campaign | Audience | Goal | Eligible actions | Sponsor model | | ------------------------------ | ----------------- | ------------------------------------------ | -------------------------------------------------------- | --------------------------- | | Quantum Exposure Reduction | Whale Wallet | Verify migration from exposed wallet | exposure\_reduction, attestation | walletwall\_native\_preview | | Dormant Whale Readiness | Whale Wallet | Enable monitoring + configure recovery | monitoring, recovery\_setup, attestation | walletwall\_native\_preview | | Vault Readiness | Individual Wallet | Demonstrate vault-readiness on testnet | vault\_readiness, recovery\_setup, attestation | walletwall\_native\_preview | | Watchlist Monitoring | Individual Wallet | Activate watchlist coverage | monitoring | walletwall\_native\_preview | | DAO Treasury Migration | DAO Treasury | Governance-coordinated migration readiness | governance\_participation, vault\_readiness, attestation | dao\_sponsored\_future | | Proof-of-Readiness Attestation | Individual Wallet | Issue a verified off-chain attestation | readiness\_attestation + any completed action | walletwall\_native\_preview | All campaigns are in preview/model-only status. No sponsor marketplace is implemented. Protocol Reward Routing remains future optional scope. ### Campaign eligibility `getReadinessCampaignsForWallet(walletSignals)` maps existing wallet signals to recommended campaigns: ```js theme={null} // Readiness-campaign eligibility mapper const campaigns = getReadinessCampaignsForWallet({ hasSignatureExposure: true, estimatedValueUsd: 500_000, dormantDays: 400, vaultEligible: true, watchlistEnabled: false, governanceContext: { proposalCount: 2 }, attestationReady: true, }); // → [ quantum_exposure_reduction, dormant_whale_readiness, vault_readiness, // watchlist_monitoring, dao_treasury_migration, proof_of_readiness_attestation ] ``` Rules are conservative — campaigns are only recommended when a concrete signal supports the recommendation. ### Why campaigns do not require custody or deposits Each campaign targets a verifiable on-chain or local-state signal (signature exposure, dormancy, vault candidate classification, watchlist state, governance participation, completed action). There is no deposit gate, no lock-up, no APY, and no staking requirement. The campaign model is aligned with security outcomes, not with capital flows. ### Future sponsor model Future sponsor models (`dao_sponsored_future`, `protocol_sponsored_future`, `ecosystem_sponsored_future`) are defined structurally but not implemented. When sponsor campaigns are introduced, they will remain non-custodial: a sponsor funds the coordination infrastructure, not the wallets participating in it. See [proof-of-readiness-campaign-roadmap](/features/proof-of-readiness-campaign-roadmap) for the product-strategy view. ## Phase 3.5: Deterministic evidence hashes Phase 3.5 adds a set of evidence helpers that build privacy-safe evidence payloads and compute deterministic evidence hashes. These hashes are what attestations reference in their `evidenceHash` field. ### How evidence hashes work An evidence hash is a stable `0x`-prefixed SHA-256 digest of a redacted evidence payload. The payload captures the observable signals (dormancy, exposure tier, vault eligibility) that motivated a readiness action, without including any raw wallet data or identity information. The hash commits to those signals without exposing them. Every evidence payload is normalized before hashing: only an explicit allowlist of signal fields (such as `hasSignatureExposure`, `dormantDays`, `migrationReadinessTier`, `vaultEligible`) is preserved. All other fields — including any identity-revealing, financial, or sensitive data — are stripped before the payload is constructed. The payload's `privacy` field is always `"redacted"` and `custody` is always `"none"`. Sensitive fields that are always stripped: `privateKey`, `seed`, `seedPhrase`, `mnemonic`, `secret`, `email`, `ipAddress`, `sessionToken`, `accessToken`, `rawTransactionHistory`, `fullBalanceHistory`, `amount`, `payout`, `rewardToken`, `apy`, `yield`, `stake`, `deposit`. Before hashing, the payload is serialized with keys sorted alphabetically at every level. This means the same semantic payload always produces the same hash regardless of the JavaScript key-insertion order. Attestations and reward events that reference the hash can be independently re-verified by any party that holds the original payload. ### Why evidence hashes are not payouts, custody, or guarantees An evidence hash proves that a normalized snapshot of readiness signals was observed at a point in time. It is: * **Not a financial instrument.** Hashing signals creates no financial entitlement. * **Not custody.** WalletWall does not hold assets, keys, or any value as a result of creating evidence. * **Not a guarantee.** A hash does not guarantee that any reward, payout, or distribution will follow. * **Not on-chain.** Evidence payloads and their hashes are off-chain only. ### Evidence payload shape ```json theme={null} { "type": "walletwall.readinessEvidence", "version": "0.1", "chainId": 1, "walletAddress": "0xab12cd34...", "actionId": "exposure_reduction", "campaignId": "quantum_exposure_reduction", "evidenceType": "exposure_reduction", "observedAt": "2026-01-01T00:00:00.000Z", "signals": { "hasSignatureExposure": true, "dormantDays": 400, "estimatedValueBand": "high", "migrationReadinessTier": "urgent" }, "privacy": "redacted", "custody": "none" } ``` `campaignId` is optional and only present when the evidence is tied to a specific readiness campaign. ### Creating an evidence hash ```js theme={null} // Evidence-hash and attestation helpers const evidence = createReadinessEvidence({ chainId: 1, walletAddress: '0xab12cd34...', actionId: 'exposure_reduction', evidenceType: 'exposure_reduction', campaignId: 'quantum_exposure_reduction', signals: { hasSignatureExposure: true, dormantDays: 400, estimatedValueBand: 'high', }, }); // → { payload: { ... }, hash: '0x3a7f...' } ``` ### Attestation referencing an evidence hash An attestation can be created from an evidence object directly; the `evidenceHash` is derived automatically: ```js theme={null} const attestation = createProofOfReadinessAttestation({ chainId: 1, walletAddress: '0xab12cd34...', actionType: 'exposure_reduction', actionId: 'exposure_reduction', evidence, // hash derived from evidence.hash nonce: 'a1b2c3d4-e5f6-...', }); // attestation.evidenceHash === evidence.hash ``` A direct `evidenceHash` string can still be passed and takes precedence over `evidence.hash`, preserving the existing Phase 2 API. ### Allowed evidence types | Evidence type | When to use | | -------------------------- | ------------------------------------------------------------------- | | `exposure_reduction` | Signature-exposed wallet has completed or is eligible for migration | | `vault_readiness` | Wallet meets vault-candidate classification threshold | | `recovery_setup` | Recovery path has been configured or simulated | | `monitoring_enabled` | Watchlist monitoring has been activated | | `governance_participation` | Wallet has participated in migration governance | | `readiness_attestation` | General readiness review has been completed | | `campaign_eligibility` | Wallet qualifies for a specific readiness campaign | ### Allowed signal fields (allowlist) | Signal field | Type | Description | | ------------------------ | ------- | ------------------------------------------------- | | `hasSignatureExposure` | boolean | Whether the wallet's public key is exposed | | `dormantDays` | number | Days since last on-chain activity | | `estimatedValueBand` | string | Rough value tier (`low`, `medium`, `high`) | | `migrationReadinessTier` | string | Readiness classifier output | | `vaultEligible` | boolean | Whether the wallet meets vault-candidate criteria | | `watchlistEnabled` | boolean | Whether watchlist monitoring is active | | `recoveryConfigured` | boolean | Whether a recovery path is configured | | `governanceContextType` | string | Type of governance context observed | | `attestationReady` | boolean | Whether a readiness attestation can be issued | | `campaignEligible` | boolean | Whether the wallet is eligible for a campaign | | `actionCompleted` | boolean | Whether a specific readiness action is completed | ## Copy guardrails The following phrases are prohibited throughout all Proof-of-Readiness Rewards copy, enforced by the test suite: * `earn interest` * `guaranteed yield` * `deposit to earn` * `WalletWall pays APY` * `passive income` * `risk-free` * `insured` * `bank-like` These guardrails ensure that the rewards model is never misread as a financial product. ## Related The product-strategy view: marketing themes, sponsor model progression, and deferred items for these reward categories. The full non-custodial boundary — no stored keys, no seed phrases, no fund movement — that constrains this entire rewards model.