Storage is not just a database choice in Z00Z. It is an authority boundary. A builder can cache wallet state, index service events, and store operational metadata, but only canonical settlement roots and their proof semantics can answer whether a committed object is part of the protocol state. This page uses HJMT-style language as a builder-facing model for sparse authenticated paths: keys map to deterministic positions, leaves commit to typed state, and proofs bind a path to a root. It does not claim that this website repository ships a protocol storage engine.

The current repository surface is documentation and content infrastructure. The live local anchors are content/docs, content/whitepapers, src/lib/content/docs.ts, src/lib/content/markdown.ts, and the verification scripts under scripts/. Protocol storage, root production, witness formats, and replay protection are target architecture described by the whitepaper corpus. Any implementation that grows from this page should therefore start by separating two questions: what does the docs site prove today, and what must a future settlement implementation prove before it can be called authoritative?

Authority Boundary

Canonical storage is the layer that accepts or rejects state transitions. It is not equivalent to a wallet cache, a browser database, a service index, or a JSON response from an RPC endpoint. A wallet may know more private data than the chain commits. A watcher may see more operational events than a user interface shows. A publication service may hold pending batches that are not yet final. Those surfaces can be useful, but they are not the settlement authority.

The Main Whitepaper separates canonical objects such as AssetLeaf, SettlementPath, TxPackage, ClaimTxPackage, CheckpointExecInput, CheckpointArtifact, and CheckpointLink. That vocabulary matters because packages and service messages are not the same thing as canonical state. A package may request a transition. A proof may demonstrate a relationship to a root. A checkpoint may bind a batch of work to a published artifact. None of those should be described as final state until the settlement boundary has accepted it.

In implementation terms, storage authority requires at least four properties. First, keys and paths must be deterministic so independent verifiers derive the same location for the same committed object. Second, leaves must be typed so an asset, right, voucher, nullifier, or checkpoint record cannot be interpreted as another class of state. Third, roots must be reproducible from the accepted transition set. Fourth, proof verification must be defined independently from the service that transported the proof.

HJMT-Style Path Semantics

HJMT-style language is useful because it forces builders to think in paths, not tables. A sparse authenticated tree lets a verifier ask whether a key is present, absent, or updated under a specific root without trusting the storage operator’s database snapshot. The useful abstraction is:

• A domain-separated key is derived from object type and object identity.
• The key selects a path in a sparse authenticated structure.
• The leaf commits to the canonical fields for that object type.
• A proof carries sibling commitments needed to connect the leaf or absence to a root.
• A verifier checks the proof against a root it already accepts from the settlement or checkpoint layer.

The docs site does not implement those functions. It can, however, document the terms consistently and prevent drift. For example, if a future storage guide uses SettlementPath, it should mean a path that binds object identity to a settlement root, not a frontend route, filesystem path, or arbitrary service locator. If a future example says “proof,” it should identify whether it is a membership proof, non-membership proof, transition witness, fraud proof, or service attestation.

This diagram is intentionally about proof shape, not storage vendor choice. A future node may persist state in RocksDB, SQLite, an append-only file, or a custom storage service. The authority comes from the root and verification rules, not the persistence backend.

Canonical State Versus Wallet State

The Assets, Rights, and Vouchers paper distinguishes what belongs in committed state from what remains in wallet payloads, witnesses, or service-side context. Canonical state should hold commitments, typed leaves, root relationships, nullifier or spentness signals where applicable, and state needed for settlement validity. It should not hold every plaintext policy, every private wallet memo, every UI explanation, or every support artifact.

Wallet state can include private descriptions, receiver material, policy explanations, recovery metadata, and data needed to make sense of a commitment. That information may be essential to the user, but it is not automatically public canonical state. Service state can include publication queues, retry records, telemetry, fraud-case coordination, and support artifacts. That can help operate the network, but a service database cannot override a root.

The boundary is especially important for rights and vouchers. A right may have conditions attached to use or transfer. A voucher may represent access, entitlement, or redemption logic. The committed leaf should identify the settlement-relevant facts. The wallet or witness layer should carry private context and selective disclosure material. Builders should avoid designs that put all policy text directly into canonical storage simply because it is easier to query.

Replay Protection

Replay protection prevents a valid-looking artifact from being reused in the wrong domain, epoch, chain, account, path, or settlement context. The Linked Liability paper makes this important by introducing conflict detection, fraud proof extraction, lock registries, bonds, penalty ladders, quarantine states, and scoped exculpability. If a claim, bond, proof, or lock message can be replayed outside its intended context, the liability surface becomes unsafe.

Replay protection belongs in the data model, not just in transport code. A builder should expect domain separation for object classes, chain or network identifiers, version identifiers, epoch or checkpoint identifiers where needed, and unique transaction or package identifiers. Nullifiers must be scoped to the domain they protect. A spentness signal for one object class should not become valid evidence for another class. A fraud proof tied to one checkpoint should not be accepted as if it were extracted from another checkpoint.

The storage layer should therefore reject ambiguous writes. If two transitions try to spend the same committed right, publish conflicting leaves, or reuse a claim path in a forbidden domain, the storage authority must make that conflict visible to settlement logic. A service can help detect the issue, but the final answer must be reproducible from roots, proofs, and accepted rules.

Builder Checklist

Use this checklist when turning the storage model into code:

• Define object domains before defining keys.
• Separate canonical leaves from wallet payloads and service records.
• Include versioning and network context in every replay-sensitive artifact.
• Treat proof verification as independent from RPC transport and service trust.
• Keep absence proofs explicit; absence can be as important as membership.
• Record whether a root is tentative, soft-confirmed, checkpointed, or final.
• Keep fraud and liability artifacts scoped to the root and checkpoint that produced them.
• Do not expose raw private wallet context from storage APIs unless the user has explicitly chosen to disclose it.

For this repository today, the closest runnable evidence is the content pipeline. src/lib/content/docs.ts loads typed page metadata, src/lib/content renders and sanitizes content, and scripts/verify.sh checks the public site surface. That proves documentation integrity, not settlement storage. Future protocol storage tests should be separate from website verification and should exercise roots, path derivation, proof verification, replay rejection, and conflict extraction directly.

Review Questions

Before a storage design is accepted, reviewers should ask which root is being trusted, who produced it, how a verifier obtains the data needed to reproduce it, and what happens when a proof conflicts with service state. They should also ask whether every private field in the design is actually needed in canonical state. If the answer is “the service knows,” the design has not yet crossed the authority boundary cleanly.

For documentation reviews, the same questions become claim checks. A docs page should not say “stored on-chain” unless the source material defines the committed field. It should not say “verified” unless it identifies the proof and root. It should not say “replay-safe” unless the replay domain is named. Those small wording choices prevent future builders from implementing the wrong storage contract.

Read Next

• RPC for transport boundaries around storage queries.
• Rollup Node for publication and checkpoint responsibilities.
• Verification And Tests for separating docs verification from future protocol verification.

Evidence and Further Reading

• Main Whitepaper sections 3, 4, and 8 for canonical object vocabulary, rollup boundaries, and publication flow.
• Assets, Rights, And Vouchers Whitepaper section 9 for canonical state versus wallet and witness payload boundaries.
• Linked Liability Whitepaper sections 5-7 for conflict detection, fraud proofs, lock registries, and scoped liability artifacts.
• src/lib/content/docs.ts for the current repository’s live content-loading authority.
• scripts/verify.sh for the current repository verification wrapper.