Skip to content

Aggregator

Jump to bottom
umermjd11 edited this page Oct 5, 2026 · 4 revisions

Aggregator

🚧 This wiki describes DevNet 2.0, soon to be launched. It follows the contracts and dincli on the develop branch; the currently running DevNet may still use older contracts and commands. Pre-launch discussion: #102.

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

Like auditors, they have skin in the game: DIN tokens staked in DinValidatorStake, which can be slashed if they miss assigned work or submit a result that disagrees with their peers. In return they earn a share of every GI's reward pool.

Becoming an aggregator

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

Staking is done once and topped up as needed. Each stake call is at least 10 DIN, and exiting has a default 7-day unbonding period. Registration is per model, per Global Iteration, and only while the aggregator registration window is open. The same conditions as for auditors apply:

  • you must be an active validator;
  • your stake must meet the model's stake floor;
  • you need room under the concurrent-registration cap;
  • at most 300 aggregators can register per GI.

The job: two-tier aggregation

Once evaluation closes, a future-block seed is locked (anyone can do it: dincli aggregator lock-seed <model_id>). The registered aggregators and approved local models are then shuffled into batches:

  • Tier 1 (T1). Approved models are split into sub-batches of 3 (the last batch may have 2), and each sub-batch is assigned to 3 aggregators. Each aggregator independently combines its batch's models by running the model owner's aggregation function in a sandboxed Worker Node.
  • Tier 2 (T2). A single final batch of the next 3 shuffled aggregators combines the finalized T1 outputs into the new global model, which seeds the next GI.

Every submission is commit-then-reveal:

  • Commit. The aggregator first commits a hash of its result CID, bound to its address, the GI, the tier and the batch.
  • Reveal. After the model owner opens the reveal phase, it reveals the CID, using the same dincli cache it committed from.

No CID is visible while commits are open, so a late aggregator can't copy an earlier one.

dincli aggregator show-t1-batches <model_id> --detailed     # see your T1 assignment
dincli aggregator aggregate-t1 <model_id> --submit          # aggregate and commit
dincli aggregator reveal-t1 <model_id>                      # after the owner opens T1 reveals
dincli aggregator show-t2-batches <model_id> --detailed     # if assigned to the final tier
dincli aggregator aggregate-t2 <model_id> --submit
dincli aggregator reveal-t2 <model_id>

Honesty is enforced by redundancy. Every aggregator in a batch runs the same deterministic computation, so the same inputs give the same output and the same CID. The batch's final CID is the one revealed most often, and at least 2 of the 3 must reveal. An aggregator who computes correctly lands in the majority. One who deviates, whether lazily, faultily or maliciously, produces a lone CID that loses.

Rewards

When the GI ends, 15% of its reward pool is shared among aggregators. Every assigned aggregator of each finalized batch gets one unit. Rewards are pulled on-chain: call claimReward(gi), then claimRewards(), on the model's DINTaskAuditor. dincli doesn't have a claim command yet.

What gets an aggregator slashed

At the end of the GI, the model owner triggers slashing. The model's DINTaskCoordinator slashes aggregators who:

  • missed their submission: they were assigned a T1 or T2 batch but didn't reveal, including committing without ever revealing. This is a partial slash, 30% of the minimum stake by default (S2), and repeat offences escalate under S5 to a full slash plus a jail period.
  • revealed a losing CID: their result disagreed with the batch's winning CID. This is a full minimum-stake slash.

Aggregation disputes (S4). Within a window after a batch is finalized, any active validator can post a 100 DIN bond and dispute the result. The model owner adjudicates, and a confirmed dispute slashes the aggregators who produced the bad result.

Slashes reach stake in the unbonding queue too.

Further reading

Introduction

DIN Components

Network Roles

Clone this wiki locally