Aggregators

Aggregators prepare work for publication; they do not become settlement authorities. They can collect candidate work items, normalize envelopes, order batches, attach publication metadata, and hand artifacts to data availability or validation stages. They are not wallet custodians, exchanges, or useful-work reward judges.

The role is easy to overstate because aggregation sits near the moment private wallet output becomes public evidence. A user may see “sent to aggregator” and assume the protocol accepted the action. That is wrong. Aggregation can improve liveness and batching discipline, but settlement truth still belongs to the checkpoint-facing protocol boundary described in the Main Whitepaper.

Aggregator Role Flow

The aggregator is in the left half of the flow. It prepares and publishes work. It does not own the right side of the flow.

Intake Discipline

An aggregator should accept only well-shaped inputs. Intake checks can include payload size, supported version, object domain, declared network, expected encoding, authentication or rate policy, replay-sensitive fields, and whether the request is compatible with the aggregator’s role. Intake should reject obvious junk before it becomes a batch.

Those checks are not full validation. A package can be well-formed but still fail replay, proof, state, or policy checks later. Aggregator docs should use “admitted for publication” or “accepted for batching” instead of “valid” when deeper validation has not occurred.

Batch Discipline

Batching is useful when it is deterministic and explainable. The Main Whitepaper’s publication vocabulary separates work items, ordered batches, publication requests, published batches, publication records, and soft confirmation. Aggregator implementations should preserve those distinctions. A batch should have a clear input set, ordering rule, timestamp or epoch context where relevant, publication target, and failure behavior.

If two aggregators produce different candidate batches, the network should be able to explain why. Hidden local ordering rules, arbitrary manual edits, or service-specific priority queues can become fairness and replay risks. If priority rules exist, they should be part of policy and evidence, not an operator secret.

Useful-Work Boundary

The Proof-of-Useful-Work papers add work packages, proofs, evidence, fact consensus, value consensus, reward authorization, challenges, and appeals. Aggregators may carry useful-work packages or batch useful-work evidence, but that does not make them reward authorities. A useful-work evaluator may assess evidence; a treasury or protocol process may authorize rewards. Aggregation should not collapse those steps.

For documentation, the safe wording is: aggregators can help move useful-work evidence into the publication pipeline. They do not decide whether the work was valuable enough for reward unless a separate, implemented protocol role grants that authority and tests prove it.

Key-Control And Custody Boundary

Under the documented target role, aggregators should not take custody of user assets or rights. A user may submit a package, but the aggregator should not learn wallet-local secrets or gain spend authority. If an aggregator requires plaintext private context to operate, the design has likely crossed a boundary that should be rejected or escalated.

Legal architecture matters here. This technical design informs but does not by itself decide custody or service classification. Operator docs should avoid language that makes aggregators sound like custodians, exchanges, brokers, or final arbiters. They are infrastructure actors. If a future deployment adds an operator business model, legal and compliance documentation must describe that model explicitly instead of letting technical docs imply it.

Failure and Challenge Boundaries

Aggregator failures should be visible. Failure classes include malformed input, unsupported version, rate limit, duplicate request, DA publication failure, batch construction error, stale epoch, privacy redaction failure, and conflict candidate. Some failures are user-correctable. Some indicate operator health. Some should become watcher alerts.

Challenge paths should not be hidden. If an aggregator publishes conflicting work or withholds data, watchers and validators need evidence. Linked liability concepts such as fraud proof extraction, lock registries, bonds, quarantine, and appeal paths belong downstream of aggregation but should influence how aggregation records evidence.

Operator Signals

Safe aggregator metrics include queue length, batch age, rejection class, publication latency, DA success rate, and version distribution. Risky metrics include wallet identifiers, user-specific timing, private policy descriptions, raw support evidence, or route intent. The Privacy Threat Model’s service and telemetry guidance should apply before any dashboard is exposed.

Current Repository Boundary

The core repository implements an aggregator crate and an executable aggregator-mode rollup-node path. crates/z00z_runtime/aggregators/ exposes ingress, ordering, publication, recovery, routing, consensus, and structured evidence contracts. Its test suite covers publication binding, planner authority, routing, recovery, quorum evidence, transport faults, and related guardrails. crates/z00z_rollup_node/src/main.rs exposes the current live CLI scope as aggregator mode.

The remaining material is a mix of current crate-level behavior and production-readiness requirements. Commands and service promises must stay within the executable CLI and tested configuration surface.

Aggregator Evidence Checklist

An aggregator should record enough evidence for later stages to verify its work without trusting its private database. Useful records include intake time, input artifact reference, schema version, network domain, rejection class, batch identifier, ordering rule, publication target, DA reference, and retry history. The record should avoid wallet-local meaning and should keep user identifiers out unless the user has explicitly disclosed them for a bounded purpose.

The checklist should be deterministic. If an aggregator says a package was rejected, another component should know whether the rejection was malformed input, unsupported version, wrong domain, duplicate submission, privacy policy failure, or downstream outage. If an aggregator says a batch was published, the record should point to the DA or publication evidence that validators and watchers can later inspect.

Anti-Overclaim Language

Aggregator pages should prefer narrow verbs. Use admit, queue, batch, publish, retry, reject, and quarantine. Avoid settle, own, custody, approve reward, or finalize unless a separate protocol source grants that authority. This vocabulary matters because operator role pages are often copied into SDK docs, support docs, and public status text.

If an aggregator implementation later includes stronger powers, those powers should be documented as explicit exceptions with tests and legal review. They should not emerge accidentally from broad public wording.

Privacy Review

Aggregation can create metadata concentration. Even if payloads are private, batch timing, retry behavior, source IPs, route metadata, or service accounts can reveal patterns. Aggregator deployments should minimize logs, aggregate metrics, and avoid exposing user-specific timing in public dashboards. Watchers and status pages should receive redacted evidence, not raw intake streams.

Implementation Readiness

An aggregator implementation is ready for operator docs only after it has fixtures for intake, batching, publication, DA handoff, duplicate handling, reject classes, retry behavior, and privacy redaction. Tests should prove that accepted-for-batch does not become accepted-for-settlement. They should also prove that a malformed package, a missing DA adapter, and a downstream validation reject produce different evidence.

Configuration should name the aggregator’s limits. Does it accept useful-work packages? Does it batch only one object class? Does it support OnionNet ingress? Does it keep queue history? Does it expose public metrics? Each answer changes the privacy and authority review. Without those answers, public docs should remain architecture-level.

Support Boundary

Support teams may receive aggregator receipts during user questions. Those receipts should be explained as publication evidence, not proof of ownership or settlement. If support needs more, it should request scoped evidence from the wallet or protocol artifact path, not raw aggregator logs.

Release Gate

Aggregator docs should become production-operational only after the implementation proves queue behavior, batch determinism, publication receipts, DA handoff, redaction, and reject classes. Until then, examples should remain conceptual. A command that appears beyond the tested CLI surface would teach operators to trust a deployment contract the repo has not proved.

When a deployment surface is still missing, the better tutorial is an artifact walkthrough: show what evidence the crate produces, which source paper defines the role, and which production test or runbook remains required.

an aggregator receipt is not a wallet balance, custody record, reward approval, or settlement certificate. It is one piece of publication evidence inside a longer pipeline.

Read Next

• Publication Pipeline for where aggregation fits in the actor order.
• Validators for replay and verdict boundaries.
• Node Operations for operator health and incident loops.

Evidence and Further Reading

• Current implementation evidence: z00z-labs/z00z, crates/z00z_runtime/aggregators/, and crates/z00z_rollup_node/src/main.rs.
• Main Whitepaper sections 4 and 8 for rollup architecture, work items, batches, publication records, and soft confirmation.
• Proof-of-Useful-Work sections 4-6 for useful-work architecture, actors, work packages, proofs, and evidence.
• Legal Architecture section 11 for service and operator boundary language.