​

WalletWall Proof Claim Schema

Scope. This document defines the proof-claim-schema.js — the application-level typed schema for future proof artifacts. It introduces no prover, verifier, circuit, or contract code, changes no runtime behavior, and changes no Dune behavior. It is the natural next step after the proof-readiness architecture map (proof-readiness-stack.md).

• Proof-Readiness Architecture — the pipeline, ML-DSA vs ZK/SP1 distinction, and the claim-contract template this schema implements.
• Vault-first positioning — canonical thesis and copy red-lines.
• Complementary feature alignment — surface jobs and Phase 0–4 roadmap.
• ZK Proof-Artifact Roadmap — staged, non-production ZK/SP1 next steps.
• Dune query guardrails — read-only / cache-only Dune posture (unchanged by this schema).

​

1. Purpose

If a future ZK or attestation layer were to produce a claim about a readiness computation, what shape should that claim take — and what must it explicitly disclaim?

​

2. Schema file

src/lib/proof-claim-schema.js

​

3. Claim types

​

4. Proof systems

​

5. ML-DSA vs ZK/SP1

​

6. Verification status

​

7. How it attaches to the Readiness Packet

Readiness Packet
  └── proofExtension (optional — present only when proofClaims passed)
        ├── proofClaims: ProofClaim[]
        ├── proofLimitations: string[]   ← mandatory limitations from schema
        └── proofReadinessVersion: string

// Build the optional extension block from proof claims:
import { buildProofClaimsPacketExtension } from './src/lib/proof-claim-schema.js';
const extension = buildProofClaimsPacketExtension([myClaim]);

// Attach to a packet:
import { buildVaultReadinessPacket } from './src/lib/buildVaultReadinessPacket.js';
const packet = buildVaultReadinessPacket(readiness, { proofClaims: [myClaim] });
// packet.proofExtension is now present

​

8. Safe limitations

• A proof claim is not custody. WalletWall holds no keys, funds, or balances.
• A proof claim produces no yield, interest, or return.
• A proof claim is not fund protection. Readiness signals are research heuristics and do not insure or protect holdings.
• A proof claim does not prove source-data truth. It binds a computation to committed inputs only.
• A proof claim does not guarantee readiness, protection, safety, or any outcome.
• A proof claim does not imply quantum resistance or quantum immunity; post-quantum verifier work is read-only research on testnet only.
• Candidate proof systems (sp1_candidate, zk_candidate) are not implemented in production and carry no production verifier guarantee.
• An ML-DSA attestation answers “who signed?” (authenticity) only; it is not a computation-correctness proof.
• A ZK/SP1 candidate proof would answer “was this computation correct?” only; it says nothing about the truth of upstream source data or the identity of the signer.
• No proof claim requires or implies that a user must connect a wallet, sign a transaction, or write to any chain.

​

9. Why SP1 is future / candidate only

1. The claim must be stable before the prover is built. A stable claim schema is a prerequisite for scoping a prover — the claim defines what the proof must assert and what it explicitly does not.
2. SP1 is one option, not the only option. RISC Zero or another zkVM could fill the same slot. The zk_candidate key exists for a prover-agnostic design option.
3. No SP1 implementation is in this app. The app imports no prover, verifier, circuit, or program from the public vault research repo at runtime.
4. Production verification is always out of scope until independently reviewed and explicitly authorized. No ProofClaim from this schema may set verificationStatus = "verified" for a candidate proof system.

​

10. Mock claim builder

• Uses proofSystem: 'mock' by default.
• Can produce a sp1_candidate or zk_candidate fixture if options.proofSystem is set explicitly.
• Performs no I/O, no clock reads, and no proving.
• Derives a stable claimId from claimType, subject address/symbol, and chain.
• Always includes the mandatory limitations plus a mock-specific disclosure.
• verificationStatus is not_applicable for mock, unsupported for candidates.

​

11. Non-goals

• Implement SP1 prover or verifier code.
• Implement ZK circuits or programs.
• Import contracts, ABIs, or implementation details from the public vault research repo.
• Add custody, yield, fund movement, or wallet-signing behavior.
• Require mainnet writes or wallet connections.
• Prove that Dune, on-chain, or any external source data is globally true.
• Guarantee readiness, safety, protection, or any specific outcome.
• Provide production on-chain verification of any proof.

​

12. Dune / source-data boundary

• No Dune queries are executed, scheduled, refreshed, or modified.
• Proof claims reference committed inputs; they do not assert that the inputs from Dune or on-chain sources are globally true.
• Existing Dune guardrails (assertDuneExecutionAllowed, readOrCache, getOrCache) are preserved unchanged.