P3/P4 implementation status — what is done, what is blocking testnet

[robertocarlous]

Overview

Quick status update covering what has shipped, what is pending review, and what is concretely blocking the move to testnet. Also flagging the frontend gap explicitly.

---

What has been implemented (PRs open, CI green, awaiting review)

PR	What it does
#146	S1/S2 partial-slash tiers (DAO-settable fraction, default 30%) + S5 recidivism escalation + S6 no-participation counter
#147	P3-5.2 reward-split simulation — confirms 60/20/15/5 split is income-stable across 10–50 validators / 100–500 clients
#148	DinEmission — geometric decay protocol subsidy contract with upgrade validation
#149	S4 aggregation dispute second phase — settleRecomputation + expireDispute + resolutionDeadline state machine
#29 + #72	DIN subgraph — 34 entities, 31 handlers across all platform contracts; GraphQL-first with RPC fallback already wired into dindao.py

All four Solidity PRs have CI passing (Solidity + Python + Docs). PRs #29/#72 have two small blockers being fixed now (schema.graphql syntax error + one test file to rewrite to CliRunner).

---

What is blocking testnet

Contract safety

• BL-11 — dispute subgroup randomness. _assignFreshSubgroup still shuffles via grindable blockhash(block.number - 1). The model owner (who calls resolveDispute) can wait indefinitely for a favourable hash with no deadline — undermining the one mechanism meant to catch owner/aggregator collusion. Needs a commit-reveal fix before the dispute mechanism is trustworthy for external validators. Dedicated PR coming for this.

• P3-6.2 stress/collusion/Sybil testing has not started. Cannot begin meaningfully until PRs feat(slashing): S1/S2 partial-slash tiers + S5/S6 escalation (#38) #146 and feat(issue-38): S4 aggregation dispute second-phase state machine #149 are reviewed and merged — those are what the adversarial tests exercise. Estimated one week to produce the full scenario suite once they land.

• PRs feat(slashing): S1/S2 partial-slash tiers + S5/S6 escalation (#38) #146–feat(issue-38): S4 aggregation dispute second-phase state machine #149 pending review. All are merge-ready, none are draft. Blocked on review sign-off.

Indexer

• Two small blockers in PR feat(indexer): implement DIN Protocol subgraph — platform + task-level contracts #29 are being fixed (in progress, same-day fixes).
• Subgraph deployment to Optimism Sepolia needs the live contract addresses and a Subgraph Studio account to deploy into. Once those are available, deployment is ~2 days of work and costs $0 at testnet scale.
• Five subgraph handlers are waiting on task-level Solidity event emissions (LocalModelSubmitted, T1/T2AggregationSubmitted, GIStateChanged) — need confirmation on who owns that contract-side work before those handlers can be enabled.

Not my items but worth naming

• P3-T0.2a–e (SIGTERM handling, keystore security, /health endpoint, structured logging, systemd/launchd units) — all still 📋 Planned.

---

No frontend yet

There is currently no frontend application. All interaction with the protocol happens through dincli commands in the terminal. There is no web UI for validators, model owners, auditors, or clients.

This is worth naming explicitly before testnet — for any goal around onboarding a broader validator or client base, a terminal CLI is a real barrier for non-technical participants. If a frontend is in scope before testnet, that workstream does not exist yet and has no owner.

---

Tokenomics — what is live, what is stubbed, what needs a decision

What is live on develop today

Item	State
ETH → DIN faucet (depositAndMint) at 1,000,000 DIN/ETH	✅ Live
60/20/15/5 reward split (client/auditor/aggregator/treasury)	✅ Live
Slash burn 50/50 (half burned, half to treasury)	✅ Live
DinTreasury contract deployed	✅ Live (empty — nothing routes to it automatically yet)
DinFeeRouter routing slots defined	✅ Live
MIN_STAKE = 10 DIN (DAO-settable)	✅ Live
setMintCap() + retireFaucet() mechanics exist	✅ Live (no cap set yet — testnet value TBD)
Fair-launch Merkle drop contract (PR #77)	✅ Merged (eligibility computation blocked on indexer)

What is built but not yet merged

• PR feat(slashing): S1/S2 partial-slash tiers + S5/S6 escalation (#38) #146 — S1/S2 partial-slash fractions (proposed 30%) + S5/S6 escalation. The 30% default needs ratification before merge.
• PR feat(emission): DinEmission — geometric decay protocol subsidy contract (issue #42) #148 — DinEmission geometric decay contract. Contract structure is correct; the actual parameter values (initialEmissionPerGI, decayBps, epochLength, maxEpochs) have not been agreed on yet.

Treasury forwarding is stubbed — tokens never reach DinTreasury

Three places in the contracts accumulate treasury balances in a treasuryAccrued counter instead of forwarding to DinTreasury: the dispute bond forfeiture path in DINTaskCoordinator, the frivolous-dispute forfeit, and the reward-settlement treasury share (5% of every GI pool) in DINTaskAuditor. The treasury contract is deployed but nothing flows in automatically. Every GI run on testnet will strand treasury funds in the task contracts until this is wired up. This is task_100926_12 §2 — in progress.

Open decisions needed before testnet

Parameter	Current devnet value	What's needed
mintCap	0 (uncapped)	Total DIN faucet ceiling — depends on validator count × target stake
dinPerEth	1,000,000 DIN/ETH	Set relative to decided MIN_STAKE and cap — needs a principled rate
MIN_STAKE	10 DIN	Confirm or revise — all S1/S2/S5/S6 slashes are calculated against this
s1SlashFractionBps	— (PR #146 pending)	Proposed 3000 (30%) — confirm or revise
s2SlashFractionBps	— (PR #146 pending)	Proposed 3000 (30%) — confirm or revise
initialEmissionPerGI	— (PR #148 pending)	DIN minted per GI at epoch 0 — sets validator earnings from protocol subsidy
decayBps	— (PR #148 pending)	e.g. 9000 = 10% decay per epoch — needs simulation to calibrate
epochLength	— (PR #148 pending)	GIs per epoch — how quickly emission steps down
maxEpochs	— (PR #148 pending)	Total epochs before subsidy ends

MAX_SUPPLY: No permanent hard cap — intentionally dynamic, governed by issuance vs. burn, with a hard cap possible later via governance. For testnet, the mintCap serves as the effective supply ceiling (faucet + emission both respect it). Whether this is the intended design or needs a separate param for each source needs confirming.

Validator token distribution for testnet: How does an external validator get DIN to stake? Options are: (a) deposit ETH via the faucet, (b) testnet airdrop via the Merkle drop contract (blocked on indexer), or (c) manual allocation. Without a clear answer, external validators cannot onboard.

P3-DOC5 tokenomics paper has not been written. No public-facing write-up of the full token model (utility, emission schedule, fee routing, supply policy) exists for validator partners, grant reviewers, or auditors.

---

Happy to answer questions on any of the above or update this as things progress.

[robertocarlous]

Here is what has been integrated regarding tokenomics, slashing and what is left @abrahamnash @umeradl

I can raise a Github issue around the open question and fix what is left to be done before testnet launch

[abrahamnash]

Thank you, @robertocarlous.
Super, yes please.

[walkonwayvs]

On the validator token question, I can answer (a) from the outside. I registered as an aggregator on Model_0 GI 2 in July. Funded a throwaway wallet with OP Sepolia ETH, used the faucet for DIN, staked. The path works. It's still sitting in DINaggregatorsRegistrationStarted on GI 2 today, same as it was in July.

What I hit instead was that the phase never advanced after registration, and closeDINaggregatorsRegistration is owner-only with no threshold or timeout. So an external validator can onboard and then sit with no way to tell whether that's normal or broken. I wrote a script polling GI state every five minutes just to know which it was. That's the case for the /health endpoint.

If P3-T0.2a-e is still unowned I'll take it. SIGTERM handling, /health, structured logging and systemd units are what I run on my own nodes. I'd start with /health and the systemd units since those are what unblock anyone else trying to run one.

[robertocarlous]

On the validator token question, I can answer (a) from the outside. I registered as an aggregator on Model_0 GI 2 in July. Funded a throwaway wallet with OP Sepolia ETH, used the faucet for DIN, staked. The path works. It's still sitting in DINaggregatorsRegistrationStarted on GI 2 today, same as it was in July.

What I hit instead was that the phase never advanced after registration, and closeDINaggregatorsRegistration is owner-only with no threshold or timeout. So an external validator can onboard and then sit with no way to tell whether that's normal or broken. I wrote a script polling GI state every five minutes just to know which it was. That's the case for the /health endpoint.

If P3-T0.2a-e is still unowned I'll take it. SIGTERM handling, /health, structured logging and systemd units are what I run on my own nodes. I'd start with /health and the systemd units since those are what unblock anyone else trying to run one.

@walkonwayvs Thanks for this, really useful to have a real-world walkthrough from the outside.

Good to confirm path (a) works end-to-end — faucet → stake is the answer for testnet validator onboarding, so that question is closed.

The phase-advancement gap you're describing is a separate blocker I hadn't specifically raised. closeDINaggregatorsRegistration being owner-only with no timeout or threshold means an external validator genuinely has no signal after staking — that deserves its own issue. I'll raise one separately.

The polling script you had to write is exactly the problem issue #153 is meant to fix — once the missing task-level events are added to the contracts and the subgraph is deployed on Optimism Sepolia, validators can query GI state via GraphQL instead of polling RPC. That one's on me to land.

P3-T0.2a-e is unowned @umeradl would decide if you should take on this. Starting with /health and the system units is the right call, and your experience on GI 2 illustrates exactly why /health is the highest-priority item in that list. If /health had been exposing GI phase state in July you wouldn't have needed the polling script at all.

Cc: @umeradl

[umeradl]

@walkonwayvs thanks for raising this, and for sticking with it since July. You're right: Model_0 is still sitting in DINaggregatorsRegistrationStarted on GI 2 today.

Here's what happened. DevNet 1.0 was our first public developer deployment, and while running it we hit a major bug in the deployed contracts (dincli 0.1.0 at the time). If an aggregator misses its submission or submits a divergent one, slashAggregators reverts, because the task coordinator's minStake is below the stake contract's MIN_STAKE floor. endGI requires the AggregatorsSlashed state, so one non-submitting aggregator blocks the whole GI from ever ending. That's why GI 2 was never moved past registration.

The DevNet 1.0 contracts aren't upgradeable, so dincli 0.2.0 (already released on main) couldn't fix this. It needs a contract redeploy, and that hasn't happened. With P3/P4 now merging into develop, we're going straight to the DevNet 2.0 launch (fresh deploy, upgradeable proxies) rather than redeploying 1.0. On develop, a missed aggregator submission is now an S2 liveness slash instead of a revert, so that wedge is gone.

Your other point still holds on develop, though: closeDINaggregatorsRegistration and the other phase changes are owner-only with no threshold or timeout. @robertocarlous is raising a separate issue for that. I'll get back to you separately on P3-T0.2a–e. Your GI 2 experience is a strong case for doing /health first.