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.

✓ RESOLVED — PR #211 (merged 2026-10-02) brought DINTaskCoordinator under EIP-170 and added a CI size gate. Deployments to Optimism Sepolia are no longer blocked by contract size.

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 — Four findings remain open: dual-role registration (#180), per-model S5 recidivism (#193), upheld dispute does not replace wrong finalCID (#194), and committed-but-unrevealed at liveness fraction only (#201 Part B). Three findings were fixed and merged to develop this week: auditor commit hash not sender-bound (#192, PR #212), unauthenticated test-data dispute (#205, PR #215), and registerDINaggregator without onlyCurrentGI (#206, PR #211). The team needs to decide explicitly which of the four remaining 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 ✓ Done — PR #211
2	Record testnet parameter values in .env.example	#155
3	Triage security findings: fix-before-testnet vs. documented-gap	#180 #193 #194 #201 Part B
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).

[Santiagocetran]

I think both goals make sense: validating that the protocol works with technical operators and making it possible for someone to join and operate it with little help. At this stage, I agree with Robert that we should start with technical users. We’re still developing the project and the CLI is our main interface, so their feedback would help us understand what works, where people get stuck, and what needs better documentation.

A simple frontend could be useful too. I’d first validate the CLI workflows with real users and use their feedback to guide it. Having the necessary SDK operations available also seems like a cleaner foundation than wrapping CLI commands. Those parts could move forward alongside the tests, without waiting for the entire SDK to be finished.

One way I could help is by running a small local testnet at home with three notebooks and a Raspberry Pi 5. Depending on resource requirements and what the setup supports, we could run multiple containerized participants per machine, with separate wallets and state. That would let us test more participants than physical devices, while keeping in mind that they share hardware and a home network and don’t replace independent external testers.

I could approach it like my onboarding walkthrough in #79: follow the documented setup and record issues, workarounds, and where I need help, building on my Pi tests in #190. Would that be useful for this validation stage?

[robertocarlous]

I think both goals make sense: validating that the protocol works with technical operators and making it possible for someone to join and operate it with little help. At this stage, I agree with Robert that we should start with technical users. We’re still developing the project and the CLI is our main interface, so their feedback would help us understand what works, where people get stuck, and what needs better documentation.

A simple frontend could be useful too. I’d first validate the CLI workflows with real users and use their feedback to guide it. Having the necessary SDK operations available also seems like a cleaner foundation than wrapping CLI commands. Those parts could move forward alongside the tests, without waiting for the entire SDK to be finished.

One way I could help is by running a small local testnet at home with three notebooks and a Raspberry Pi 5. Depending on resource requirements and what the setup supports, we could run multiple containerized participants per machine, with separate wallets and state. That would let us test more participants than physical devices, while keeping in mind that they share hardware and a home network and don’t replace independent external testers.

I could approach it like my onboarding walkthrough in #79: follow the documented setup and record issues, workarounds, and where I need help, building on my Pi tests in #190. Would that be useful for this validation stage?

Thank you for this @Santiagocetran
The Pi run is exactly what we need before external onboarding. it's lower stakes than a real external tester and produces the same kind of signal: where does the documented path break, what needs a workaround, what's missing from the guide. The #79 format is right.

Two things need to land before that run is viable. BL-27 means model owner deploy currently fails against the foundry ABIs, no task contracts, no GI to participate in. BL-28 means registration slots accumulate permanently without releaseGIRegistrationSlots. Both are on the list in this discussion. Once those are fixed and the testnet parameters are committed (#155), the Pi setup should be able to get through a full GI end-to-end.

On the frontend, agreed on the SDK-over-CLI-wrapper point. Option C in the discussion is the same logic, build on dind's HTTP layer rather than shelling out to the CLI. The constraint is that dind isn't merged to develop yet, so it's gated on P4. Worth revisiting after the first internal GI, when we have a clearer picture of what the frontend actually needs to show.

The Pi run is the right next step once BL-27/BL-28 and #155 are resolved. Happy to coordinate on what to record the staking flow, GI registration, the commit-reveal windows, and any place where the docs say one thing and the CLI does another are the highest-value items to capture.

[Santiagocetran]

Thanks, Robert! That makes sense, and the points you mentioned sound like a good starting checklist.

For the full run, I’d follow the documented setup once BL-27/BL-28 are fixed and the parameters from #155 are recorded. I’d keep the same approach as #79: what worked, where I got stuck, any workarounds, and where I needed help, paying particular attention to staking, GI registration and the commit-reveal windows.

It would be useful to coordinate the setup with you before starting. Which branch and network should we target, and what would be the smallest model and participant mix for a complete GI? That would help me work out how to distribute the roles across the notebooks and Pi, within what the hardware can handle.

[robertocarlous]

Thanks, Robert! That makes sense, and the points you mentioned sound like a good starting checklist.

For the full run, I’d follow the documented setup once BL-27/BL-28 are fixed and the parameters from #155 are recorded. I’d keep the same approach as #79: what worked, where I got stuck, any workarounds, and where I needed help, paying particular attention to staking, GI registration and the commit-reveal windows.

It would be useful to coordinate the setup with you before starting. Which branch and network should we target, and what would be the smallest model and participant mix for a complete GI? That would help me work out how to distribute the roles across the notebooks and Pi, within what the hardware can handle.

Here are the specifics.

Branch and network: Target develop once BL-27/BL-28 are resolved. For the first run, use local (Anvil via ./foundry/anvil.sh) removes the dependency on Sepolia ETH and faucets, and lets you iterate faster on the protocol flow. Once it completes cleanly on local, a repeat on sepolia_op_devnet (Optimism Sepolia) is the actual testnet validation.

Minimum participant mix for a complete GI: one model owner, two T1 aggregators (you need at least two to form a sub-batch for commit-reveal), one T2 aggregator, two auditors (you need at least two for a median score during evaluation), and one client submitting a local model update. That's six roles across seven wallets. You can run multiple containerized roles per machine model owner and client are lightweight and can share a machine with something else; aggregators are the ones that need the most memory for weights. A reasonable split across three notebooks + Pi would be:

Notebook 1: model owner + T2 aggregator
Notebook 2: T1 aggregator A + auditor A
Notebook 3: T1 aggregator B + auditor B
Pi: client

I am happy to walk through the exact dincli command sequence end-to-end before you start once BL-27/BL-28 have PRs open I can pull the updated constructors and verify the deploy path is clean.

[Santiagocetran]

Thanks, Robert! That gives me a much clearer starting point. We can use that layout as a starting plan and confirm the model and commands once the fixes are ready. Starting locally with Anvil before moving to Sepolia makes sense.

[Abidoyesimze]

On the frontend question — I don't think we need one for this cohort.

The validator profile we're targeting already assumes CLI comfort, people who've run a validator before and are fine with Docker Compose. A frontend doesn't really solve a problem that group has, it's more for the broader launch after this one.

We also don't have real feedback from validators yet to design against. Section 4 is literally asking this cohort to surface doc/UX friction, so building a frontend before we know what that friction actually is just means guessing at it.

My take: keep this cohort CLI-only, get the operator guide done, run through one real GI, then revisit the frontend question once we've actually debriefed the first validator or two. If we do build something later I'd lean toward B over C, but that's a call for later once we have real feedback in hand.