Core Protocol API

This page is called an API page because builders need an implementation-shaped mental model. It is not a generated reference for local functions in this website repository. The current repo can prove the docs loader, Markdown renderer, route structure, verification scripts, and corpus content. The protocol API families below are corpus-backed architecture: they describe the surfaces a real implementation must keep separate.

The core design starts from a no-account premise. Public settlement should not become a reusable balance table. Wallets can know ownership, prepare packages, and interpret private rights locally; public state should see committed objects, typed paths, replay artifacts, and checkpoint evidence.

The API Families

A future core implementation should expose API boundaries around seven families:

Family	Developer job	Evidence source
Objects	Represent `Asset`, `Voucher`, `Right`, and live settlement leaves without collapsing their meanings	Main Whitepaper section 3, Assets/Rights/Vouchers sections 3-9
Commitments	Bind confidential amounts, ownership metadata, policy hashes, and action roots	Main Whitepaper section 3 and appendix B
Roots	Track canonical state under settlement paths and checkpoint roots	Main Whitepaper sections 3-4
Checkpoints	Turn ordered packages into replay-safe settlement truth	Main Whitepaper sections 3-4
Validation	Reject malformed packages, duplicate replay artifacts, policy mismatches, and invalid proof surfaces	Main Whitepaper section 3, Smart Cash sections 5-6
Policy	Classify cash, voucher, right, action, and fee-support rules without inventing a universal hidden VM	Assets/Rights/Vouchers sections 4-9
Disclosure	Keep public evidence, wallet-local secrets, selective audit, and liability reveal separate	Privacy and Legal authority pages

None of those families should become one giant doEverything() API. Z00Z’s safety comes from making boundaries explicit.

Conceptual Surface Diagram

flowchart TD Wallet["Wallet-local API\npossession, receiver material,\npackage assembly"] --> Package["Package API\nTxPackage, ClaimTxPackage,\nrequest intent"] Package --> Validation["Validation API\nsyntax, proofs, replay,\npolicy checks"] Validation --> Checkpoint["Checkpoint API\nexecution input, artifact,\nlink, finality"] Checkpoint --> State["State API\nSettlementPath,\nSettlementLeaf,\nroot continuity"] Policy["Policy API\nCashPolicy, VoucherPolicy,\nRightPolicy, ActionPool"] --> Validation Disclosure["Disclosure API\nselective audit, reveal,\nevidence packages"] --> Package Evidence["Evidence API\nroots, deltas, proofs,\npublication artifacts"] --> Checkpoint style Wallet fill:#E3F2FD,stroke:#1E88E5,stroke-width:1px,color:#0D47A1 style Package fill:#FFF3E0,stroke:#FB8C00,stroke-width:1px,color:#E65100 style Validation fill:#F3E5F5,stroke:#8E24AA,stroke-width:1px,color:#4A148C style Checkpoint fill:#EDE7F6,stroke:#5E35B1,stroke-width:1px,color:#311B92 style State fill:#E8F5E9,stroke:#43A047,stroke-width:1px,color:#1B5E20

The diagram is deliberately conceptual. It teaches the boundary between wallet preparation, package validation, checkpoint finality, and state roots. It does not assert that these exact module names are exported by this website repository.

For implementation planning, read each box as a responsibility seam. A concrete project might choose different package names, modules, or crate boundaries, but it still needs a way to keep wallet-local possession, package transport, validation, checkpoint evidence, and state roots from collapsing into one ambiguous API.

Object Model

The object model is the first API boundary. Asset is final value. Voucher is conditional value. Right is authority without value. The terminology paper also names live structural settlement terms such as AssetLeaf, RightLeaf, VoucherLeaf, SettlementLeaf, and SettlementPath. A developer API should preserve those distinctions because each object answers a different question.

Object	Must mean	Must not become
`Asset`	Final spendable value, especially clean native cash under a fixed cash policy	Arbitrary programmable cash with hidden restrictions
`Voucher`	Conditional value with backing, lifecycle, redeem, refund, partial redeem, or expiry semantics	Dirty cash or an authority object that secretly carries value
`Right`	Bounded authority over an object, action, or scope	A hidden value container
`SettlementLeaf`	Structural committed state family under one settlement root contract	A second public account tree

This is where many fake API designs fail. They start by asking for account balances and token transfer endpoints. Z00Z needs object inventory, possession, package construction, policy classification, and checkpoint evidence instead.

Commitments And Roots

Commitments are the API layer that keeps public state narrow. A committed amount is not a plaintext balance. A policy hash is not a mutable rule document. An action root is not an off-chain operator promise. A settlement path is the place where committed state lives or disappears under a checkpointed transition.

The root boundary is equally important. A public root is useful only because it binds a precise state view and can be checked against typed deltas and checkpoint artifacts. It is not a marketing anchor. It is not proof that every local wallet story is true. Developers should design root APIs so callers can ask specific questions: what root was used, which paths were consumed, which leaves were created, which proof bytes were checked, and which replay artifacts were accepted or rejected.

Checkpoints And Validation

Checkpoints are the public finality boundary. A wallet-prepared package can be useful before settlement, but it is not final state. An aggregator can admit or order work, but admission is not settlement. A validation API should make those states impossible to confuse.

At minimum, a checkpoint-facing implementation needs to separate:

State	Correct meaning
Wallet-prepared	A local package or request exists
Published or admitted	A service path has seen or accepted the candidate
Checkpoint candidate	The transition is part of a candidate execution input
Final checkpoint artifact	Public replay-safe evidence has been sealed
Settled state	The accepted root and deltas make the object live, consumed, or replaced

When a docs page says “payment sent” or “right accepted,” it should be clear which state is meant. User experience can be friendly, but developer APIs need precise states.

Policy And Action APIs

The Assets/Rights/Vouchers paper gives the cleanest policy split. Native cash should have a fixed CashPolicy. Vouchers may carry a bounded VoucherPolicy and committed ActionPool. Rights may carry a RightPolicy or dedicated policy commitments for transition, revocation, challenge, disclosure, and retention behavior. Those policy names are semantic contract surfaces; the page must not imply that every current crate or local file already exports exactly those type names.

The API lesson is that policy should compile into verifiable evidence. A wallet can assemble a package and gather signatures. A validator can check state inclusion, policy commitments, action membership, value conservation, and delta correctness. An external service can attest or maintain a registry only when that trust boundary is explicit.

Disclosure And Evidence

The core API should not make privacy depend on silence or vibes. It needs evidence channels. Ordinary public settlement should expose roots, deltas, proofs, and replay artifacts. Wallet-local possession should hold secrets, decrypted payloads, labels, and private decision history. Selective audit should export a bounded evidence package for a specific reviewer. Liability reveal should stay tied to a fraud or dispute domain, not become public transparency by default.

This is why a future developer API should distinguish “export settlement evidence” from “export wallet history.” They are not the same operation, and conflating them would undo the protocol’s privacy story.

Live Repo Boundary

In this website repo, you can inspect and change the docs that explain these API families. You can verify the site with npm run verify. You can trace how docs render through src/lib/content/docs.ts and src/lib/content/markdown.ts. You cannot prove a full protocol API surface by pointing only to this page. The correct local claim is that this page is the conceptual map used by developer docs and future references.

Evidence and Further Reading

Use the source bullets below as an audit checklist, not decoration: when reusing this page, preserve the named section scope, the responsible actor, and the split between live repository evidence, target architecture, and open design work.

Main Whitepaper sections 3 and 4 define canonical state objects, cryptographic proof discipline, checkpoints, rollup ordering, publication, and verification boundaries.
Assets, Rights, And Vouchers Whitepaper sections 3 through 9 define the Asset, Voucher, and Right triad, policies, action semantics, receiver safety, and settlement storage split.
Corpus Terminology And Abbreviations Reference section 3 defines canonical protocol and wallet terms such as SettlementLeaf, SettlementPath, Checkpoint, TxPackage, ReceiverCard, and PaymentRequest.
src/lib/content/docs.ts, src/lib/content/markdown.ts, and scripts/verify.sh are the local repo anchors for the website docs surface, not proof of a shipped full core protocol API.

Z00ZBlockchain