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

Exposure reduction

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

Vault readiness

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

Recovery setup

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

Monitoring

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

Governance participation

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

Readiness attestation

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:

import { getProofOfReadinessRewardActions } from 'src/lib/proof-of-readiness-rewards.js';

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 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.

Local reward ledger

The local reward ledger (src/lib/proof-of-readiness-ledger.js) 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

Reward event shape

A reward event is a plain object with no financial fields:

{
  "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 (src/lib/proof-of-readiness-attestations.js) 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

{
  "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:

import { getReadinessCampaignsForWallet } from 'src/lib/proof-of-readiness-campaigns.js';

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 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 for the product-strategy view.

Phase 3.5: Deterministic evidence hashes

Phase 3.5 adds src/lib/proof-of-readiness-evidence.js — a set of helpers that build privacy-safe evidence payloads and compute deterministic evidence hashes. These hashes are what attestations reference in their evidenceHash field.

What evidence hashes are

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.

Why payloads are redacted

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.

Why hashes are deterministic

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

{
  "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

import { createReadinessEvidence } from 'src/lib/proof-of-readiness-evidence.js';
import { createProofOfReadinessAttestation } from 'src/lib/proof-of-readiness-attestations.js';

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:

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.

​Proof-of-Readiness Rewards

​What this is

​What this is not

​Why quantum migration is a governance coordination problem

​Reward action categories

​Exposure reduction

​Vault readiness

​Recovery setup

​Monitoring

​Governance participation

​Readiness attestation

​Eligibility model

​Future scope: Protocol Reward Routing

​Non-custodial guarantees

​Phase 2: Local reward ledger and attestation schema

​Local reward ledger

​Readiness statuses

​Reward event shape

​Proof-of-Readiness attestation schema

​Evidence hash concept

​Replay prevention and nonce

​Attestation shape

​Attestations are not payouts

​Phase 3: Readiness campaigns

​What a readiness campaign is

​Campaign table

​Campaign eligibility

​Why campaigns do not require custody or deposits

​Future sponsor model

​Phase 3.5: Deterministic evidence hashes

​What evidence hashes are

​Why payloads are redacted

​Why hashes are deterministic

​Why evidence hashes are not payouts, custody, or guarantees

​Evidence payload shape

​Creating an evidence hash

​Attestation referencing an evidence hash

​Allowed evidence types

​Allowed signal fields (allowlist)

​Copy guardrails

Proof-of-Readiness Rewards

What this is

What this is not

Why quantum migration is a governance coordination problem

Reward action categories

Exposure reduction

Vault readiness

Recovery setup

Monitoring

Governance participation

Readiness attestation

Eligibility model

Future scope: Protocol Reward Routing

Non-custodial guarantees

Phase 2: Local reward ledger and attestation schema

Local reward ledger

Readiness statuses

Reward event shape

Proof-of-Readiness attestation schema

Evidence hash concept

Replay prevention and nonce

Attestation shape

Attestations are not payouts

Phase 3: Readiness campaigns

What a readiness campaign is

Campaign table

Campaign eligibility

Why campaigns do not require custody or deposits

Future sponsor model

Phase 3.5: Deterministic evidence hashes

What evidence hashes are

Why payloads are redacted

Why hashes are deterministic

Why evidence hashes are not payouts, custody, or guarantees

Evidence payload shape

Creating an evidence hash

Attestation referencing an evidence hash

Allowed evidence types

Allowed signal fields (allowlist)

Copy guardrails