No recovery path when a T1/T2 batch never reaches reveal quorum — GI stuck forever (BL-30)

[Abidoyesimze]

Summary

finalizeT1Aggregation/finalizeT2Aggregation (DINTaskCoordinator.sol) iterate every batch in the GI in a single transaction and revert the entire call if any one batch has too few reveals:

if (winningCID == bytes32(0)) revert TC_NoSubmissions();
if (submissionCount < T1_AGGREGATORS_PER_BATCH / 2 + 1)
    revert TC_InsufficientSubmissions();

(finalizeT1Aggregation L979-980, finalizeT2Aggregation L1127-1128, verified against develop @ 740a613)

There is no per-batch retry, no owner override to skip a stuck batch, and no abort path for the GI as a whole: endGI requires GIstate == AggregatorsSlashed and startGI requires GIended/GenesisModelCreated — both unconditional, no bypass. I checked the full contract for any abort/skip/force/emergency function; none exists.

Reachability

This isn't an edge case — with the demo default of 3 aggregators per T1 batch and majority = 2, any 2 of 3 assigned aggregators simply not revealing (going offline, missing the window, or deliberately withholding — no collusion needed, no cost beyond the existing S1/S2 slash, which doesn't stop the GI) permanently bricks that batch, and therefore the whole GI, forever. DINTaskCoordinator/DINTaskAuditor are not upgradeable, so there is no patch-around once deployed. The model's reward pool and its validators' registration slots (see #223) stay locked with it.

Impact

This gap is already blocking other work, not just a standalone concern: BL-26's residual notes explicitly deferred a contract-side re-anchor cap on the batch-assignment seed "because a capped GI would be stuck forever" with no way to recover.

Suggested approach

Needs a GI-abort design (flagging the decision points, not prescribing an answer):

• Who may trigger it — model owner only? DIN-Representative as an emergency backstop?
• When — only after some minimum time/deadline past the batch's reveal window opening, so an impatient owner can't abort a GI that would've resolved fine?
• Where the reward pool and in-flight slashing state go on abort — forfeited? refunded pro-rata? rolled to the next GI?
• Whether it's a full abort (GIended early) or a narrower "skip this batch, exclude it from T2" path

References

• Developer/BACK_LOG.md BL-30
• PR fix(foundry+dincli): ungrindable batch-assignment seed (issue #156 H-2, Part B) #191 review (BL-26, the deferred re-anchor-cap decision this blocks)
• PR fix(cli): remove broken non-proxy dinrep deploy, fix add-slasher crash; refresh contract docs (#203) #204 review (DINTaskCoordinator.md §10 No. 6)

[umeradl]

Status update: confirmed; blocked on a GI-abort design

Checked against develop @ a1fcce2. The finding holds.

• finalizeT1Aggregation and finalizeT2Aggregation revert the whole call when any one batch has no winning CID or too few reveals (foundry/src/DINTaskCoordinator.sol:979-981, :1127-1129).
• endGI needs AggregatorsSlashed and startGI needs GIended, and nothing can skip a batch or abort the GI.
• With 3 aggregators per T1 batch, 2 non-revealers stop the GI for good. That freezes its reward pool and its validators' registration slots.

Can be done now: no, it needs a design decision first. The open questions are the ones in the issue:

1. Who: the model owner after a deadline, the DIN-Representative as a backstop, or anyone after a long timeout.
2. When: a minimum delay after the reveal window, so an owner can't abort a GI that would have finalised.
3. What happens to the reward pool and pending slashes: refunded, rolled into the next GI, or forfeited.
4. Scope: a full abort (jump to GIended) or a narrower "skip this batch and exclude it from T2".

Timing matters here. DINTaskCoordinator isn't upgradeable, so a GI-abort path only helps models deployed after it lands. That means it should be decided before the DevNet 2.0 deploy. Contract size matters too: the coordinator has a 1,079 B margin. It's also the missing piece behind BL-26's deferred re-anchor cap. This is not in task_061026_22.