Aggregator

Aggregator

Aggregators do the network's model building: staked validators who combine the auditor-approved local models into the new global model at the end of each Global Iteration. Where Auditors decide what goes in, aggregators produce what comes out.

Like auditors, they are validators with skin in the game: DIN tokens staked in DinValidatorStake, slashable for missing assigned work or submitting results that diverge from their peers.

Becoming an aggregator

dincli aggregator dintoken buy <amount_eth>     # exchange ETH for DIN
dincli aggregator dintoken stake <amount>       # stake (approval + stake in one command)
dincli aggregator register <model_id>           # register for the current GI (window must be open)

Staking is once (topped up as needed, minimum 10 DIN per stake call, 7-day unbonding on exit); registration is per model, per Global Iteration, while the aggregator registration window is open.

The job: two-tier aggregation

Once evaluation closes, the approved local models are aggregated hierarchically:

• Tier 1 (T1) — approved models are split into sub-batches, each assigned to a small group of aggregators (3 per batch). Each aggregator independently combines their batch's models (running the model owner's aggregation function in a sandboxed Worker Node) and submits the resulting CID.
• Tier 2 (T2) — a single final batch: assigned aggregators combine the finalized T1 outputs into the new global model, which seeds the next GI.

dincli aggregator show-t1-batches <model_id> --detailed     # see your T1 assignment
dincli aggregator aggregate-t1 <model_id> --submit          # aggregate & record on-chain
dincli aggregator show-t2-batches <model_id> --detailed     # if assigned to the final tier
dincli aggregator aggregate-t2 <model_id> --submit

Honesty is enforced by redundancy. Every aggregator in a batch performs the same deterministic computation, and the batch's final CID is decided by majority vote: identical inputs must yield identical outputs, so an identical CID. An aggregator who computes correctly is automatically in the majority; one who deviates — lazily, faultily, or maliciously — produces a lone CID that loses the vote and marks them for slashing.

What gets an aggregator slashed

At GI end, the model owner triggers slashing against aggregators who:

• failed to participate — registered but did not submit for an assigned T1/T2 batch, or
• submitted a minority result — their CID disagreed with the batch majority.

Slashing is executed by the model's DINTaskCoordinator against the aggregator's stake, including stake in the unbonding queue.

Further reading

• Aggregator command reference
• Task Contracts — batch formation, CID voting, and finalization on-chain
• Platform Contracts — staking, unbonding, and slashing mechanics
• Auditor — the validator role upstream, deciding which models reach aggregation