Testnet launch: action plan, early validator profile, and frontend

[robertocarlous]

@abrahamnash @Santiagocetran @umeradl @Abidoyesimze

Background

This discussion maps the remaining work to get from develop to a live testnet, proposes a profile for the early validators we want to bring in as testers, and names a gap that has no owner yet — the absence of any frontend for validators or other participants. All three are connected: the kind of validators we can realistically onboard is constrained by the tooling they have to use, and the tooling gap is large enough that it deserves an explicit decision before we start outreach.

---

1. Where we are

The P3 mechanism work is substantially complete on develop. Staking, slashing (S1–S6), dispute resolution (S4), commit-reveal aggregation, emission schedule, reward split, and the adversarial test suite have all landed. Deploy scripts support envOr overrides for every testnet parameter. Contracts are upgradeable proxies. CI runs on every develop push.

What remains is described honestly below.

---

2. Hard blockers before testnet

A. Contract size — DINTaskCoordinator is 24,585 B at runtime, 9 B over EIP-170 (#201 Part A). Foundry's local Anvil silently ignores this limit; nothing on develop can currently deploy to Optimism Sepolia or any real chain. This is the single most critical engineering blocker.

B. Testnet parameters — mintCap, dinPerEth, the DinEmission schedule, and the S1/S2 slash fractions are not recorded in .env.example (#155). The decision from the Sep 25 meeting needs to be committed. Validators cannot stake or earn anything meaningful without these set.

C. Open security findings — Seven findings are documented but unresolved: dual-role registration (#180), auditor commit hash not sender-bound (#192), per-model S5 recidivism (#193), upheld dispute does not replace wrong finalCID (#194), unauthenticated test-data dispute (#205), registerDINaggregator without onlyCurrentGI (#206), and committed-but-unrevealed at liveness fraction only (#201 Part B). The team needs to decide explicitly which of these are testnet-acceptable known gaps and which need a fix before external stake is exposed to them.

D. Validator operator guide — There is no public end-to-end guide that takes a new validator from setup to earning rewards. The technical reference docs exist but the operator-facing staking guide, slashing rules, and failure-mode recovery docs are still planned (P3-DOC2–4).

E. dincli gaps — BL-27 (dinrep deploy uses old constructors) and BL-28 (no releaseGIRegistrationSlots command) block the model owner from running a GI, which means validators have nothing to participate in.

---

3. Proposed action plan (ordered)

Priority	Item	Tracking
1	Fix DINTaskCoordinator to under EIP-170	#201 Part A
2	Record testnet parameter values in .env.example	#155
3	Triage security findings: fix-before-testnet vs. documented-gap	#180 #192 #193 #194 #205 #206
4	Fix dinrep deploy constructor mismatch and add releaseGIRegistrationSlots	BL-27, BL-28
5	Write validator operator guide: wallet → stake → first GI	P3-DOC4
6	Write public slashing rules and failure-mode recovery doc	P3-DOC3
7	Run one full end-to-end GI internally on Optimism Sepolia	—
8	Onboard first two external validator partners	OPS-1
9	Announce first external validator publicly	OPS-2

The SDK/daemon (P4) and indexer (P4-IDX) are not on this critical path. Testnet can run on the existing dincli CLI.

---

4. Early validator profile

We are targeting two to three external validators for the initial cohort.

Technical baseline:

• Comfortable running Docker Compose and a Python CLI
• Has operated a node or validator on another network before (Cosmos, Solana, or similar counts)
• Can read a transaction on Etherscan and understand a basic staking/slashing flow
• Uses a dedicated burner wallet

Domain interest:

• Interested in decentralised AI/ML infrastructure, not purely yield-driven
• Willing to give honest feedback on documentation gaps and UX friction
• Available for a 30-minute onboarding call and a quick debrief after their first GI

Role split:

• At least one aggregator: heavier compute (downloading weights, running aggregation), less latency-sensitive. Good fit for someone with a cloud VM or home server.
• At least one auditor: lighter compute (scoring model updates), more sensitive to the commit-reveal windows. Good fit for a reliable connection and availability during GI windows.

What we are not looking for at this stage: pure yield validators with no interest in the ML side, or anyone who cannot tolerate a rough edge — testnet will have them.

The reason to be selective: a bad first external validator experience sets back credibility more than staying internal for another two weeks.

---

5. 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.

To make the decision concrete, there are three realistic approaches:

Option A — Web app (browser + wallet)
A React/Next.js app that connects via MetaMask or WalletConnect and talks to the contracts via ethers.js. Validator never installs Python. Fully hosted. The problem: the compute-heavy roles (aggregation, model scoring) cannot run in a browser. A web app can handle wallet and staking operations but cannot replace the full validator workflow for aggregators and auditors.

Option B — Desktop app wrapping dincli
A native desktop app (Tauri is the lightweight option) with a visual interface that runs dincli commands in the background. The validator installs one app; it handles Python and Docker setup under the hood. This covers the full validator workflow including the compute-heavy parts, and is closer to how other validator networks package their node software. Higher build cost but the most complete solution.

Option C — Web dashboard served from the daemon
The P4 daemon (dind) is planned to expose an HTTP /health endpoint. This could be extended to a full local web UI: validator installs dind, opens localhost:7432 in a browser, and gets a live visual of their stake, current GI state, what action is needed next, recent rewards, and slash history. This is the most natural fit for the existing roadmap — it builds on top of P4 rather than adding a separate workstream — but it is gated on dind shipping, which is currently not merged to develop.

General Questions for the team:

1. Is a frontend in scope before testnet, or is the early testnet validator cohort (section 4 above) intentionally CLI-only with the frontend following for a broader launch?
2. If it is in scope, which option should we pursue — Option B (desktop app, standalone workstream) or Option C (web dashboard on top of dind, tied to P4 schedule)?
3. If Option B, who owns it and what is the scope for a v1? A practical v1 might cover just three flows: wallet setup and staking, GI registration and participation, and reward claim — with the full monitoring view as a v2.
4. Are there validators or model owners the team has already spoken to who have expressed a specific preference here?

The frontend decision affects the validator profile in section 4. If a frontend ships before broader outreach, we can open onboarding to a wider pool. If it stays CLI-only, the profile in section 4 is the right filter for the foreseeable future.

---

@Abidoyesimze — tagging for the frontend decision since you will be handling that aspect (section 5).