Testnet readiness — what needs to be in place before we ship? (prep for week-of-14th deep dive)

[umermjd11]

On our sync call (Sep 8) we agreed to hold a half-day deep-dive the week of Monday, Sep 14, to actually nail down what "testnet" means for DIN and what has to be in place before we ship it. Opening this thread now, per Abraham's ask on the call, so we go in with an itinerary instead of starting cold — drop your points here and we'll consolidate before the call.

Why this needs its own discussion

We haven't formally scoped this anywhere. ROADMAP.md names "testnet-ready" as the P3 goal (staking, slashing, rewards, scoring, tokenomics, fee flows, DAO-governed controls) but doesn't define a shippable checklist — a line in a phase goal isn't the same as a launch bar we can check items off against. The P3 "long-term" phase goals gesture at what's still open:

• Full devnet integration of all P3 components
• Adversarial, collusion, Sybil, and stress testing
• Smart contract audits; gas optimisation and L2 readiness
• Public documentation: staking guide, slashing rules, validator guide, tokenomics paper

None of that is broken down into "must exist before testnet" vs. "can land after testnet is live." That's what this thread and the call are for.

Starting questions (add your own)

• Scope bar: does "testnet" require all of P3 merged and hardened (staking + slashing + rewards + scoring + tokenomics + DAO param controls), or is there a smaller subset that's honestly sufficient for an initial external-facing testnet?
• Security bar: do we need a formal audit before testnet, or is testnet itself the adversarial/stress-testing environment, with mainnet gated on the audit instead?
• Operational readiness: Task 0 items (SIGTERM handling, keystore security, /health endpoint, structured logging, service manager units) — which of these are hard blockers for letting external validators onto the network vs. nice-to-haves?
• Docs: staking guide, slashing rules, validator guide, tokenomics paper — do these need to exist before testnet opens, or can they trail the first cohort of validators by a couple weeks?
• Definition of done: what's the actual exit criteria — a merged PR list, a checklist doc, a go/no-go review? Right now there isn't one written down anywhere.

Logistics

Half-day block, week of the 14th (weekday or weekend, whichever works for everyone) — let Abraham know your availability by email so he can lock a time. Use this thread to get thoughts down beforehand so the call is working from a shared list rather than starting from zero.

cc @abrahamnash @robertocarlous @Santiagocetran — add anything you think is missing above.

[robertocarlous]

Thanks for opening this, Umer. Good to have somewhere to collect thoughts before the call.

Availability: Free anytime from 12pm WAT that week, weekday or weekend asides sunday.

Scope bar: I'd push for a smaller shippable subset rather than waiting for all of P3. Anything that makes the network unsafe for validators to put real stake into is a hard blocker; anything that makes it incomplete is testnet scope. On that basis, a few things I'd call pre-launch blockers from the current backlog:

Security bar: Gate the audit on mainnet, not testnet , testnet is where we find what the audit would catch. Slashing and reward settlement paths should have adversarial test coverage before external validators join, even without a formal audit.

Docs: Staking guide and slashing rules before the first external validators join; tokenomics paper and validator guide can trail by a couple of weeks.

Looking forward to the call.

[Santiagocetran]

Availability: Friday the 18th from 9am Argentina time (UTC-3), which is 1pm WAT. Any
other day that week I can organise around whatever suits the rest of you.

Short takes on your questions:

Scope. With Robbert on a smaller subset, and on clearing anything that makes the network
unsafe. Worth being precise about what that means here: on a test chain almost all economic
harm evaporates. What survives is the harm that isn't chain-dependent at all, meaning keys,
host and data, plus anything that feeds a future allocation. How much of that we need to
cover depends on who's in the first cohort and whether access is really restricted to them,
so I'd settle that first.

Security. Agree an audit shouldn't hold up a small invited group. I'd still want the
known findings that affect that scope closed or mitigated first, checked against what we
actually deploy rather than what's merged.

Operational. The two I wouldn't move on: how we store people's private keys, and being
upfront about what running a node actually costs in hardware. I'd also want some way to
see whether a node is healthy and what it was doing when it broke, even with only two
people running one, otherwise every problem turns into guesswork over chat. Stopping
cleanly without losing work in progress should be shown working rather than assumed.
Starting on boot and restarting after a crash can come later.

Docs. Happy to go through what we have in detail and open issues for whatever's missing
or out of date. That should make it clearer what genuinely has to exist before we open up
and what can trail.

See you on friday :)

[umermjd11]

Proposal for a release sequencing, to give the "scope bar" and "definition of done" questions above a concrete shape:

DevNet 1.0 → DevNet 2.0 → DevNet 3.0 → Testnet, not DevNet → Testnet directly.

• DevNet 1.0 (shipped) surfaced real bugs and gaps — that's exactly what it was for. Those findings are what's driving the P3 (and some P4) work in flight right now; none of it has shipped back out yet.
• DevNet 2.0 should be the release that actually integrates that fix set. Open question tied to the sequencing thread on #139: does 2.0 ship with P3 only, or P3 + P4 together? P3 is close to release-ready on its own; folding P4 in too means real merge work on two 187-commit-stale branches first. Either way, 2.0's job is the same — put the fixes in front of real usage again and see what breaks.
• DevNet 3.0 is where whatever DevNet 2.0 surfaces gets fixed. This is the step that's easy to forget to plan for — 2.0 will find things, the same way 1.0 did, and 3.0 needs to be budgeted as a real release, not an afterthought.
• Testnet is a different kind of undertaking entirely, not just "DevNet but external." It needs, at minimum:
  • Real marketing — testnet is the first external-facing surface; nobody shows up to an unannounced testnet.
  • Real infrastructure — RPC/IPFS capacity, monitoring and alerting, and an on-call/incident-response process sized for external traffic, not a dev's laptop.
  • Tokenomics finalized and signed off — not shadow-mode thresholds and open DAO-settable numbers (§9 still has open items), an actual locked parameter set people are staking real expectations against.
  • Mass validator onboarding — a real funnel: onboarding docs, a low-friction setup path, and an incentive structure that gets validators beyond the current team, not just the staking/slashing/rewards mechanism working in isolation. This is a distinct workstream from the contracts being correct.
  • A completed security audit (or an explicit, documented decision to treat testnet itself as the adversarial-testing environment, per the "security bar" question above) — P3-6.2 (stress/collusion/Sybil testing) hasn't started yet and is the natural gate before an audit even makes sense.
  • Legal/compliance sign-off on token distribution, given the fair-launch design (BL-18) — worth getting ahead of before external users are staking or holding DIN.
  • Support/community ops — someone answering validator questions and triaging incidents once it's not just the four of us running the network.

Net: DevNet 2.0/3.0 is a two-release loop to burn down what 1.0 found (and settle the P3-vs-P3+P4 sequencing question); testnet is a separate bar that starts only once that loop is done and the list above is actually checked off, not run in parallel with it.

[umermjd11]

Following up on my sequencing comment above with the actual detail, so we walk into the call with a checklist instead of a shape.

A. Testnet requirements, broken out by the three bars already on this thread

Robbert's bar is "unsafe for staked funds," Santiago's is "chain-independent harm survives even on a test chain," mine was the release-sequencing shape. Overlaying those three against what's actually in ROADMAP.md / BACK_LOG.md today:

A1. Chain-independent harm (Santiago's framing) — blocking regardless of cohort size

This is keys, host, and data — none of it gets safer just because it's a test chain.

• Keystore security (P3-T0.2b) — passphrase-prompted keystore, no plaintext key in .env/disk. Still shows 📋 Planned in ROADMAP.md as of the last edit, and nothing in the Sep 11 P3 status update (which covers the 8 cryptoeconomic PRs) touches it. Worth confirming on the call whether this actually shipped somewhere unrecorded or is genuinely still open — if it's still open, this is the single sharpest blocker Santiago flagged.
• Resource ceiling docs (same P3-T0.2b) — minimum/recommended RAM/CPU/disk/network per role. Same status question.
• Graceful SIGTERM (P3-T0.2a) — Santiago asked for this "shown working," not assumed. The pattern exists in daemon form in draft PR #32 (feat/din-sdk, unmerged), but that's the P4 daemon, not the base dincli/din-node container path P3-T0.2a describes. Those are two different surfaces — daemon SIGTERM handling merging doesn't retroactively close the CLI-level item.
• /health endpoint + structured logging (P3-T0.2c/.2d) — same situation: implemented and tested in PR dind #21: daemon scaffold, preferences/capabilities, BL-19/20/21 hardening, first real job type (P4-1.1, P4-2.1/2.2) #32's daemon scaffold, not yet present on the base container path that ships today.
• systemd/launchd units (P3-T0.2e) — same, 📋 Planned.

Net: before we call chain-independent harm closed, we need a real status check on T0.2a–e against what's on develop today (not what's implemented in an unmerged daemon branch). This is the concrete version of "known findings closed or mitigated, checked against what we actually deploy" from Santiago's comment.

A2. Contract-level safety for staked funds (Robbert's framing)

• Slashing/reward adversarial coverage — Robbert's ask. SlashingInvariants.t.sol exists (PR feat(foundry): slashing taxonomy, invariant tests, and dispute-resolution scaffold (task_210726_6 Part 4, #38) #66) but had 3 failing tests pending PR Feat/p3 staking #65's burn/treasury update — worth confirming those are green post-#117 before external validators stake against it.
• BL-11 — dispute-redo subgroup selection still shuffles via grindable blockhash, and the grinding party (model owner) is also the sole adjudicator with no deadline. This is exactly the kind of thing that's fine in an internal 4-person devnet and not fine once external validators can be on the losing end of a dispute they can't trust the randomness of. I'd put this on the blocker side, not the "trail it" side — it undermines the one collusion-catching mechanism we have.
• MECHANISM_DESIGN §9 item 2 — partial-slash penalty fraction is still an open DAO-settable number, not yet backed by P3-5.2 income-simulation data. If we open testnet with this unset, validators are staking against a rule we haven't picked yet.
• P3-6.2 stress/collusion/Sybil testing — per the Sep 11 ROADMAP update this hasn't started. This is also the thing Santiago named as the natural gate before an audit even makes sense — so it sits on the critical path to both "testnet-safe" and "auditable," not just one of them.
• Encrypted-test-data-key dispute path (PR #63 follow-up, per my backlog notes) — no dispute resolution defined yet for that flow specifically; separate from the general dispute scaffold above.

A3. External-facing surface (my sequencing comment, expanded)

Restating with owners/sources attached instead of just naming the categories:

Item	Status / source	Notes
Real infra (RPC/IPFS capacity, monitoring, on-call)	Not started as a workstream	Distinct from any single PR — this is ops headcount/process, not code
Tokenomics locked (not shadow-mode)	§9 items 2, 3, 6, 7, 13 still open	Items 1, 4, 5, 8, 9, 10, 11 already resolved per Abraham's Jul 21 calls — so this is narrower than "all of tokenomics," just the 5 remaining numbers
Mass validator onboarding funnel	P3-DOC2/DOC4 (staking guide, operator guide) 📋 Planned; OPS-1 (2–3 validator partners) 📋 Planned	Docs are gated on P3-T0.2b per DOC4's own dependency line — another reason A1's status matters
ToS/participation-agreement acceptance wired into the tooling itself (dincli/dind), plus a website to actually launch on	Not tracked as tooling anywhere — BL-4/BL-5 (client/model-owner tooling layer) sit at 💭 Idea, P4/P5; no website-launch workstream exists at all	A doc or guide doesn't scale past a hand-held cohort — "massive" validator/client/model-owner onboarding needs an accept-before-register step in the tooling itself (not just a page someone can skip) and a public site to actually land people on; this is also the delivery mechanism for the ToS/disclaimer item in my comment below
Security audit or documented "testnet is the adversarial env" decision	Not yet decided in writing	Robbert's proposal (gate audit on mainnet) is the working assumption on this thread but hasn't been ratified anywhere formal
Legal/compliance on fair-launch distribution	BL-18 — contract slice merged (PR #77), eligibility-computation slice blocked on the indexer (#24/#29)	Legal sign-off itself isn't tracked anywhere yet — worth a named owner
Support/community ops	Not started	Same category as infra — a people/process gap, not a code gap

B. What DevNet 2.0/3.0 should actually be spending its effort on

Separate question from "what blocks testnet" — this is "given 2.0 ships P3 (+ maybe P4), what should the 2.0→3.0 loop be hardening, and what should be deliberately left for P5/P5+ rather than rushed into 2.0/3.0."

2.0/3.0's real job, per my sequencing comment: take the P3 fix set (now 8 merged PRs + the BL-10..15 follow-ups) and the P4 tracks (#29/#72 indexer, #31/#32 SDK+daemon), put them in front of real usage, and see what breaks — the same role DevNet 1.0 played for what became today's P3 backlog. Concretely, that means:

• Close out what's already known, not open new scope. BL-11 (dispute-redo randomness), the §9 item 2 partial-slash fraction (once P3-5.2 sim data exists), and the T0.2a–e status question above are the highest-value things to burn down in this loop — they're already scoped, already understood, just not finished.
• Land the P4 merges cleanly. Per discussion #139: feat(indexer): implement DIN Protocol subgraph — platform + task-level contracts #29's two blockers, SDK #20: dincli/sdk foundation — loaders, manifest/runtime, state/serialize, wallet/session/tx, operations #31's wallet-test isolation gap, then both integration branches into develop (187 commits stale each — real conflict-resolution work, not a fast-forward). The unowned contract-event-addition gap for the indexer (LocalModelSubmitted etc., audited in July, still not in any Solidity source) needs an assignee before 2.0, or Start DIN-Indexer #24 stays permanently half-lit.
• Run P3-6.2 (stress/collusion/Sybil) against the merged result — this is 2.0/3.0's actual reason to exist, not a checkbox.

What I'd deliberately push to P5/P5+ rather than let scope-creep into 2.0/3.0 or the testnet bar itself — these are all things the team has already, correctly, been declining to pull forward:

• DIN-DAO in full (BL-16, DD-1/DD-2 open) — Abraham's Aug 4 call already deferred this past mainnet, off-chain governance in the interim. Nothing here should change that.
• DPoS delegation (§9 item 10) — explicitly parked to P5+ already; §8.1 delegator/removal semantics wait on it.
• Curated per-model staking / fee attribution (BL-17) — Robert's own comment leaves P4-vs-P5 open; given it's a real economic redesign (network-pool → per-model attribution), it belongs after testnet data exists to design against, not before.
• dinPerEth rate-setting authority + ICO/token-sale mechanics (§9 items 13, 14) — both explicitly unresolved, both need a live faucet/testnet population to reason about realistically rather than being designed in the abstract.
• MAX_SUPPLY hard cap (§9 item 5) — deliberately left open/dynamic; a governance-set cap "once the economics are proven" is a P5+ decision by design, not an oversight.
• Slashing-framework translation (§9 item 12) — Abraham's Ethereum-DPoS framing needs a real translation pass onto DIN's S1–S6 conditions; better done with testnet slashing data in hand than speculatively now.
• DP mechanism precision (BL-24, F4 — Laplace calibrated against L2 clip) — needs a DP specialist's sign-off, not something to rush for testnet; flag it as a known-open item in the DP docs and move on.

C. Definition of done

Given there isn't one written down anywhere (per the thread), I'd propose the call end with a single checklist doc — Developer/design/testnet-readiness.md or similar — with each row from A1–A3 above as a line item: owner, current status, and a hard yes/no on "blocks opening testnet" vs. "trails by N weeks." That gives us something to actually check off against instead of re-deriving the bar every time someone asks "are we testnet-ready yet."

Happy to draft that doc structure ahead of the call if useful — say the word and I'll put a skeleton up as a PR.

[Santiagocetran]

Hi @umermjd11 — taking A1 since every row in it is mine. Status check done against origin/develop @ 87f6d19 (the Sep 11 true-up commit), not against my branches. Short version: A1 is in better shape than the ROADMAP suggests, but for a reason worth stating precisely, because it changes what "blocking" means for four of these five rows.

T0.2b keystore — shipped, row is stale

This one is done on develop and has been since early July:

• Passphrase-prompted encrypted keystore, dincli system connect-wallet and register-wallet --keystore — dincli/cli/utils.py (_extract_keystore, Account.decrypt), dincli/cli/system.py.
• Migration documented — Documentation/public/guides/keystore-migration.md, plus wallet-setup.md.
• Plaintext storage is demo-mode only and gated behind explicit warnings; --demokey is labelled DEMO MODE ONLY in the help text.

So the sharpest item on your list isn't open. Two honest residues rather than a clean tick:

1. --account <N> with demo mode off still reads a raw ETH_PRIVATE_KEY_<N> out of the environment (system.py:529, :1261). The .env.example calls it DEV ONLY, but T0.2b said remove or replace, and the code path is still live. Small fix, and worth doing before external operators arrive.
2. dincli/docker/node/.env.example:25 points operators at Documentation/guides/wallet-setup.md. The files are at Documentation/public/guides/. Dead path, in exactly the doc that tells someone how to handle their key safely.

T0.2b resource ceilings — genuinely open, and I'd call this A1's real remaining blocker

All that exists is one generic block in Documentation/public/getting-started.md:148 — 4 GB RAM, ~30 GB disk, "standard CPU". T0.2b asked for minimum and recommended, per role (aggregator / auditor / client), including network bandwidth, tied to the Compose comments. None of that exists.

It's the cheapest item in A1 and it's a stated external-validator blocking requirement. I'll take it.

T0.2a / c / d / e — not absent, superseded

Correcting the framing rather than the status. Your read was that the daemon work doesn't close the CLI-level items because they're two different surfaces. That's right about dincli itself, but not about the din-node container path — and that's where these rows actually live.

On develop today, dincli/docker/node/Dockerfile is:

# main process just idles. When `dind` exists this CMD becomes its entrypoint.
CMD ["sleep", "infinity"]

The container's main process is sleep infinity. There is nothing to send SIGTERM to, nothing to health-check, and nothing emitting a log stream — dincli runs one-shot via docker compose exec. So T0.2a/c/d aren't unimplemented on the container path so much as not implementable there until dind becomes that process, which the Dockerfile comment says was always the plan. The ROADMAP notes already record it: T0.2a says "this is no use for DIN cli now. DIN Daemon may need it", and T0.2c and T0.2d both say "Pattern reused in P4-1.1."

On feat/din-daemon all four are built (this is the branch behind the daemon PR — A1 labels it feat/din-sdk, which is the SDK branch; the dind modules are on feat/din-daemon):

Row	Where	State
T0.2a SIGTERM	dincli/dind/signals.py	SIGTERM/SIGINT → stop event; shutdown releases the lock, tears down control + health, and calls reset_running_jobs() so nothing is stranded running
T0.2c /health	dincli/dind/health.py	JSON payload; degraded answers 503 not 200 (BL-20), so a plain curl -f distinguishes hung from crashed
T0.2d logging	dincli/dind/logging.py	Line-delimited JSON, rotating file under the state dir alongside stderr; context fields are role, network, model_id, gi, job_id, error_code — T0.2d's list exactly
T0.2e units	dincli/dind/examples/dind@.service, com.din.dind.plist	Restart=on-failure, KillSignal=SIGTERM, TimeoutStopSec=30, journald

The Compose integration is there too — the daemon branch flips the entrypoint to CMD ["dind", "start"] and wires a real healthcheck: against /health. T0.2e's network-isolation half is already on develop (--network none at system.py:161 and worker.py:146, documented in the node README).

One genuine remainder that the daemon does not cover: T0.2a's first clause, auditing long-running dincli paths (worker spawns, IPFS fetches, chain calls) for interrupt-and-corrupt risk. Ctrl-C on a one-shot CLI command mid-job is a different problem from daemon shutdown, and nothing has been done on it.

What I'd propose

Treat dind as the supported operator surface for testnet, and record that instead of carrying four rows that read as untouched work:

• T0.2c, T0.2d, T0.2e — close as delivered by P4-1.1 when the daemon PR merges. They're built and tested; the merge is the gate, not the implementation.
• T0.2a — split. Daemon half: same as above. CLI half: either a small scoped item for interrupt-safety of one-shot commands, or an explicit decision that we accept it, on the grounds that the CLI is operator-attended and the daemon is what runs unattended. I'd lean toward writing down the acceptance rather than opening work, but I don't want to make that call unilaterally since it's the one piece of A1 that stays genuinely open.
• T0.2b — keystore half closed today, with the two fixes above. Resource table is real work and I'll do it.

Net for the call: A1 is gated on one merge plus one missing document, not on four unstarted rows. The thing actually worth arguing about is the merge — those branches are ~106 commits behind develop, and until they land, the container path we'd hand an external validator has no shutdown handling, no health endpoint and no persistent logs, regardless of what's built.

Happy to open the resource-ceiling table as a PR this week either way.

[robertocarlous]

Following up on my sequencing comment above with the actual detail, so we walk into the call with a checklist instead of a shape.

A. Testnet requirements, broken out by the three bars already on this thread

Robbert's bar is "unsafe for staked funds," Santiago's is "chain-independent harm survives even on a test chain," mine was the release-sequencing shape. Overlaying those three against what's actually in ROADMAP.md / BACK_LOG.md today:

A1. Chain-independent harm (Santiago's framing) — blocking regardless of cohort size

This is keys, host, and data — none of it gets safer just because it's a test chain.

• Keystore security (P3-T0.2b) — passphrase-prompted keystore, no plaintext key in .env/disk. Still shows 📋 Planned in ROADMAP.md as of the last edit, and nothing in the Sep 11 P3 status update (which covers the 8 cryptoeconomic PRs) touches it. Worth confirming on the call whether this actually shipped somewhere unrecorded or is genuinely still open — if it's still open, this is the single sharpest blocker Santiago flagged.
• Resource ceiling docs (same P3-T0.2b) — minimum/recommended RAM/CPU/disk/network per role. Same status question.
• Graceful SIGTERM (P3-T0.2a) — Santiago asked for this "shown working," not assumed. The pattern exists in daemon form in draft PR #32 (feat/din-sdk, unmerged), but that's the P4 daemon, not the base dincli/din-node container path P3-T0.2a describes. Those are two different surfaces — daemon SIGTERM handling merging doesn't retroactively close the CLI-level item.
• /health endpoint + structured logging (P3-T0.2c/.2d) — same situation: implemented and tested in PR dind #21: daemon scaffold, preferences/capabilities, BL-19/20/21 hardening, first real job type (P4-1.1, P4-2.1/2.2) #32's daemon scaffold, not yet present on the base container path that ships today.
• systemd/launchd units (P3-T0.2e) — same, 📋 Planned.

Net: before we call chain-independent harm closed, we need a real status check on T0.2a–e against what's on develop today (not what's implemented in an unmerged daemon branch). This is the concrete version of "known findings closed or mitigated, checked against what we actually deploy" from Santiago's comment.

A2. Contract-level safety for staked funds (Robbert's framing)

• Slashing/reward adversarial coverage — Robbert's ask. SlashingInvariants.t.sol exists (PR feat(foundry): slashing taxonomy, invariant tests, and dispute-resolution scaffold (task_210726_6 Part 4, #38) #66) but had 3 failing tests pending PR Feat/p3 staking #65's burn/treasury update — worth confirming those are green post-#117 before external validators stake against it.
• BL-11 — dispute-redo subgroup selection still shuffles via grindable blockhash, and the grinding party (model owner) is also the sole adjudicator with no deadline. This is exactly the kind of thing that's fine in an internal 4-person devnet and not fine once external validators can be on the losing end of a dispute they can't trust the randomness of. I'd put this on the blocker side, not the "trail it" side — it undermines the one collusion-catching mechanism we have.
• MECHANISM_DESIGN §9 item 2 — partial-slash penalty fraction is still an open DAO-settable number, not yet backed by P3-5.2 income-simulation data. If we open testnet with this unset, validators are staking against a rule we haven't picked yet.
• P3-6.2 stress/collusion/Sybil testing — per the Sep 11 ROADMAP update this hasn't started. This is also the thing Santiago named as the natural gate before an audit even makes sense — so it sits on the critical path to both "testnet-safe" and "auditable," not just one of them.
• Encrypted-test-data-key dispute path (PR #63 follow-up, per my backlog notes) — no dispute resolution defined yet for that flow specifically; separate from the general dispute scaffold above.

A3. External-facing surface (my sequencing comment, expanded)

Restating with owners/sources attached instead of just naming the categories:

Item Status / source Notes
Real infra (RPC/IPFS capacity, monitoring, on-call) Not started as a workstream Distinct from any single PR — this is ops headcount/process, not code
Tokenomics locked (not shadow-mode) §9 items 2, 3, 6, 7, 13 still open Items 1, 4, 5, 8, 9, 10, 11 already resolved per Abraham's Jul 21 calls — so this is narrower than "all of tokenomics," just the 5 remaining numbers
Mass validator onboarding funnel P3-DOC2/DOC4 (staking guide, operator guide) 📋 Planned; OPS-1 (2–3 validator partners) 📋 Planned Docs are gated on P3-T0.2b per DOC4's own dependency line — another reason A1's status matters
ToS/participation-agreement acceptance wired into the tooling itself (dincli/dind), plus a website to actually launch on Not tracked as tooling anywhere — BL-4/BL-5 (client/model-owner tooling layer) sit at 💭 Idea, P4/P5; no website-launch workstream exists at all A doc or guide doesn't scale past a hand-held cohort — "massive" validator/client/model-owner onboarding needs an accept-before-register step in the tooling itself (not just a page someone can skip) and a public site to actually land people on; this is also the delivery mechanism for the ToS/disclaimer item in my comment below
Security audit or documented "testnet is the adversarial env" decision Not yet decided in writing Robbert's proposal (gate audit on mainnet) is the working assumption on this thread but hasn't been ratified anywhere formal
Legal/compliance on fair-launch distribution BL-18 — contract slice merged (PR #77), eligibility-computation slice blocked on the indexer (#24/#29) Legal sign-off itself isn't tracked anywhere yet — worth a named owner
Support/community ops Not started Same category as infra — a people/process gap, not a code gap

B. What DevNet 2.0/3.0 should actually be spending its effort on

Separate question from "what blocks testnet" — this is "given 2.0 ships P3 (+ maybe P4), what should the 2.0→3.0 loop be hardening, and what should be deliberately left for P5/P5+ rather than rushed into 2.0/3.0."

2.0/3.0's real job, per my sequencing comment: take the P3 fix set (now 8 merged PRs + the BL-10..15 follow-ups) and the P4 tracks (#29/#72 indexer, #31/#32 SDK+daemon), put them in front of real usage, and see what breaks — the same role DevNet 1.0 played for what became today's P3 backlog. Concretely, that means:

• Close out what's already known, not open new scope. BL-11 (dispute-redo randomness), the §9 item 2 partial-slash fraction (once P3-5.2 sim data exists), and the T0.2a–e status question above are the highest-value things to burn down in this loop — they're already scoped, already understood, just not finished.
• Land the P4 merges cleanly. Per discussion #139: feat(indexer): implement DIN Protocol subgraph — platform + task-level contracts #29's two blockers, SDK #20: dincli/sdk foundation — loaders, manifest/runtime, state/serialize, wallet/session/tx, operations #31's wallet-test isolation gap, then both integration branches into develop (187 commits stale each — real conflict-resolution work, not a fast-forward). The unowned contract-event-addition gap for the indexer (LocalModelSubmitted etc., audited in July, still not in any Solidity source) needs an assignee before 2.0, or Start DIN-Indexer #24 stays permanently half-lit.
• Run P3-6.2 (stress/collusion/Sybil) against the merged result — this is 2.0/3.0's actual reason to exist, not a checkbox.

What I'd deliberately push to P5/P5+ rather than let scope-creep into 2.0/3.0 or the testnet bar itself — these are all things the team has already, correctly, been declining to pull forward:

• DIN-DAO in full (BL-16, DD-1/DD-2 open) — Abraham's Aug 4 call already deferred this past mainnet, off-chain governance in the interim. Nothing here should change that.
• DPoS delegation (§9 item 10) — explicitly parked to P5+ already; §8.1 delegator/removal semantics wait on it.
• Curated per-model staking / fee attribution (BL-17) — Robert's own comment leaves P4-vs-P5 open; given it's a real economic redesign (network-pool → per-model attribution), it belongs after testnet data exists to design against, not before.
• dinPerEth rate-setting authority + ICO/token-sale mechanics (§9 items 13, 14) — both explicitly unresolved, both need a live faucet/testnet population to reason about realistically rather than being designed in the abstract.
• MAX_SUPPLY hard cap (§9 item 5) — deliberately left open/dynamic; a governance-set cap "once the economics are proven" is a P5+ decision by design, not an oversight.
• Slashing-framework translation (§9 item 12) — Abraham's Ethereum-DPoS framing needs a real translation pass onto DIN's S1–S6 conditions; better done with testnet slashing data in hand than speculatively now.
• DP mechanism precision (BL-24, F4 — Laplace calibrated against L2 clip) — needs a DP specialist's sign-off, not something to rush for testnet; flag it as a known-open item in the DP docs and move on.

C. Definition of done

Given there isn't one written down anywhere (per the thread), I'd propose the call end with a single checklist doc — Developer/design/testnet-readiness.md or similar — with each row from A1–A3 above as a line item: owner, current status, and a hard yes/no on "blocks opening testnet" vs. "trails by N weeks." That gives us something to actually check off against instead of re-deriving the bar every time someone asks "are we testnet-ready yet."

Happy to draft that doc structure ahead of the call if useful — say the word and I'll put a skeleton up as a PR.

On A2 — contract-level safety, from my end:

SlashingInvariants.t.sol post-#117: All four open PRs (#146 S1/S2/S5/S6, #147 reward-sim, #148 emission, #149 S4 dispute) have CI green — Solidity + Python + Docs all pass. The invariant test suite is healthy in that context.

BL-11 (grindable blockhash in _assignFreshSubgroup): Agree this is a real blocker for testnet, not a "trail it" item. I'll put it plainly: my PR #149 implements the full S4 dispute second phase (settleRecomputation / expireDispute / resolutionDeadline) but does not fix the underlying randomness. _assignFreshSubgroup still shuffles via blockhash(block.number - 1) — the grinding window is still there. The concrete issue is that the model owner calls resolveDispute in the same transaction that sets the block context, with no deadline. Commit-reveal is the tractable fix here (VRF adds an oracle dependency; commit-reveal keeps it self-contained). I can open a dedicated PR for this — it's a bounded change to _assignFreshSubgroup and resolveDispute plus a new test suite. Call it out at the call as a named blocker with an owner.

§9 item 2 (partial-slash penalty fraction): This is now backed by numbers — not "open" anymore in the sense of "nobody has proposed a value." PR #146 implements DAO-settable s1SlashFractionBps (missed audit vote, default 3000 = 30%) and s2SlashFractionBps (missed T1/T2 submission, same default), with PR #147's simulation data providing the income-stability argument for why 30% doesn't destabilise a floor-staked validator at the modeled participation range. The 30% is my proposal, not a final decree — the DAO-settable parameter means testnet data can inform an adjustment. What I'd say is: this is unblocked pending PR #146 review, not a gap.

P3-6.2 (stress/collusion/Sybil testing): Not started, and that's on me for the contract side. Realistically: I can't start it meaningfully until PRs #146 and #149 are reviewed and merged, since the slashing taxonomy and dispute lifecycle are what the adversarial tests are exercising. Once those land I'd estimate a week to produce the collusion/Sybil/stress scenarios Umer has specced. Agreed it sits on the critical path to both "testnet-safe" and "auditable" — I'll flag if the review queue is the bottleneck there.

Encrypted-test-data-key dispute path: The key-correspondence gap (BL-13) is resolved via PR #110. The remaining piece Umer flagged — no defined resolution path for that dispute flow specifically — is something I haven't touched in any open PR. Worth clarifying on the call whether that's a gap in scope or an intentional deferral to P4, since PR #110 added the on-chain plumbing but the resolution adjudication (who decides the dispute, how the bond settles) for the test-data path specifically is separate from the aggregation dispute scaffold in DINTaskCoordinator.

BL-15 (one-dispute-per-batch undocumented): This is a doc fix, not a code change — I'll add a comment to _assignFreshSubgroup / resolveDispute and a note to slashing-taxonomy.md noting the one-shot design is intentional at this stage. Cheap to close.

On B / indexer contract events:

I asked in discussion #139 whether the task-level event additions (LocalModelSubmitted, T1AggregationSubmitted, T2AggregationSubmitted, GIStateChanged) belong to me as a follow-on from owning feat/din-indexer, or need a separate assignment. That's still pending an answer — happy to take it on but want confirmation before I start touching the task-contract event surfaces, since GIStateChanged in particular needs emit sites at every state transition in DINTaskCoordinator. If it's mine, I'll scope it as a follow-on PR against develop once #29/#72 land.

[umermjd11]

Per Umer's ask, this is a different lens than my comment above — that one was grounded entirely in our own ROADMAP/BACK_LOG/MECHANISM_DESIGN. This one steps outside it: I did a research pass on what other protocols, token networks, and (where they exist) decentralized-AI-compute networks specifically treat as pre-testnet requirements, then checked each candidate against our actual docs to find what genuinely isn't on our radar yet — not restating anything already tracked above.

Tagging each as testnet-blocking (needed before we open, even to a small cohort) or P5+ seed (real, but scales with network size — doesn't block an initial small testnet).

1. Sybil/uniqueness resistance for the fair-launch airdrop itself — testnet-blocking

BL-18's eligibility computation is scoped as "off the indexer, i.e. from on-chain event history" — that's a Sybil-DoS defense for staking (economic cost to spin up fake validators), but nothing addresses one person running many funded, independently-active validator identities to multiply airdrop share once real rewards are on the line. This is a distinct, well-documented failure mode industry-wide: protocols routinely build detection on funding-source tracing, timing/behavioral correlation across wallets, and proof-of-personhood layers (e.g. Human/Gitcoin Passport) specifically because naive on-chain-activity eligibility gets farmed at scale. Nothing in BL-18 or §9 names this as a question to answer, and it's on the critical path the moment testnet pairs a real airdrop with real validator activity.

2. Securities-law exposure of the airdrop path we're actually building — testnet-blocking

§9 item 14 and issues/tokenomics.md only analyze KYC/legal posture for the ICO/token-sale fallback branch. The validator-airdrop path — the one actually in progress (PR #77, BL-18) — has no equivalent analysis anywhere: whether a programmatic, contribution-based DIN distribution clears the Howey test, and whether we need to geoblock any jurisdictions before non-team wallets can receive it. "Legal/compliance sign-off" was already on my list above as a line item — this sharpens what that sign-off actually needs to answer, since the mechanism getting built isn't the one our existing docs did the legal thinking about.

3. Terms of participation / experimental-network disclaimer — testnet-blocking

Zero hits anywhere in Developer/ or Documentation/ for anything like a ToS, disclaimer, or "testnet is experimental, may be reset, no guarantee of migration to mainnet" notice. This is close to universal practice before external, non-team participants show up with real (if testnet) assets or expectations at stake — cheap to write, and it's the thing that sets expectations if/when a testnet reset wipes someone's accumulated activity.

Worth separating the doc from its delivery: writing the ToS is cheap, but nobody reads a markdown file nobody is forced to look at, and that doesn't scale past a hand-held cohort anyway. This wants an accept-to-proceed step wired into the tooling itself — dincli system register-wallet/connect-wallet and dind start are exactly the choke points every validator, client, and model owner passes through — plus a public website to actually host the ToS, docs, and onboarding funnel on. Neither exists as a tracked workstream today: BL-4/BL-5 (client/model-owner tooling layer) are still 💭 Idea for P4/P5, and there's no website-launch item anywhere. Added a row for this on the A3 table in my comment above.

4. Formal, numeric security bar — feeds directly into the thread's open "security bar" question

The thread is already debating "audit before testnet vs. testnet-as-audit" without reference points. Industry norms give concrete anchors: ~95%+ test coverage before engaging an external audit, two independent audits once a protocol custodies material value, and bug-bounty programs (Immunefi/HackenProof/Sherlock) typically starting at or after mainnet rather than testnet, with critical-tier rewards commonly $100K+. Doesn't resolve our open question, but gives the call something to calibrate against instead of arguing from first principles.

5. FL-specific Byzantine/poisoning defense, as a proactive rather than reactive item — testnet-blocking decision, not necessarily testnet-blocking implementation

scoring-mechanism.md already names the risk but defers it: "start with clipped averaging, then add robust update aggregation if poisoning pressure increases" — no trigger, no threshold for when that kicks in. Differential privacy (already well-covered in our docs) protects against reconstruction/inference; it does nothing against an adversarial client submitting a well-formed but poisoned update. Once testnet opens to non-team clients, "if pressure increases" needs to become an actual decision — either commit to robust aggregation before opening, or write down (the way BL-24's DP open-question note already does) that we're knowingly accepting this exposure for the initial cohort size. Either answer is fine; having none isn't.

6. IP/copyright/liability exposure for models, genesis weights, and audit test data — testnet-blocking (cheap)

No mention anywhere in our docs of who bears liability if a model owner's training data, genesis model, or audit test set carries copyright/licensing issues once it's coordinated (and artifacts pinned) through the network. This is an active, unsettled area for AI training generally, not just us — worth a short participation-agreement clause allocating that liability to the model owner rather than leaving it silent, before real external model owners join.

7. Incident-response runbook + public status/incident communication — testnet-blocking

Distinct from validator-operations.md's existing "public status page" item — that one's purpose is proving the network isn't empty before validators join. Nothing addresses what happens during an incident: a rehearsed runbook (the Security Alliance's web3 IR template is the standard reference here) and a way to communicate status to external participants mid-incident. "On-call/incident-response process" was already on my list above as a category; this names the concrete artifact that category is currently missing.

8. Two-sided marketplace onboarding — model owners, not just validators — P5+ seed, but worth naming now

Every onboarding item in our roadmap (P3-DOC2/DOC4, OPS-1) targets validators. Model owners — the other side of the marketplace, who register models and pay the fees the whole fee-router/tokenomics design routes — have no onboarding docs, funnel, or incentive program anywhere. An initial small testnet can run on our own example model(s); it doesn't need this day one. But it's exactly the kind of gap that's invisible from inside a P3/P4-shaped roadmap, since neither phase is about external model owners. Grant/incentive programs for early ecosystem builders (Pyth, NEAR, Polygon all run these) are the common pattern once we're past the first cohort.

9. Decentralization health as a public, visible metric — P5+ seed

Geographic/infra diversity of the validator set as a standing, visible dashboard — not the per-node /health endpoint (which is operator-facing), but an aggregate, public view the way Messari's methodology or Ethereum client-diversity dashboards work. Not a blocker for a small invited cohort (Santiago's framing), but a real gap once "testnet" means genuinely external and we want to credibly claim decentralization rather than assert it.

10. Community support structure beyond "someone answers questions" — P5+ seed

Already flagged support/community ops as missing in my first comment; the concrete, common shape other protocols use is a tiered ambassador/community-helper program (entry-level Discord support scaling into regional/content leads) rather than a binary "hire support staff" — worth having the shape in mind before OPS-1's validator-partner outreach scales past 2–3 people.

11. What the closest actual analogues do differently than a generic L1 checklist

Two comparisons worth having in mind for the call, since DIN isn't a consensus L1 and most testnet-checklist writing online assumes one:

• Gensyn's public testnet ran as an explicitly phased rollout — each phase adding one real capability (culminating in RL Swarm, live Nov 2025) rather than opening with the full feature set — closer to our own DevNet 1.0→2.0→3.0 loop than to a big-bang testnet launch.
• EigenLayer's AVS onboarding is deliberately permissioned — a vetting committee reviews each new service (audits, system-requirement checks) before it's allowed to draw on restaker security — which is structurally the same shape as our own slasher-authorization gate for new model owners (DinCoordinator → DinValidatorStake). Worth citing explicitly as validation that gate is the right shape, not a workaround.

[abrahamnash]

This is super, thank you, @umermjd11.