Configuration And Genesis

Configuration and genesis are related, but they are not the same authority surface. The z00z repo already has real configuration loaders and live config entrypoints. They control how runtime and tool surfaces ingest environment variables and YAML files. They do not yet by themselves define one canonical launched genesis state, final validator set, treasury power map, or governance-approved network bootstrap artifact.

Builders must separate current repository-local configuration from target protocol genesis and avoid maturity claims that make a loader, CLI flag, or helper YAML file sound like a network launch artifact.

Current Repo Configuration

The live local configuration surface includes:

• crates/z00z_utils/src/config/env.rs for environment-variable reads.
• crates/z00z_utils/src/config/yaml.rs for bounded YAML loading.
• crates/z00z_utils/src/config/layered.rs for the current ENV > YAML > none precedence model.
• z00z_rollup_node CLI usage, which currently expects --aggregator-config, --planner-config, and --storage-config.
• crate manifests and feature flags that define optional runtime, wallet, and debug behavior.

These files and entrypoints are authoritative for the current workspace behavior they actually control. If LayeredConfig::with_yaml loads a specific YAML path, that is real config behavior. If the rollup-node help output requires three config paths, that is a real operator-facing contract. None of those facts imply that a final protocol genesis artifact has been published.

What Live Config Can Prove

Live config can prove how the current workspace reads and layers configuration. It can prove the YAML loader size bound, the environment override behavior, the expectation that some runtime surfaces receive explicit config paths, and the feature flags exposed by crate manifests.

Live config cannot prove a circulating supply, genesis allocation, treasury balance, validator set, DA adapter choice, chain ID, fee schedule, or governance quorum. If a future page needs those values, it should point to the real protocol-owned genesis or launch artifact after it exists. Until then, the page should say “target parameter,” “future genesis input,” or “not yet fixed by live repo evidence.”

This distinction is not pedantic. Genesis values are consensus and governance facts. Website values are presentation and local build facts. Mixing them can create public overclaims and later migration risk.

Protocol Genesis Concepts

A protocol genesis artifact normally defines the starting state and constraints from which all later state transitions derive. For Z00Z, future genesis parameters may include network identity, initial roots, object domains, supported cryptographic suites, initial supply, allocation categories, vesting rules, treasury controls, validator or operator bootstrap information, protocol version, data availability assumptions, governance bootstrap rules, and feature activation gates.

The Main Whitepaper section on current contracts versus target architecture is the correct maturity frame. It distinguishes what is described as a target architecture from what exists as implementation. A genesis document should do the same. It should not bury consensus-impacting values in application config or docs frontmatter.

Protocol genesis also needs validation. A builder should expect schema checks, domain checks, supply conservation checks, allocation checks, duplicate-key checks, cryptographic-suite checks, and deterministic root derivation tests. Those tests should live with the protocol implementation and launch artifacts, not inside unrelated presentation config.

Allocation and Economic Constraints

The Tokenomics paper gives the economic context: genesis supply, allocation, vesting, circulation, and phased rollout need explicit handling. A docs site may summarize those concepts, but it should not invent exact launch numbers or treat illustrative values as final policy. A future genesis artifact must bind economic values to evidence, review, and governance acceptance.

Allocation constraints should be machine-checkable. Examples include total supply consistency, category caps, vesting schedules, unlock timing, treasury reservation rules, and restrictions on early transfer. If useful-work rewards or treasury programs exist at launch, genesis should identify which parts are active, which are gated, and which require later governance.

Phased rollout matters because a network can intentionally launch with only a subset of target capabilities. Documentation should say which features are available at genesis, which are testnet-only, which are governance-gated, and which remain research. That language protects builders from assuming every whitepaper concept is live on day one.

Governance Gates

The DAO paper describes what can be specified now, recommended launch order, and future expansion. Governance gates should define who can change which parameters, under what process, with what delay, and with what audit evidence. Examples include activating new proof systems, changing treasury policy, adjusting useful-work evaluation rules, adding bridge adapters, or upgrading protocol serialization.

Governance should not be implemented accidentally through helper configuration or documentation deployment. Changing a local YAML file used for a development flow should not change protocol supply. Changing documentation should not activate a cryptographic suite. A future governance process may publish documentation, but the documentation is the record or explanation, not the authority itself.

Builder Rules

Use these rules when adding configuration or genesis material:

• Name current repo files only for behavior they actually control.
• Keep protocol genesis values in a future protocol-owned artifact, not in helper YAML or unrelated docs metadata.
• Mark illustrative launch parameters as illustrative until accepted by the protocol governance process.
• Keep allocation math reproducible and testable.
• Treat governance gates as authority boundaries, not convenience config sections.
• Include migration paths for parameters that may change after launch.
• Keep user-facing docs synchronized with implementation evidence, not ahead of it.

Schema and Review Expectations

Repo-local configuration should stay human-readable and easy to review, but it still needs structure. Loader code should define allowed inputs clearly, operator-facing CLIs should keep config expectations explicit, and feature flags should remain honest about risk. If a value starts affecting protocol launch claims, it belongs in a different authority surface.

Future genesis configuration should have a schema, deterministic parsing, and tests. Review should verify unknown fields, duplicate keys, unsupported versions, invalid allocations, impossible vesting schedules, unsupported cryptographic suites, and inconsistent governance gates. It should also verify that the canonical genesis artifact can derive the expected starting root or state commitment. Those tests cannot be substituted with a docs build.

Documentation Anti-Drift

Docs should avoid phrases such as “configured in this repo” when the value is a future network parameter. Use “documented in the corpus,” “target genesis parameter,” or “not currently fixed by the live z00z repo.” If a future protocol config file is added, update the docs to point to that file directly. Until then, loader code and CLI contracts mean runtime configuration behavior, not launched network genesis.

This anti-drift rule also applies to examples. A tutorial may show how to edit a theme, but that does not teach protocol governance. A tutorial may show how to enable Mermaid rendering, but that does not activate DA support. Keep examples inside the authority of the files they actually touch.

Launch Readiness Signals

A future launch-readiness checklist should not be inferred from helper config alone. It should require protocol genesis schema validation, allocation review, cryptographic-suite review, operator bootstrap review, governance approval, security testing, recovery planning, and public communication review. Website readiness can be one item on that checklist because users need accurate docs, but it is not a substitute for network launch evidence.

If launch parameters are still unsettled, docs should say so directly. A placeholder value is safer when labeled as a placeholder than when hidden in a table that looks final. Builders can work with honest uncertainty; they cannot reliably work with accidental finality. That rule applies to every launch-facing table.

Read Next

• API Reference for current workspace surfaces and future protocol API layers.
• Verification And Tests for what local cargo gates and the shared broad verify sweep prove and do not prove.
• Runtime Services for service boundaries around protocol launch.

Evidence and Further Reading

• crates/z00z_utils/src/config/env.rs, yaml.rs, and layered.rs define the current live configuration loading and precedence rules referenced here.
• github.com/z00z-labs/z00z, README.md, and crates/z00z_rollup_node/Cargo.toml define the current workspace and operator config-entry surfaces referenced here.
• Main Whitepaper section 12 for current versus target architecture framing.
• Tokenomics and Incentives sections 4 and 10 for genesis allocation and phased rollout concepts.
• DAO section 11 for governance launch order and future expansion framing.