Skip to main content
A readiness packet is a dated, versioned, read-only snapshot of one wallet’s stablecoin vault-readiness assessment — the artifact you can hand to a treasury committee, a DAO forum, or a due-diligence thread. It travels as a link:
https://vault.walletwall.org/packet#<encoded packet>

What a packet is — and is not

  • It is a self-describing summary: recommendation, score band, risk drivers, evidence references, data-freshness stamps, generation time, and WalletWall’s boundary statements embedded in the data itself.
  • It is not an endorsement, attestation, or certification of the wallet it describes, and it is never a custody, insurance, or return claim. Readiness signals are research heuristics. A packet with a missing score honestly reads “insufficient evidence” — never zero.
  • Boundary statements are non-strippable: a payload without them is rejected as invalid by the packet page.

The privacy model

Everything after the # is a URL fragment. Fragments are never sent in HTTP requests, so the packet content — including the wallet address — never reaches WalletWall’s servers, CDN logs, or analytics when a link is opened. Analytics page-view URLs additionally redact any payload-sized fragment. Sharing a link is still publishing: anyone holding it can read the packet. A “share without address” variant is issued separately for redacted sharing.

Two independent checks

Every issued packet carries two verifiable properties: 1. Integrity — the content hash (evidence.reportHash). SHA-256 over the packet’s canonical JSON: recursively key-sorted, no insignificant whitespace, with evidence.reportHash set to null and the issuerSignature field removed before hashing. To verify independently: download the packet JSON, apply those two exclusions, canonicalize, hash, and compare. A mismatch usually means a truncated link — ask for the JSON file. 2. Authenticity — the issuer signature (issuerSignature). An ECDSA P-256 signature over the same canonical bytes (with only issuerSignature removed), created by WalletWall’s server when it derived the packet from its own scheduled data. Verify against WalletWall’s published packet-signing public key. The hash alone proves a link wasn’t corrupted; only the signature proves WalletWall issued the content. The packet page renders the full presentation only when the signature verifies — unsigned or altered payloads get a warning and the raw JSON, nothing more.

Fail-closed by design

Issuance is server-side only and fail-closed: a deployment without a signing key answers 503 and never issues an unsigned packet. Clients ship without a pinned verification key until one is published, and until then treat every payload as unverified. Signed still does not mean endorsed — the signature proves WalletWall’s server derived the content from its data at the stated time, nothing more.