task_100926_13 — P3 Slashing Depth, Aggregator Dispute & Reward/Tokenomics Economics (Robbert)

[umermjd11]

cc @robertocarlous
Assigned. Full spec: Developer/tasks/task_100926_13.md

The task file has the full specification — exact file/line references, per-item background, and the deliverables checklist. This post is just the summary, assignment notice, and the open questions that need an answer before (or while) you build. This one has more open design questions than usual — read the "Blockers" section below before starting §2 in particular.

Summary

Sibling to task_100926_12.md, from the same 2026-09-10 audit of ten open P3 issues (#36-43, #75, #78) — full audit is in both task files. This task is the half that still needs a slashing-economics judgment call or a simulation-first sequencing, not just wiring:

• P3 slashing: conditions taxonomy, penalty tiers, slashed-stake destination, dispute resolution (P3-4.1/4.2/4.3) #38 (remainder): partial-slash tiers for S1/S2 (flat minStake() → a DAO-settable fraction), S5 recidivism counter, S6 registration-without-capacity counter, and the S4 aggregator-recomputation dispute mechanism folded in from P3 auditing: auditor evaluation mechanism — commit-then-reveal, encrypted test data, deviation accountability #40 (closed 2026-09-10 — its one leftover scope line now lives here).
• P3 rewards: per-GI reward engine and pull-payment claim flow for clients, auditors, aggregators #41: the reward-split-percentage simulation (60/20/15/5 defaults were never validated against the P3-5.2 income-stability model this issue's own scope calls for).
• P3 tokenomics: token utility, emission schedule, supply policy, treasury (P3-5.1/5.2) #42: the emission contract — MECHANISM_DESIGN §9 records geometric decay per epoch as a resolved design decision, but no corresponding contract exists on develop at all. Sequenced after P3 rewards: per-GI reward engine and pull-payment claim flow for clients, auditors, aggregators #41's simulation since the decay schedule should be checked against those numbers, not picked independently.

Blockers / design choices needing an answer

1. S4 aggregator-recomputation dispute, §2 — the real blocker. P3 auditing: auditor evaluation mechanism — commit-then-reveal, encrypted test data, deviation accountability #40's leftover scope line ("T1/T2 outputs verifiable by recomputation, any validator may open an S4 dispute") isn't specified beyond that one sentence anywhere, and aggregation itself is deliberately off-chain — the contract structurally can't just "recompute and check." The task proposes a plausible shape (fresh subgroup reassigned by the existing _assignFreshSubgroup re-runs aggregation off-chain and submits a new CID; match = frivolous dispute, mismatch = upheld) but this needs to be confirmed or refined before any contract code gets written against it. Robbert — don't start this section's implementation until this is confirmed here or on the task file.
2. Partial-slash fraction, §1(a). MECHANISM_DESIGN §9 item 2 has been open since the original P3 push — a 25-50% example is given, not a final number. Your call to propose in the PR description; flag here too if you want a sanity check before committing to one.
3. S5 recidivism counter architecture, §1(b). DinValidatorStake.slash() is the single choke point for every slash call today but doesn't distinguish partial from full severity, and doesn't take a GI number — both of which a "≥r partial slashes within w GIs" counter needs. Needs a signature change or a parallel bookkeeping call; propose the shape.
4. S6 counter, §1(c) — depends on task_100926_12 §1(b). The registration-without-capacity counter is the same shape as task_12's concurrent-registration-cap counter. Check whether task_100926_12 has merged before starting this piece — extend its counter rather than building a second independent one.

Reference material

• Developer/tasks/task_100926_13.md — full spec
• Developer/tasks/task_100926_12.md — sibling task, §1(b)'s registration counter is a dependency for this task's §1(c)
• #38, #41, #42 — tracking issues; #40 (closed 2026-09-10, its remainder folded into P3 slashing: conditions taxonomy, penalty tiers, slashed-stake destination, dispute resolution (P3-4.1/4.2/4.3) #38)
• Developer/design/MECHANISM_DESIGN.md §4 (slashing/disputes), §5 (rewards), §7 (tokenomics)

Post progress updates, questions, and PR links here as the task moves — same convention as prior task-tracking discussions (e.g. #47, #106). If anything in the task spec doesn't feel right, is ambiguous, or needs clarification — comment here and cc @umeradl.

[robertocarlous]

Hi @umermjd11 for the issues #38

For the S4 aggregation recomputation dispute, the proposed mechanism is: when a dispute is opened against a T1/T2 batch, _assignFreshSubgroup reassigns a fresh validator subgroup who re-runs the aggregation off-chain and submits a new CID on-chain. If the new CID matches the disputed one → frivolous dispute, challenger forfeits bond. If it doesn't match → dispute upheld, original aggregator slashed. Does this match your intent for 'verifiable by recomputation'? Or do you have a different adjudication model in mind — e.g. the challenger themselves submitting a counter-CID, or a Merkle-proof-based approach

[umermjd11]

Yeah, the fresh-subgroup recomputation approach is right — go ahead with it. Two things to nail down before you build though:

Dispute window + resolution window. Both need to be explicit, bounded parameters, not left implicit:

• Dispute window: how long after a T1/T2 CID is submitted a validator can open an S4 dispute. This needs to close before GI end so we never end up contesting a CID the next GI has already built on. Make it a DAO-settable parameter (same pattern as the other open §9 knobs), defaulted to something inside the current GI's remaining phase length.
• Resolution window: how long the reassigned fresh subgroup gets to recompute and submit a counter-CID, with a defined timeout outcome. Don't default a timeout to "upheld" — that lets the fresh subgroup grief the original aggregator for free by staying silent. Default a timeout to dispute dismissed, and slash the fresh subgroup for liveness failure (consistent with how auditor/aggregator liveness already works), so silence isn't free for either side.

Please add both as named parameters in the S4 spec rather than leaving them to fall out of whatever the contract happens to do.

On the alternative (platform-run special DIN aggregator dispute resolver): I don't want this as the primary mechanism. The reason we recompute via a fresh subgroup instead of just trusting someone's word is that aggregation correctness is exactly the place trustlessness matters most — a platform-run resolver reintroduces the trusted third party we're trying to avoid there, and it cuts against the current stance of keeping platform/governance authority minimal pre-mainnet.

Where it could still earn a place: as a last-resort fallback only if the fresh subgroup itself fails to resolve within the resolution window (no quorum, dispute-on-the-dispute) — bounded and rare, just to guarantee termination, not as the normal path.

[umeradl]

All four deliverables from Developer/tasks/task_100926_13.md are merged into develop, verified against the actual code (not the PR descriptions) and against a clean forge build + green test run at current develop HEAD.

Verification

Deliverable	PR	Merge commit	Deviation/fix commit	Evidence
§1(a) S1/S2 DAO-settable partial-slash fraction	No. 146	fa55764	7204fe0	DINTaskAuditor.s1SlashFractionBps/setS1SlashFractionBps (DINTaskAuditor.sol:160,210), DINTaskCoordinator.s2SlashFractionBps/setS2SlashFractionBps (DINTaskCoordinator.sol:154,1071)
§1(b) S5 recidivism counter + escalation	No. 146	fa55764	7204fe0	DinValidatorStake.s5RecidivismWindow/Threshold/JailDuration, escalation at DinValidatorStake.sol:311-314; namespaced per calling slasher after the fix (cross-model GI ring collision)
§1(c) S6 registration-without-capacity counter	No. 146	fa55764	7204fe0	DinValidatorStake.s6NoParticipationThreshold/Count, escalating slash at DinValidatorStake.sol:333-351
§2 S4 aggregator-recomputation dispute (design confirmed here 2026-09-11, then built)	No. 149	ea1501e	d18f82a	Fresh-subgroup recomputation, DAO-settable disputeWindow/resolutionWindow (not-default-to-upheld timeout), settleRecomputation/_assignFreshSubgroup (DINTaskCoordinator.sol:140,1053,1244,1347)
§3 Reward-split simulation (#41)	No. 147	2199a78	e345ca7	Developer/design/reward-split-simulation.md — confirms 60/20/15/5 across the 10-50 validator / 100-500 client spec range; no RewardSplit change needed
§4 Emission contract (#42)	No. 148	4fd851f	656aafe	foundry/src/DinEmission.sol — geometric decay per epoch, GI-lifecycle-tied, respects mintCap/faucetRetired, DAO-settable decay params; rescoped to mapping(address => EmissionState) per taskAuditor in the fix (was colliding across models)

Each PR needed a follow-up deviation commit — real bugs caught during merge-time verification, not develop-drift:

• No. 146: S1(S2)/S6 double-fire (a single missed vote/submission could be slashed via both slashPartial and recordNoParticipation, exceeding 100% of MIN_STAKE in one event) and a cross-model GI ring underflow in _trimAndRecordPartialSlash (validators active in >1 model pushed non-monotonic GI values into one shared ring). Both pinned as regressions in a new PR146SlashingRegression.t.sol.
• No. 147: two arithmetic errors in the simulation doc (LOW-tier aggregator APY, Case 8's per-participant table) — doc-only, doesn't change the 60/20/15/5 recommendation.
• No. 148: DinEmission's per-GI state was a single global value, so two models' identically-numbered GIs collided — rescoped per-taskAuditor. Also a pyproject.toml duplicate-dependency merge artifact, and dincli's _DEPLOYMENTS_TO_DIN_INFO/din-info gap for the new dinEmission deployment key.
• No. 149: a real conflict with No. 146 in resolveDispute (deferred-bond design vs. already-landed forfeiture path), resolved as a deliberate union confirmed with me before applying; plus the review's requested fix folded directly into the merge commit (settleRecomputation was slashing the entire batch roster instead of only CID-matching submitters); plus a TreasuryForwarding.t.sol break from this PR's own API change (setDisputeParams arity) that git's conflict detection couldn't see since the PR never touched that file.

Current develop HEAD (cdbd79d) re-verified fresh, not just re-citing each PR's own merge-time run:

• forge build (real via_ir=true profile): clean.
• forge test --match-contract "SlashingInvariantsTest|PR146SlashingRegressionTest|DisputeResolutionTest|TreasuryForwardingTest|EmissionTests": 80/80 passed, 0 failed (5 suites).
• Working tree clean throughout (git status --short), no stray edits.

Closing

All nine ## Deliverables checklist items in the task file are satisfied on develop, forge build/forge test are green for every touched suite, and each PR's own review flow (verification → merge-proposal → actual-outcome) is recorded on its respective PR thread. Closing as resolved.