API Reference

This is a reference map, not an exhaustive generated API. The current z00z repository exposes real Rust crates, manifests, tests, binaries, feature flags, and CLI entrypoints. It does not yet expose a single generated public SDK catalog, stable RPC method registry, or one canonical operator API document for every runtime lane. Future implementation work should add generated references from real source code and tests when those surfaces are ready.

The main risk for an API page is false precision. A table of invented methods can look useful while creating concept drift. This reference therefore separates four layers: current live workspace surfaces, conceptual protocol vocabulary, future generated implementation APIs, and external interface expectations.

Before You Dive In

Read Developer Getting Started for the live workspace and Core API for the protocol vocabulary that future APIs must preserve. Use it to classify an interface claim, not as a ready-to-integrate HTTP or SDK contract.

API Layer Map

Use this map when reading any API claim. If the claim points to a real crate manifest, source file, test, example, or CLI help surface, it is live workspace evidence. If it points to whitepaper vocabulary, it is conceptual protocol evidence. If it points to a future module or external method catalog that does not exist yet, it must be marked “not yet generated.”

Current Live Surfaces

The current live surface includes:

• workspace crates declared in root Cargo.toml;
• operator and scenario entrypoints exposed by z00z_rollup_node and z00z_simulator;
• wallet library, bins, tests, and features exposed by z00z_wallets;
• crypto, storage, runtime, utility, and network crates in the active workspace;
• the broad verify gate in ./.github/skills/z00z-full-verify-gate/scripts/full_verify.sh.

These are real implementation surfaces, but they are not yet the same thing as a polished public API program. A crate can be live without every module being frozen as a downstream contract. A binary can be runnable without its CLI being final. The reference should therefore distinguish “exists in code” from “stable public interface.”

The README already names two especially important live entrypoints: cargo run -p z00z_rollup_node -- --help and cargo run -p z00z_simulator --bin scenario_1 -- --help. The wallet manifest adds more live surfaces such as z00z_wallet_egui, z00z-wallet-validate, and gen_password_bloom. Those are better API evidence than invented HTTP examples.

Conceptual Protocol Vocabulary

The Corpus Terminology Reference and Main Whitepaper provide the terms future APIs should preserve. Important names include AssetLeaf, RightLeaf, VoucherLeaf, SettlementLeaf, SettlementPath, Checkpoint, SettlementTheorem, ReceiverCard, PaymentRequest, TxPackage, ClaimTxPackage, CheckpointExecInput, CheckpointArtifact, and CheckpointLink.

These terms are conceptual unless backed by implementation code. They should guide naming and schema design, but they should not be documented as exported functions, endpoints, or classes until they exist. For example, a future generated API may expose submit_tx_package, but this repository should not list that as a runnable method unless source code and tests define it.

Vocabulary consistency still matters now. If docs pages use different names for the same object, builders will implement incompatible concepts later. This reference should therefore act as a map from current docs language to future implementation language.

Future Generated APIs

Future generated API references should come from real source artifacts. Good inputs include TypeScript types, OpenAPI specs, Rust docs, protobuf schemas, JSON schema files, route handlers, SDK source, or CLI definitions. Generated references should include request and response shapes, versioning, error classes, authentication requirements, privacy-sensitive fields, maturity labels, and examples that can be tested.

Until those artifacts exist, the correct status is “not yet generated.” A page can explain the intended layer and constraints, but it should not manufacture method signatures. When the implementation arrives, the generated reference should replace speculative tables rather than sit beside them as a parallel authority.

Not Yet Generated

The following reference surfaces are not generated by this repository today:

• Protocol RPC method catalog.
• Wallet SDK reference.
• Rollup node operator API.
• Settlement storage API.
• Useful-work evaluator API.
• Cross-chain locker or rights API.
• Public support or disclosure API.
• Browser WASM wallet API.
• Production network status API.

These surfaces may be valid future work. They are not yet live generated public interfaces. Any tutorial that depends on them should say “target architecture” or “future implementation” and link to the whitepaper sections that justify the concept.

Transport Boundaries

Future external APIs will likely include JSON or JSON-RPC-style transport. The RPC page covers that boundary in detail. For this reference page, the rule is that transport shape is not settlement authority. A method that returns “accepted” must define accepted by whom: transport validator, publication service, node validation, data availability, checkpoint process, or final settlement. A method that returns a proof must identify proof type, root source, domain, and verification method.

External interfaces should also define privacy-sensitive fields. Wallet IDs, receiver material, proof hints, policy text, support evidence, timing data, recovery records, and telemetry should not appear in generic examples unless the privacy boundary is explained.

Evidence-Linked API Concepts

An API concept is ready for documentation when it has evidence. Evidence can be one of four types:

• Local source evidence: concrete files under the z00z workspace such as Cargo.toml, crate manifests, src/, tests/, examples/, bin/, or repo scripts.
• Whitepaper evidence: a named section in the corpus defining the concept.
• External standard evidence: an official spec such as JSON-RPC or RFC 8259.
• Test evidence: deterministic validation proving behavior.

If a claim has only whitepaper evidence, it should be conceptual. If it has source and test evidence, it can be implementation-facing. If it has neither, it should not be in the API reference.

Reference Table Rules

When generated references are added later, each table should identify the layer, maturity, source file, test evidence, and privacy class. A method table without those fields is likely to imply more authority than it has. For example, a publication method should distinguish transport receipt from data availability, checkpoint maturity, and settlement. A wallet method should identify whether it handles local payloads, network publication, recovery, or selective disclosure. A support method should identify the evidence package and redaction policy.

Reference examples should be executable only when the backing endpoint or function exists. Otherwise they should be pseudo-structures labeled as target schema sketches. This protects readers from copying commands that cannot run and protects implementers from treating docs fiction as an API contract.

Current Route Caveat

The current CLI surfaces are intentionally narrower than a complete public API story. The README currently documents z00z_rollup_node --mode aggregator --aggregator-config <path> --planner-config <path> --storage-config <path> as the live rollup-node contract. That is useful evidence, but it is not yet a full operator handbook or a stable external network API catalog.

The same caveat applies to internal crate modules. They are reliable evidence for current implementation structure, but they are not automatically stable downstream contracts. Avoid promoting an internal helper to “the API” unless the repo already treats it that way through docs, tests, or generated reference output.

Naming Stability

API names should be stable because downstream builders copy them. When the corpus already defines a term, prefer that term over a friendlier synonym that changes meaning. For example, do not alternate between settlement path, storage path, proof path, and route path unless each term is intentionally different. Do not rename PaymentRequest to “payment link” in an API table if the protocol concept is a payment request with receiver material and policy context.

If a future implementation chooses a different exported name, the reference should explain the mapping instead of letting docs drift. One table can map canonical concept, exported type, route or method, source file, maturity, and test evidence. That kind of table is useful only after real source exists. Before that point, prose with explicit source links is safer than invented reference rows. Evidence should lead every exported name.

Read Next

• RPC for request, response, validation, and error boundaries.
• Examples And Tutorials for avoiding fake API examples.
• Verification And Tests for source-anchor and review checks.

Evidence and Further Reading

• github.com/z00z-labs/z00z, README.md, and root Cargo.toml define the live workspace, entrypoints, and crate set referenced here.
• crates/z00z_rollup_node/Cargo.toml, crates/z00z_simulator/Cargo.toml, and crates/z00z_wallets/Cargo.toml define the current node, simulator, wallet, bin, feature, and test surfaces used as API evidence here.
• Corpus Terminology And Abbreviations Reference section 3 for canonical protocol vocabulary.
• Main Whitepaper sections 3-4 for object and rollup boundary vocabulary.
• JSON-RPC 2.0 Specification: https://www.jsonrpc.org/specification.