task_240926_17 — Adversarial Suite (#154) + Testnet-Parameter Readiness (#155) (Robbert)

[umeradl]

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

The task file has the full specification: exact file/line references, the scenario matrix, and the deliverables checklist. This post is the summary, the assignment notice, and the decisions that need flagging while you build.

Timeline

Sep 24 – Oct 1, 2026. This is the same 7-day window as task_240926_16 (Discussion #163): both tasks are due by Oct 1. If both can't fit, say so early here. The likely trade is the stretch stress scenario first, then any Part 2 rows that depend on task_16 Parts A/B merging.

Summary

Three PRs into develop:

• Part 1: #154, threat-model doc (review gate).
  • Developer/design/adversarial-threat-model.md is a scenario matrix. Each row lists the attacker, capability, protocol response today, expected outcome (DEFENDED / COST-BOUNDED / KNOWN GAP) and trust assumption.
  • It also has a trust-assumptions section and a gaps-before-audit list.
  • It needs my sign-off before Part 2 tests are written against it. Aim to have it up within the first 2 days.
• Part 2: #154, P3Adversarial.t.sol.
  • One test per matrix row, named test_defended_… / test_costBounded_… / test_knownGap_…, each with an attack-narrative NatSpec block.
  • Multi-actor, multi-GI scenarios through the real GI lifecycle, not re-tests of paths already covered by SlashingInvariants.t.sol / PR146SlashingRegression.t.sol / DisputeResolution.t.sol.
  • Stretch: 10 GIs × 20 clients stress scenario in GasSimulation.t.sol.
• Part 3: #155, testnet-parameter readiness.
  • DeployPlatform.s.sol reads the tokenomics params via vm.envOr, defaulting to today's values.
  • A fix for the 0-bps S1/S2 slash fraction bricking slashAuditors/slashAggregators.
  • DinEmission's decayBps NatSpec fix.
  • The actual values come from the Fri Sep 25 meeting (decision table in the #155 review) and land afterwards as a follow-up commit (3d).

The #154 review supersedes the issue's original scope. Note especially:

• The dispute semantics are corrected. confirmed=true means the bond is returned and the original aggregators are slashed; confirmed=false means the bond is forfeited; expireDispute means the bond is fully returned and the fresh subgroup is slashed.
• The auditor/aggregator scenario is reframed. Auditors only judge client models and never see T1/T2 output, so the issue's "Auditor colluding with aggregator to pass a bad T2 model: S1 slash path" is replaced by three rows:
  • auditor-bloc approval of a poisoned client model;
  • T1-majority wrong CID;
  • cross-role dual registration + owner batch-routing.

Decisions to flag, not guess

1. Part 1, expected-outcome column: this is the judgment call in the task. Where DEFENDED vs. GAP is unclear (e.g. the colluding-T1-majority row, or whether dual-role registration in one GI is intended), flag it in the doc PR.
2. Part 1/2, KNOWN GAP rows: each links an open issue. Open new ones where none exists.
3. Part 2, bug found by a scenario: open an issue and add a test_knownGap_. Don't fix it in Parts 1–2, which are test/doc only.
4. Part 3b: don't change who can set the S1/S2 fractions. That's a Sep 25 meeting decision. If the meeting changes authority for any parameter, that's a new issue, not more Part 3 scope.

Dependencies on task_240926_16

• The subgroup-steering row targets task_16 Part A's future-block seed. It's a test_knownGap_ until Part A merges.
• Bond-destination assertions are written after task_16 Part B merges, or asserted through its helper.
• Part 3 touches the same two task contracts as task_16. Rebase after whichever merges first.

Reference material

• Developer/tasks/task_240926_17.md: full spec
• #154, #155: tracking issues (each has a review comment with the agreed scope)
• Developer/design/slashing-taxonomy.md: S1–S6
• Documentation/technical/audits/foundry-src-security-review.md: C-1/H-2 (Sybil registration, grindable shuffles)
• Developer/design/MECHANISM_DESIGN.md §9 items 2, 13

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

[umeradl]

Heads-up: dincli dindao is now dincli dinrep — PR No. 175 landed on develop (merge 5864f7d, follow-up 8f9a90b). The DIN-Representative command group is renamed to match the role: dincli/cli/dindao.py → dincli/cli/dinrep.py, Documentation/public/roles/dindao.md → dinrep.md. Breaking, no alias — dincli dindao … now returns "No such command". Subcommands are unchanged (dincli dinrep deploy …, dincli dinrep add-slasher …, dincli dinrep registry …).

For this task: nothing to change — this task file and its branches don't reference the old name. Use dincli dinrep from now on.

[robertocarlous]

task_240926_17 — Progress update (2026-09-28)

Confirmed the dincli dindao → dincli dinrep rename — no impact on task_17 branches. Confirmed all three task_16 PRs (#171/#172/#173) are merged.

Part 1 — threat-model doc (open for review)

PR #182 — Developer/design/adversarial-threat-model.md

Ten scenario rows: Sybil N-identity no-participation (COST-BOUNDED), Sybil seat capture (COST-BOUNDED), recidivist missing votes (DEFENDED — S5), auditor bloc poisoned model (KNOWN GAP — S3 shadow), T1 wrong CID (DEFENDED via S4 — judgment call flagged), cross-role dual-registration (KNOWN GAP — judgment call flagged), challenger right/owner rejects (KNOWN GAP), subgroup steering (DEFENDED — lockDisputeSeed), reward manipulation (COST-BOUNDED), duplicate-update gaming (deferred — #39).

Two judgment calls flagged for Umer review before Part 2 tests are written:

1. Row 5 — T1 wrong CID: Proposed DEFENDED under owner-adjudicator assumption + Row 7 as the separate gap. If you prefer the whole scenario KNOWN GAP, test name changes.
2. Row 6 — Dual-role registration: Nothing in the code prevents dual-role in the same GI. Marked KNOWN GAP, issue security: dual-role registration allows one operator to control both the auditor filter and T1 aggregator in the same GI #180 opened. If intentional (concurrent-registration cap is the intended defence), close security: dual-role registration allows one operator to control both the auditor filter and T1 aggregator in the same GI #180 and I will reclassify.

New issues opened: #180 (dual-role registration guard), #181 (decentralized dispute adjudication).

Part 3 — testnet-parameter readiness (in progress)

3a (DeployPlatform.s.sol vm.envOr), 3b (0-bps setter guard + zero-skip in slash loops), 3c (DinEmission header NatSpec) — building and testing now.

Part 2 — adversarial tests

Waiting for Umer sign-off on the threat-model matrix before writing.

[robertocarlous]

Part 3 PR open

PR #184 — feat(issue-155): testnet-parameter readiness

• 3a: DeployPlatform.s.sol reads all tokenomics params via vm.envOr; keys documented in .env.example
• 3b: 0-bps S1/S2 setter guard + zero-amount skip in slash loops
• 3c: DinEmission header NatSpec corrected (retention, not decay)
• 3d: Sep 25 meeting values — follow-up commit once confirmed

421/421 tests green.

[umeradl]

Status check (2026-09-30): not closing yet. Part 1 and Part 3a–3c have landed. Part 2 (P3Adversarial.t.sol) hasn't started, and Part 3d is waiting on the meeting values.

Checked against origin/develop at 6ccc28c.

Part	Status	Evidence
1: threat-model doc (No. 154)	✅ Landed, signed off	PR No. 182, merged 2026-09-28 (6e32e2a). Row 5/6 decisions recorded in 3768ce2; tracking issues No. 193 and No. 194 linked in ea349d6. Developer/design/adversarial-threat-model.md is on develop.
2: foundry/test/P3Adversarial.t.sol (No. 154)	⏳ Not started	The file doesn't exist on develop, there's no open PR, and no branch for it on your fork.
Stretch: 10 GIs × 20 clients	⏳ Open	Not in GasSimulation.t.sol, and the doc doesn't list it as deferred yet. One or the other closes this line.
3a: DeployPlatform.s.sol env parameters (No. 155)	✅ Landed	PR No. 184, merged 2026-09-29 (cc6120c, follow-ups 1ebb943). All eleven keys read via vm.envOr, overrides applied post-deploy, effective values logged, keys documented in .env.example. Script-level default/override tests came in with PR No. 200 (5ebd2fa, DeployPlatformScript.t.sol).
3b: 0 bps S1/S2 fix	✅ Landed	Both setters reject bps == 0. Both slash loops skip slashPartial when the computed amount is 0. Setter and rounding-path regression tests are in DeployPlatform.t.sol.
3c: DinEmission NatSpec	✅ Landed	Header now describes decayBps as a retention fraction.
3d: meeting values into the env	⏳ Waiting on me	The values from the tokenomics meeting aren't posted on No. 155 yet. Nothing for you to do until they are.
No. 154 issue text	⏳ Open	The issue body still has the original scope list and the inverted dispute semantics. Edit it, or add a comment noting that the review comment and the threat-model doc supersede it.

@robertocarlous, Part 2 has been unblocked since PR No. 182 merged on Sep 28. Three things to account for when you write it, because develop has moved:

• Shuffle-steering and batch-routing rows are closed gaps now. task_240926_18 Part B landed (525f256, follow-ups d95abdf): autoCreateTier1AndTier2 and createAuditorsBatches consume a future-block seed locked through lockAggSeed/lockAuditSeed. Write those rows as test_defended_ directly, along with the dispute-subgroup row (lockDisputeSeed, PR No. 171). Re-read the doc's rows on develop first; d95abdf updated them.
• T1/T2 submission is commit-reveal. PR No. 197 landed (d68f73a, follow-ups e373c8d). submitT1Aggregation/submitT2Aggregation no longer exist; scenarios go through commitT1Aggregation → startT1AggregationReveal → revealT1Aggregation → finalize, and the same for T2. AggregatorCommitReveal.t.sol has helpers worth reusing.
• Forfeiture assertions use the 50/50 split. task_240926_16 Part B is on develop, so settleRecomputation(false) burns half and forwards half.

The window ends Oct 1. If Part 2 won't land by then, say so here and give a date. The likely trade is the stretch scenario first, per the task's Notes.

This discussion closes once Part 2 has merged, the stretch line is resolved, 3d is recorded, and No. 154 and No. 155 are closed.