A Z00Z rollup node is a target protocol component, not a feature shipped by the current website repository. This distinction is the first implementation rule. The docs repo can describe the responsibilities, vocabulary, diagrams, and verification expectations. It cannot honestly claim to run a node, produce settlement roots, publish data availability batches, or enforce protocol state.
The current local anchors are the documentation pipeline, whitepaper corpus, configuration files, and repository verification commands. Future node code should use those docs as source-linked guidance, not as evidence that the node exists. Where this page says “node,” read it as the intended protocol role defined by the whitepaper corpus unless a future implementation adds concrete runtime modules and tests.
Responsibility Boundary
The Main Whitepaper describes rollup architecture around publication intake, ordered batches, data availability, validation, checkpoint artifacts, and separation between aggregation, validation, watching, and service operation. A rollup node should coordinate these responsibilities without turning itself into a universal trust oracle. It can assemble local evidence, validate packages, produce candidate roots, and publish artifacts, but final authority depends on the protocol’s accepted root and checkpoint rules.
The node should be treated as a pipeline with explicit stages:
- Intake accepts candidate packages and rejects malformed input early.
- Ordering turns accepted work into deterministic batches.
- Data availability publishes or references the data needed for independent verification.
- Validation checks object semantics, proof material, replay protection, and conflict rules.
- Root production derives the state commitment for accepted transitions.
- Checkpoint coordination links the batch, root, and publication evidence.
- Monitoring exposes health without leaking private wallet context.
- Failure handling identifies retry, quarantine, rejection, or escalation paths.
If those stages collapse into one opaque service, builders lose the ability to debug, audit, and test the system. A node implementation should make every stage observable enough for operators and verifiers while still respecting privacy boundaries.
Intake and Batch Formation
Publication intake starts with envelopes, not trust. A submitted package should declare enough information for validation: object type, network or domain, version, references to prior state, proof or witness references, and replay protection material. Intake can check size, shape, encoding, supported version, and authentication policy, but deeper validity belongs to validation.
Batch formation must be deterministic. Two honest nodes with the same input set and ordering rules should be able to derive the same batch, or at least explain why their candidate batches differ. Determinism matters for checkpoint reproducibility, data availability verification, and conflict detection. A builder should avoid hidden local ordering inputs such as wall-clock arrival time unless the protocol explicitly commits to them and handles disagreement.
The Main Whitepaper’s publication vocabulary includes WorkItem,
OrderedBatch, PublicationRequest, PublishedBatch, PublicationRecord, and
SoftConfirmation. These names should not be used as generic UI labels. They
describe protocol pipeline roles. A SoftConfirmation is not final settlement;
it is an intermediate signal that must be bounded by its source and maturity.
Data Availability
Data availability is the promise that verifiers can obtain enough data to check the batch and root. A node that publishes a root without making the relevant batch data available creates an unverifiable claim. Future implementations should record the data availability adapter, publication record, content hash or commitment, retrieval expectations, and failure behavior.
The website repository does not ship a DA adapter. If a docs page or tutorial mentions Celestia, local files, object storage, or any other DA layer, it must state whether that is conceptual, simulated, or implemented. The whitepaper mentions target adapter boundaries; this repository currently proves only docs content and local site verification.
DA failure should be a first-class node state. If data cannot be retrieved, the node should not pretend the batch is independently verifiable. Operators need status signals, watchers need evidence, and users need maturity language that distinguishes “submitted,” “published,” “available,” “checkpointed,” and “settled.”
Validation and Root Production
Validation ties the node back to protocol semantics. It should check canonical object types, path and root relationships, proof formats, nullifier scope, replay protection, conflict detection, and maturity gates. A package can pass transport checks and still fail validation. A node should keep those failure classes distinct so clients and operators know whether to fix a request, investigate a dispute, or wait for external data.
Root production should be reproducible from accepted transitions and previous accepted state. It should not depend on a private service database, an RPC server’s memory, or a UI-specific index. If a future node maintains local indexes for speed, those indexes must be derived from canonical data rather than becoming a competing source of truth.
The Cross-Chain Integration paper reinforces this point for cross-chain rights and lockers. External systems add lifecycle states, trust assumptions, and failure modes. A rollup node should record which external evidence it relied on and which parts remain outside local authority. A bridge or locker signal is not automatically equivalent to a settled Z00Z state transition.
Checkpoint Coordination
Checkpoint coordination binds batch data, state roots, validation results, and publication evidence into an artifact that watchers and verifiers can reason about. The node should identify checkpoint inputs, output artifacts, signatures or attestations where applicable, and links to DA records. It should also record maturity: candidate, soft-confirmed, challenged, finalized, or rejected.
The Proof-of-Useful-Work paper is relevant because useful work introduces additional evidence classes. A useful-work evaluator may produce proof and quality evidence, but a reward or settlement outcome still needs protocol acceptance. A rollup node should not silently merge evaluator decisions, treasury policy, and settlement authority into one endpoint.
Monitoring and Failure Modes
Monitoring should answer operational questions without becoming a privacy leak. Useful signals include queue length, batch age, DA publication state, validation failure class, checkpoint maturity, and node health. Sensitive signals include wallet identifiers, user behavior timing, private policy text, recovery events, and full request bodies. Node telemetry needs a redaction policy before it is safe to expose.
Failure handling should distinguish malformed input, unsupported version, unauthorized caller, DA outage, validation rejection, replay attempt, conflict, checkpoint challenge, and internal fault. Each class needs a deterministic operator path. Some failures are caller repair. Some are protocol rejection. Some are service outages. Some require quarantine or dispute handling.
Operator Interfaces
A future node operator interface should be narrow. It can expose queue health, batch progress, DA status, validation failure counts, checkpoint maturity, resource usage, and upgrade readiness. It should not expose private wallet payloads, receiver material, unredacted support evidence, or user-specific timing data. Administrative commands should be separated from read-only status, and both should be authenticated according to the deployment threat model.
Operator controls should also avoid hidden consensus behavior. Restarting a service, retrying publication, pruning a local cache, or changing log levels should not change canonical state. If an operator action can change which batch is proposed, which DA adapter is used, or which protocol version is accepted, that action needs policy, audit, and governance treatment rather than a casual dashboard button.
Documentation Maturity Check
Any rollup-node tutorial should state whether the reader is running current
website code, a simulator, or future node code. If the command does not exist
in package.json or scripts, do not present it as runnable. If a diagram shows
DA publication or checkpointing, label it as target architecture until source
modules and tests exist. This keeps builder expectations aligned with the
repository instead of with an aspirational architecture slide.
Read Next
- Storage And HJMT for root and proof semantics.
- Runtime Services for non-authoritative service responsibilities around a node.
- Verification And Tests for how future node tests differ from website verification.
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 4 and 8 for rollup architecture, publication artifacts, data availability, and soft confirmation.
- Cross-Chain Integration Whitepaper section 7 for cross-chain lifecycle and trust-boundary concerns.
- Proof-of-Useful-Work Whitepaper section 4 for useful-work system architecture and layer separation.
package.jsonandscripts/verify.shfor the current repository’s actual verification commands.src/lib/content/docs.tsfor the current docs loader, which is not a rollup node implementation.