Get Started

Start from the z00z Rust monorepo, not from the website that publishes these docs. The Developers section is for builders working in z00z-labs/z00z: the live workspace, crates, binaries, tests, verification scripts, and research corpus that define what can honestly be claimed today.

The practical goal is simple. By the end of the session you should be able to install the Rust toolchain, compile the workspace, inspect the live rollup-node and simulator entrypoints, identify which crate owns a change, run the real verification gate, and separate code-proved behavior from corpus-backed target architecture.

First Session Checklist

Start at the z00z repository root. The fastest trustworthy first pass comes from the README quickstart and the current workspace manifests, not from guessed daemon commands or website-local tooling.

rustup toolchain install stable
rustup component add rustfmt clippy
cargo check --workspace
cargo run -p z00z_rollup_node -- --help
cargo run -p z00z_simulator --bin scenario_1 -- --help

Those commands prove three things early: the Rust workspace resolves, the current rollup-node CLI surface exists, and the simulator binary surface exists. Only after that should you branch into crate-specific work such as wallet flows, storage proofs, RPC plumbing, or WASM output.

Pick The Right Surface

Most first contributions in z00z should start by choosing the owning crate or artifact, not by opening the nearest doc page. The workspace already separates foundations, runtime, client, storage, simulator, and research surfaces. A good first change keeps that split intact.

That split prevents the most common first-session mistake: changing docs or prose when the real issue is a crate, manifest, test, or CLI contract in the main workspace.

Understand The Workspace Before Editing

The main mental model is crate ownership, binary ownership, and maturity ownership:

If a claim is about a command, feature, bin, or crate boundary, the manifest and script win. If a claim is about the broader settlement model, privacy posture, rights model, or migration path, the whitepaper corpus wins. If neither source proves the sentence, the sentence is not ready.

Edit-To-Verify Flow

The safest first-session loop is short enough to memorize:

The evidence step is not optional. If the claim is about a live command, use README.md, Cargo.toml, a crate manifest, a Rust source file, or the verification script. If the claim is about assets, rights, vouchers, settlement, wallet-local possession, privacy, legal posture, or post-quantum migration, use content/whitepapers/ and cite the exact section that carries the claim.

What Verification Covers

cargo check --workspace, cargo test --workspace, and the full verify script are real local gates, but they are not magical proofs of every whitepaper ambition. They prove the current workspace surface. They do not automatically prove every broader architecture statement in the research corpus.

For developer-facing changes, you also need source-local checks:

If a page says that z00z ships a complete public RPC, a production recovery service, or a fully proved whitepaper lane that the code does not support, the page is still wrong even if the workspace compiles cleanly. Verification correctness is not claim correctness.

Manual Review Before Closeout

Before you summarize a change, do one manual pass that the scripts cannot fully replace. Re-read every present-tense implementation sentence. If it names a command, bin, test, feature, or crate, the evidence should be in the z00z repo. If it names settlement behavior, privacy guarantees, disclosure scope, governance, or post-quantum posture, the evidence should be in the whitepaper corpus and the wording should say whether the claim is live, target, or conceptual.

This review matters because developer pages sit between two worlds. They must help builders act on the live workspace, but they also introduce protocol concepts that are broader than the current code. The page is complete only when both sides are readable without confusion.

Common First-Session Mistakes

The fastest way to create drift is to import assumptions from a different kind of repository. Avoid these patterns:

A Good First Change

A good first change is narrow but evidence-rich. For example, tighten a developer page so it cites the current workspace manifest and the right whitepaper sections, align a CLI claim with the actual --help output, add a targeted test near the changed crate, or correct a maturity statement that widened beyond what the repo proves. Keep the summary factual: what changed, what verified, and which warnings remain.

If an AI assistant is involved, route it through the same discipline. It should read the request, inspect the target manifests and source files, keep artifacts in English, avoid destructive operations, run the real verification path, and separate live implementation claims from corpus architecture. Automation is useful here only when it strengthens evidence.

Read Next

Continue to Workspace to understand crate ownership, then read Verification And Tests for the real gate stack. Open Core Protocol API and Rollup Node when you are ready to connect code surfaces to the protocol model.

Evidence and Further Reading

• github.com/z00z-labs/z00z, README.md, and Cargo.toml define the live quickstart, workspace members, Rust version, and common workflows used 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 cited here.
• ./.github/skills/z00z-full-verify-gate/scripts/full_verify.sh in the z00z repo defines the broad verification gate used here.
• Main Whitepaper sections 3, 4, and 12 distinguish object semantics, settlement boundaries, and live-versus-target maturity.