Create a shared introduction for potential testnet partners #158

Activity

1. Santiagocetran

   added

   documentationImprovements or additions to documentationImprovements or additions to documentation

   on Sep 21, 2026
2. umeradl commented on Sep 24, 2026

   

   umeradl

   on Sep 24, 2026

   Member

   More actions

   Thanks @Santiagocetran. Agreed, this needs its own document, and so does #157. Both docs should be written and reviewed together by @abrahamnash, @umeradl and @Santiagocetran. Here is a first outline for this one. The companion outline for #157 ("what can be trained on DIN") is here. The two should link to each other: this doc is the "why and how to take part" entry point, and #157 is the "is my training project a fit" deep dive.

   Owners / reviewers: @abrahamnash (vision, policy positions, final sign-off before external sharing), @umeradl (technical accuracy, what actually works on the network), @Santiagocetran (partner framing, input from ongoing conversations, draft).

   Proposed doc outline: DIN testnet partner introduction

   Proposed location: Documentation/public/partner-introduction.md, kept short (2–3 pages), with links to the detailed guides.

   1. What DIN is, in one paragraph. A decentralized federated-learning network. Raw data never leaves participants' devices. Only model updates (on IPFS) and coordination state (on-chain) are shared. Training, auditing and aggregation are done by independent participants who have staked DIN and can be slashed for misbehaving.
   2. Why a community might want to take part.
      • Train models on data that can't be pooled (privacy, regulation, ownership).
      • Help shape the protocol at an early stage.
      • Be an early participant ahead of the fair-launch token distribution. (Wording to be confirmed by Abraham; see item 7.)
   3. Ways to contribute.
      • Run a node: client (trains on local data), auditor (scores submissions), aggregator (combines models).
      • Bring a training project as a model owner: your model, dataset and scoring. See the Clarify what can be trained on DIN and how to bring a dataset #157 doc for what can be trained.
      • Contribute data as a client in someone else's model.
      • Help with development: protocol, CLI, docs, testing. See Developer/CONTRIBUTING.md.
   4. What participants need.
      • Hardware per role: baseline for the MNIST example, and how it scales with model size. (Needs measured numbers.)
      • Time commitment: availability during Global Iteration phases, since phases are opened and closed by the model owner.
      • Setup: Python ≥3.12, dincli, a wallet/keystore, test ETH on Optimism Sepolia, IPFS access. Links to getting-started.md, wallet-setup.md, ipfs.md.
      • Costs: testnet gas (test ETH only), DIN obtained by depositing test ETH, the validator stake (MIN_STAKE), and model registration fees (open-source vs. proprietary). No real money on testnet. (Values pending Decide and set testnet tokenomics parameters: mintCap, dinPerEth, and DinEmission values #155.)
   5. How it works for a partner, step by step. Which role you pick decides your path: onboarding → register wallet → stake (validators) → join a model's GI → earn rewards or get slashed. Links to din-workflow.md and model-workflow.md.
   6. Support and the limits of an experimental testnet.
      • Support: contact point, Discord/GitHub, onboarding calls. (Channel and owner to be decided.)
      • Limitations: contracts are not yet audited; parameters can change; possible bugs and downtime; only the MNIST reference is tested end to end.
      • Security: keystore handling. Model service code is only run after DIN DAO approval of the model registration and of every manifest update.
   7. Confirmed vs. still undecided. This is a table where every row is labeled ✅ confirmed / 🟡 proposed / ❓ open:
      • Fees: registration and update fees, and fee routing to the treasury.
      • Rewards: emission schedule and per-GI rewards. (Pending Decide and set testnet tokenomics parameters: mintCap, dinPerEth, and DinEmission values #155.)
      • Slashing: what gets slashed and the default fractions. (Pending Decide and set testnet tokenomics parameters: mintCap, dinPerEth, and DinEmission values #155.)
      • Future token distribution: the fair-launch direction. DIN goes to validators and active participants, with no ICO, pre-sale or VC allocation, using Merkle-drop claims with cliff and linear vesting (BL-18 / start fair-launch token distribution #75). How eligibility is computed is still open.
      • Testnet resets: whether balances, stakes and models carry over between testnet versions, and whether testnet participation counts toward fair-launch eligibility.
   8. Next step / contact. One clear call to action: who to contact, and what happens after (onboarding call → role selection → guided setup).

   Open questions for the three of us

   • Which items in section 7 can be stated as confirmed now, and which must stay marked open? Friday's Decide and set testnet tokenomics parameters: mintCap, dinPerEth, and DinEmission values #155 meeting should settle most of the tokenomics rows.
   • What exactly can we say about fair-launch eligibility and testnet resets without over-promising?
   • Who is the named contact / support channel for partners?
   • Do we have measured hardware numbers per role, or do we state MNIST-only baselines for now?

   Draft the doc against this outline, then review it jointly before anything goes out externally.
3. umeradl

   added a parent issue on Sep 25, 2026

   • Testnet readiness: tracking what must be in place before testnet opens #166
4. umeradl

   assigned

   umeradl

   ,

   Santiagocetran

   and

   abrahamnash

   on Sep 25, 2026
5. Santiagocetran commented on Sep 28, 2026

   

   Santiagocetran

   on Sep 28, 2026

   CollaboratorAuthor

   More actions

   I added the first draft of the partner introduction to draft PR #189, alongside the companion guide for #157. The two pages now link to each other.

   The introduction is written for a potential partner: ways to participate, what a trial requires, how to get started, and a table separating current code from decisions still open. It does not promise rewards, future token eligibility, or testnet state carrying over. I used the contact email already published in the repository README as the initial call to action; this needs confirmation before external sharing.

   @abrahamnash — could you review the public positioning, contact route, and fair-launch/testnet-reset wording for final sign-off? @umeradl — could you check the DevNet 2.0 scope, role requirements, fees, slashing, and rewards language? Issue #155 remains open for tokenomics values, and #75 remains open for fair-launch eligibility.
6. umeradl commented on Oct 7, 2026

   

   umeradl

   on Oct 7, 2026

   Member

   More actions

   Done by PR No. 189, merged into develop as e02db6d with no follow-up commit (outcome). I'm closing this by hand: a merge into develop doesn't trigger closing keywords, because main is the default branch.

   Checked on origin/develop @ e02db6d. The new page is Documentation/public/partner-introduction.md ("Explore DIN with your community"), linked from Documentation/README.md and from the companion page for issue No. 157:

   • What DIN is and why a community might take part: the opening paragraph and "Why take part?". It explicitly makes no promise of income, a token allocation or a model result.
   • Ways to contribute: the roles table (client, auditor, aggregator, model owner, developer or tester), plus the validator staking note.
   • What participants need (hardware, time, costs): "What would your team need?" covers time per round, the Model_0-only hardware figures, setup, test tokens, minimum stake, and the fact that fees are paid in test ETH.
   • Support and limits of an experimental testnet: the scope callout, the closing paragraph of the settled-vs-undecided section (bugs, resets, no production audit, registry approval plus inspecting code yourself), and Discussion No. 102 for testing questions.
   • Confirmed vs. undecided on fees, rewards, token distribution and resets: the "What is settled, and what is still being decided?" table. Rewards and slashing values point to issue No. 155, and distribution eligibility points to issue No. 75 (BL-18 fair launch: no ICO, pre-sale or VC allocation). Resets are marked open.
   • Reviewed, with a clear contact: "Start a conversation" uses the README contact email. Abraham signed off on the vision, contact and policy wording on PR No. 189, and the technical claims were checked against foundry/src/ in the PR review.
   • Verification: check_doc_links.py Documentation resolves all 182 links on the merged tree; the PR's CI is green.

   Out of scope, as the body says: the internal outreach checklist (not tracked in an issue yet), and partnership terms or reward policy, which stay with issues No. 155 and No. 75.
7. umeradl

   closed this as completedon Oct 7, 2026
8. umeradl commented on Oct 7, 2026

   

   umeradl

   on Oct 7, 2026

   Member

   More actions

   Follow-up: the internal outreach checklist this issue left out of scope is now tracked in issue No. 239.