Few questions related to GI2 aggregator #307

Activity

1. abrahamnash

   assigned

   umermjd11

   ,

   robertocarlous

   ,

   Santiagocetran

   and

   Abidoyesimze

   on Oct 30, 2026
2. robertocarlous commented on Oct 31, 2026

   

   robertocarlous

   on Oct 31, 2026

   Last edited by robertocarlous

   Collaborator

   More actions

   @abrahamnash @Swiftevo

   Thanks for these, going through them one by one.

   ---

   When does the GI 2 Aggregator registration period close? / How long are the usual T1 and T2 aggregation windows? / Is each T1 batch still expected to contain three models and be assigned to three Aggregators?

   These are set by the model owner when they call the open/close registration commands and configure batch parameters — there is no protocol-level hardcoded window. The DIN-Representative or model owner for GI 2 would need to confirm the schedule. We don't have that information here.

   ---

   Are Aggregators rewarded? If so, when and how?

   The contract has reward settlement: DINTaskAuditor.settleRewards runs at endGI and records each participant's share, and claimReward(gi) lets validators pull their reward per GI afterward. The reward pool is funded from model-owner fees routed through DinFeeRouter.

   However, dincli currently has no aggregator claim-reward (or equivalent) command — the contract function exists but is not exposed in the CLI. The same gap applies to dincli auditor. Reward claiming is not yet possible through dincli.

   ---

   What are the actual consequences if an assigned Aggregator fails to complete work on time?

   Slashing under S1/S2: slashPartial on DinValidatorStake, applied by the model owner via dincli model-owner ... slash. S5 recidivism escalation applies if the same validator misses repeatedly within the window.

   ---

   Which branch/version should participants use for the current public DevNet?

   The official release is v0.2.0 (the latest wheel). However, the Tier2Batch NameError reported below is confirmed on that release — see next item. Participants who hit GI > 1 will need the develop branch until a patched release is cut.

   ---

   The Tier2Batch NameError — confirmed and fixed on develop?

   Confirmed. In v0.2.0, dincli/cli/client.py builds a Tier2Batch(...) object at line 46 when current_GI > 1, but Tier2Batch is never imported in that file — it would raise NameError: name 'Tier2Batch' is not defined before training begins.

   This is fixed on the develop branch: the code was rewritten to read the CID directly from the contract return value without constructing a Tier2Batch object. A new release would need to be cut from develop to ship this fix.

   ---

   Does the updated version include the T1/T2 aggregation fixes (T2 batch-ID, local-path handling)?

   Yes — those fixes landed in PR No. 214 (fix/auditor-commit-retry-and-t2-batch-id) and are on develop.

   ---

   Gaps that need implementation

   Two things are not yet in dincli at all:

   1. dincli aggregator unstake / dincli aggregator withdraw — DinValidatorStake has unstake(amount) and withdraw() with a 7-day unbonding period (configurable by the DIN-Representative), but neither is exposed as a CLI command. Validators currently have no way to exit their stake through dincli.

   2. dincli aggregator claim-reward (and dincli auditor claim-reward) — DINTaskAuditor.claimReward(gi) exists in the contract but is not wired up in the CLI.

   If it would be useful we can open issues for both and put up PRs. Let us know if you'd like us to go ahead.
3. umeradl commented on Nov 2, 2026

   

   umeradl

   on Nov 2, 2026

   Member

   More actions

   Thanks for the questions, and for staking early. First, an important update: we're retiring DevNet 1.0 and moving all our work to the DevNet 2.0 release. The Model 0 task contracts deployed on DevNet 1.0 can't slash a misbehaving aggregator or auditor: slashAggregators reverts because of a minStake mismatch, and slashAuditors is only a stub. endGI depends on the aggregator slashing step, so one missed or divergent aggregator submission can leave a GI stuck with no way to end it. This can't be fixed without redeploying, as we noted here. So GI 2 on the current deployment won't continue. The answers below describe DevNet 2.0 unless noted otherwise.

   1. When does the GI 2 Aggregator registration period close?

   GI 2 on DevNet 1.0 won't move past this stage, so there's no need to wait for registration to close. You also don't need to do anything else on that deployment. DevNet 2.0 will be a fresh deployment with new contracts. We'll announce the timing on GitHub and in our Telegram and Signal groups.

   In general, registration has no fixed on-chain deadline. The model owner closes it manually, so the timing is announced per model rather than set by a timer.

   2. After registration, how long are the usual T1 and T2 aggregation windows?

   There's no fixed length. The contracts have no timer on these windows, so the model owner opens and closes each one manually.

   DevNet 2.0 uses commit-then-reveal for both tiers, so each tier has two stages:

   1. Commit: the model owner runs startT1Aggregation, and assigned aggregators commit a hash of their result.
   2. Reveal: the model owner runs startT1AggregationReveal, and aggregators reveal the CID behind that commit. The model owner then finalizes the tier.

   T2 follows the same pattern, using the T2 versions of those functions. You need to do both stages: if you commit but never reveal, your submission isn't counted.

   Once a batch is finalized, a dispute window opens. Its default is 1 day, and that value is a placeholder that can be changed. It isn't a limit on how long aggregation takes.

   Because the windows are set per model and there's no fixed duration for now, watch the GI state rather than a clock.

   3. Are Aggregators rewarded? If so, when and how are rewards distributed or claimed?

   Yes. In DevNet 2.0, each GI has a reward pool in DIN, and aggregators share a set portion of it. The default is 15%, though we expect the default split to change before launch, and final values aren't confirmed yet.

   How your share is calculated: you get one unit of weight for each finalized T1 or T2 batch you submitted to. Assigned aggregators who don't submit get nothing for that batch (this fix is tracked here). Your share of the aggregator pool is your weight divided by the total weight of all aggregators in that GI. Each aggregator gets at most one batch per GI, so everyone who submits to a finalized batch earns the same share, whichever tier they're in.

   When: rewards are settled when the model owner ends the GI, after the slashing step.

   How: rewards aren't sent automatically, so you claim them yourself in two steps on the DINTaskAuditor contract:

   1. claimReward(gi) adds your share for that GI to your claimable balance.
   2. claimRewards() transfers your full claimable balance to your wallet.

   Slashing is separate from rewards: if you're slashed, that comes out of your stake.

   4. What are the actual consequences if an assigned Aggregator fails to complete the work on time?

   "On time" means revealing your submission before the model owner finalizes that tier. Committing without revealing counts the same as not submitting.

   In DevNet 2.0, a missed submission has these consequences:

   • Partial slash: you lose 30% of the minimum stake. With the current default minimum of 10 DIN, that's 3 DIN.
   • No reward: you earn nothing for that batch.
   • Repeat misses: a third partial slash within 5 GIs on the same model, or a sixth across all models within 7 days, becomes a slash of the full minimum stake plus a 7-day jail.

   Submitting a result that doesn't match the batch's consensus is treated more seriously: you lose the full minimum stake in one slash.

   Slashing happens once per GI, after aggregation and auditing finish, in a step run by the model owner.

   A batch needs at least 2 of its 3 aggregators to reveal before it can finalize. If it doesn't reach that, the GI currently has no way to recover, which is a known gap tracked in issue 222.

   All of these values are current defaults and may change before DevNet 2.0 launches.

   5. For the current public DevNet, should participants use the main branch, the official wheel, or the develop branch?

   As DevNet 1.0 is being retired, there's no need to install or update anything for it right now.

   • main and the dincli 0.2.0 wheel: these are the DevNet 1.0 code, so they aren't what you'll use for DevNet 2.0.
   • develop: this holds the DevNet 2.0 code, which is still changing and isn't deployed yet. Use it if you want to read the code, run it locally or contribute, but don't treat it as a public network client yet.

   For DevNet 2.0, we'll say which dincli version to install when we announce the launch on GitHub and in our Telegram and Signal groups.

   6. For GI 2, is each T1 batch still expected to contain three models and be assigned to three Aggregators?

   Yes, in DevNet 2.0 the batch rules stay the same, and they're fixed in the contract:

   • Aggregators: each T1 batch gets exactly 3. The T2 batch also gets 3, and there's one T2 batch per GI.
   • Models: each T1 batch gets 3 models. The last batch can have 2 if only 2 models are left.
   • Assignment: aggregators and models are shuffled using a seed that's locked after evaluation closes, and each aggregator gets at most one batch per GI.

   The number of T1 batches depends on how many models are approved and how many aggregators register. For example, 9 approved models need 3 T1 batches (9 aggregators) plus 3 more for T2, so 12 in total. If only 1 model is left after the others are batched, or there aren't enough aggregators to cover every model, the leftover models aren't assigned to a batch for that GI.

   7. How can an Aggregator unstake their DIN tokens, and is there an unbonding or waiting period?

   Your 10 DIN on DevNet 1.0: you can withdraw it yourself at any time, and there's no waiting period. dincli has no unstake command, so call the staking contract directly, for example with Foundry's cast:

   cast send 0x5088D7a568E79c6bec0795258591f2435649139a \
     "unstake(uint256)" 10000000000000000000 \
     --rpc-url <your Optimism Sepolia RPC> --account <your wallet>

   The DIN returns to your wallet straight away. DIN and stakes from DevNet 1.0 won't carry over to DevNet 2.0.

   On DevNet 2.0, unstaking has two steps and a waiting period:

   1. unstake(amount) moves your stake into a pending withdrawal and starts the unbonding period, which is 7 days by default.
   2. Once that period ends, claimUnstaked() transfers the DIN to your wallet.

   You can only have one pending withdrawal at a time, and your pending amount can still be slashed during the 7 days. Blacklisted validators can't unstake.

   The 7-day default may change before launch.

   8. Will an updated version of dincli be released before GI 2 enters the client training stage (LMSstarted)? Has the Tier2Batch issue been confirmed and fixed in the officially supported version?

   You read the code correctly, and thanks for catching it. In dincli 0.2.0, client train-lms uses Tier2Batch without defining or importing it, so it raises a NameError once the GI is above 1.

   We won't be releasing a fix for 0.2.0. DevNet 1.0 is being retired, so GI 2 won't reach LMSstarted there and no update is needed. The bug doesn't exist on develop, where train-lms reads the T2 batch directly from the contract, so it won't carry into DevNet 2.0.

   9. Does the updated version also include the latest fixes for T1/T2 aggregation, including the T2 batch-ID and local-path handling fixes currently present on the develop branch?

   Those fixes are on develop, which is the DevNet 2.0 code, and they won't be backported to 0.2.0. The dincli version we announce for DevNet 2.0 will be built from develop, so it'll include them, along with the newer commit-then-reveal aggregation commands.

   That's a lot to take in, so thanks for your patience, and for testing this closely. We'll post DevNet 2.0 news on GitHub and in our Telegram and Signal groups.

   👍React with 👍1Reacted by Shift
4. Swiftevo commented on Nov 2, 2026

   

   Swiftevo

   on Nov 2, 2026

   Author

   More actions

   Thanks a lot for the details update here. I will keep contact with @abrahamnash for DevNet 2.0 news

   👍React with 👍1Reacted by Dr. Abraham Nash
5. Swiftevo

   closed this as completedon Nov 2, 2026