Contract size headroom for all contracts (DINTaskCoordinator −9 B over EIP-170 with PR No. 197) + slash reason for committed-but-unrevealed across commit-reveal flows

[umeradl]

Summary

Two follow-ups from the PR No. 197 re-review (verification comment, findings No. 6 and No. 4), each widened from PR No. 197 to every contract it applies to:

• Part A: contract size. Once PR No. 197 is merged, DINTaskCoordinator exceeds EIP-170 and can't be deployed. Nothing in CI or local tooling catches this, and the other large contract (DINTaskAuditor) has only about 2 KB left. We need a size budget with real headroom for all deployable contracts, and a gate that enforces it.
• Part B: slash reason for committed-but-unrevealed. In both commit-reveal flows (auditor scoring and T1/T2 aggregation), a validator who commits but never reveals is slashed as a liveness miss (30%), not as a wrong answer (100% of minStake). This is a mechanism-owner decision, tied to the No. 155 S1/S2 fraction decision and the No. 38 slashing taxonomy.

Part A: EIP-170 headroom for all contracts

Current sizes (runtime, via_ir, solc 0.8.28, optimizer_runs = 200)

Contract	develop @ 4658bf8	Margin	With PR No. 197 (b3ff1b9)	Margin
DINTaskCoordinator	22,689 B	1,887 B	24,585 B	−9 B
DINTaskAuditor	22,567 B	2,009 B	22,567 B	2,009 B
DinValidatorStake / V2	9,881 / 9,919 B	14,695 / 14,657 B	unchanged
DINModelRegistry / V2	6,436 / 6,474 B	18,140 / 18,102 B	unchanged
DinFeeRouter	5,160 B	19,416 B	unchanged
DinToken / V2	4,208 / 4,246 B	20,368 / 20,330 B	unchanged
DinFairLaunchDistributor	3,928 B	20,648 B	unchanged
DinCoordinator / V2	3,697 / 3,736 B	20,879 / 20,840 B	unchanged
DinEmission	3,353 B	21,223 B	unchanged
DinTreasury	1,646 B	22,930 B	unchanged

The two per-model task contracts are the ones at risk. Both are already about 92% of the limit, and every mechanism-design item on the P3 roadmap (No. 38, No. 155, No. 192, No. 193, No. 194) adds code to one or the other. PR No. 191 and PR No. 197 each fitted on their own; merged together, they don't.

Why nothing caught it

• .github/workflows/ci.yml runs plain forge build / forge test with no size check, and Solidity CI is green on PR No. 197's b3ff1b9.
• forge test doesn't enforce the limit: suite results were identical with and without FOUNDRY_DISABLE_CODE_SIZE_LIMIT=true.
• foundry/anvil.sh starts anvil with --code-size-limit 4294967295, so the local devnet deploys an oversized contract without complaint.
• forge build --sizes leaves DINTaskAuditor out of its table entirely (reproduced on both trees above; the figure here comes from out/DINTaskAuditor.sol/DINTaskAuditor.json's deployedBytecode). So simply adding --sizes to CI would leave one of the two at-risk contracts ungated.

It would first surface as a revert when DeployPlatform.s.sol / the task-contract deploy runs against Optimism Sepolia.

Proposal

1. Budget: a minimum runtime margin every deployable foundry/src contract must keep. Proposed: ≥ 1,024 B; to be confirmed. Also check initcode against EIP-3860's 49,152 B, currently far from binding.
2. CI gate: a step after forge build that reads every foundry/out/<src contract> artifact directly (not the --sizes table, because of the omission above), and fails if any runtime size exceeds 24,576 − budget. The log should print the full table so reviewers can see each contract's margin in every PR.
3. Bring DINTaskCoordinator back under budget. The immediate blocker for PR No. 197. Candidates, roughly cheapest first:
   • fold the near-duplicate T1/T2 commit…Aggregation / reveal…Aggregation / start…AggregationReveal bodies (PR No. 197, DINTaskCoordinator.sol L807–1041 at b3ff1b9) into tier-parameterised internal functions, with external signatures unchanged;
   • the same for the other T1/T2 pairs (finalize…, the slashAggregators T1/T2 branches);
   • collapse per-tier custom errors into tier-agnostic ones where the tier is already implied by the call;
   • move large pure/view logic (shuffles, batch construction) into an external library;
   • as a last resort, lower optimizer_runs for this contract only (via a compilation restriction), trading gas for size.
4. Give DINTaskAuditor the same review before the next feature lands on it. It has the same shape of per-phase duplication.
5. Remove or document the --code-size-limit override in anvil.sh, so local deploys fail the way a real chain would. At minimum, add a comment saying why it's there.

Acceptance

• CI fails when any foundry/src contract's runtime size is over 24,576 − budget B, and it covers DINTaskAuditor.
• DINTaskCoordinator (with PR No. 197) and DINTaskAuditor both meet the budget.
• The chosen budget is recorded in Developer/CONTRIBUTING.md (or the Foundry README).

Part B: committed-but-unrevealed slash reason (all commit-reveal flows)

Current behaviour

Flow	Commit-but-no-reveal is treated as	Slash	Revealed-but-wrong is treated as	Slash
Auditor scoring (DINTaskAuditor, PR No. 63)	AUD_NO_VOTE (S1 liveness)	s1SlashFractionBps (default 3000 = 30% of minStake)	AUD_SCORE_DEVIATION (S3)	full minStake
T1/T2 aggregation (DINTaskCoordinator, PR No. 197)	AGG_T1_NO_SUBMISSION / AGG_T2_NO_SUBMISSION (S2 liveness)	s2SlashFractionBps (default 3000 = 30%)	AGG_T1_BAD_CONSENSUS / AGG_T2_BAD_CONSENSUS	full minStake

In both flows, "committed and then withheld the reveal" can't be told apart from "never showed up".

The problem

Reveals land one at a time within the reveal window. A validator who has committed can watch peers' reveals, see that their own answer will end up in the minority, and choose not to reveal. They then pay the 30% liveness slash instead of the full-minStake slash for a wrong answer. Before commit-reveal, a wrong submission was irrevocable. So commit-reveal closes the copy-the-leader attack (No. 156 M-1) but opens a 70% discount on being wrong. The same holds on the auditor side, where S3 deviation is currently disabled by default (s3SlashingEnabled = false) but is intended to be turned on.

Options (mechanism-owner call)

• Distinct reason codes (AGG_T*_NO_REVEAL, AUD_NO_REVEAL) with their own fraction, set between the liveness fraction and full minStake, or equal to the wrong-answer slash.
• Treat committed-but-unrevealed as the wrong-answer case (full minStake). Simplest, but harsh on honest aggregators who miss the window through a genuine outage or a client-side bug (compare the retry/salt-overwrite bug, finding No. 1 on PR No. 197).
• Keep as-is and document it as an accepted trust assumption, calibrated through the No. 155 S1/S2 fraction decision.

Whichever is chosen, it should be applied uniformly to both flows, and to any future commit-reveal flow (e.g. No. 178's multi-party commit-reveal seed, if adopted).

Related

No. 155 (S1/S2 fractions), No. 38 (slashing taxonomy and penalty tiers), No. 156 (M-1 aggregation commit-reveal), No. 192 (auditor commit hash sender binding), No. 193 (S5 recidivism). This should also get a row in the adversarial threat model (Developer/design/adversarial-threat-model.md).

cc @abrahamnash for Part B.

[umeradl]

Decision (2026-09-30): PR No. 197 merges with the overflow; Part A is now a hard blocker for any deploy from develop.

PR No. 197 is being merged into develop with DINTaskCoordinator at 24,585 B runtime, 9 B over EIP-170, rather than holding the PR for the size fix. Consequences until Part A lands:

• No task-contract deploy from develop to Optimism Sepolia (or any real chain), including DevNet 3.0. DINTaskCoordinator is deployed per model by each model owner, and the deploy will revert.
• The local devnet won't show the problem (foundry/anvil.sh lifts the code-size limit), and neither will CI or forge test. A green local run is not evidence that the contract is deployable.
• PRs that add code to DINTaskCoordinator before Part A lands make the gap bigger. Reviewers should post forge build --sizes for it until the CI gate exists.

Part A's acceptance criteria are unchanged: the contract must get back under the limit with the agreed margin (proposed ≥ 1,024 B), not just by 9 B.

[umeradl]

Status update: not closable yet

Checked on origin/develop @ 4ec42d4. Part A landed with PR No. 211, merged into develop as 84d0eef (size work in c96a063). develop can deploy task contracts to a real chain again, so the hard-blocker decision above no longer applies. Part B and the DINTaskAuditor review (Part A, proposal item 4) are still open.

Item	Status	Evidence
A1: size budget (≥ 1,024 B runtime, EIP-3860 initcode check)	✅	.github/scripts/contract_size_gate.py:30-31 (EIP3860 = 49_152, FAIL_MARGIN = 1_024); also warns below 2,048 B
A2: CI gate reads artifacts directly and covers DINTaskAuditor	✅	.github/workflows/ci.yml:69 runs the gate after forge build. The gate's table in CI run for 7785acf lists both task contracts
A3: DINTaskCoordinator under budget	✅	23,497 B runtime, 1,079 B margin (CI run above, after PR No. 212). The gate warns because the margin is below 2,048 B
A4: DINTaskAuditor meets the budget	✅	22,589 B runtime, 1,987 B margin (same run), so it also gets the under-2,048 B warning
A4: DINTaskAuditor gets "the same review" (per-phase duplication)	❌	Not done. task_021026_19 scoped Part A to DINTaskCoordinator only, and PR No. 212 has since added bytes to the auditor
A5: anvil.sh --code-size-limit override documented	✅	foundry/anvil.sh:9-12 comment points at the CI gate
Acceptance: budget recorded in CONTRIBUTING.md	✅	Developer/CONTRIBUTING.md:50 ("Contract size budget")
Part B: slash reason for committed-but-unrevealed (both flows)	❌	No decision yet. task_021026_19 lists it as out of scope (mechanism decision, tied to No. 155 / No. 38)

Remaining

1. Part B: pick one of the three options (distinct *_NO_REVEAL codes with their own fraction, treat as wrong-answer, or keep and document), then apply it to both commit-reveal flows. This needs the No. 155 S1/S2 fraction decision. cc @abrahamnash
2. DINTaskAuditor dedup review: the auditor is 61 B short of the 2,048 B warn line, and issues No. 205 (test-data dispute rework, task_021026_19 Part E) and the S3/scoring work will add to it. The review should happen before No. 205 lands, and it isn't tracked anywhere else yet.