Santiagocetran · Sep 28, 2026 · Sep 28, 2026 · Oct 5, 2026
diff --git a/Developer/design/MECHANISM_DESIGN.md b/Developer/design/MECHANISM_DESIGN.md
@@ -186,7 +186,7 @@ T1/T2 outputs are deterministic functions of accepted inputs ⇒ verifiable by r
 
 | Flow | Mechanism | 2.0 design |
 |---|---|---|
-| **Mint — deposit** | `depositAndMint` ETH→DIN at `dinPerEth` (exists) | ✅ **Resolved:** keep active (faucet mode) for devnet; the deposited ETH backing should route to treasury, not `owner()` withdrawal. **Cap on testnet. Retire on mainnet**, replaced by either a proper on-ramp/ICO or a validator-airdrop program rewarding testnet participants — both kept open, final model TBD. |
+| **Mint — deposit** | `depositAndMint` ETH→DIN at `dinPerEth` (exists) | ✅ **Resolved:** keep active (faucet mode) for devnet; the deposited ETH backing should route to treasury, not `owner()` withdrawal. **Cap on testnet. Retire on mainnet**, replaced by the fair-launch validator/active-participant distribution recorded in [BL-18](../BACK_LOG.md). No ICO, pre-sale, or VC allocation is in the current plan; eligibility rules and amounts remain unset. |
 | **Mint — emission** | None today | New emission contract (P3-5.2): per-GI reward subsidy, ✅ **geometric decay per epoch confirmed**, inflation guard (per-GI mint ceiling) tied to GI lifecycle events only. `MAX_SUPPLY`: ✅ **resolved as deliberately open/dynamic for now** — no hard cap at freeze time, supply governed by issuance vs. burn, hard cap possible later via governance once economics are proven. |
 | **Burn — slashing** | Accidental (stranded in stake contract) | Explicit: slashed-stake burn share (§4). |
 | **Burn — fees** | None | ✅ **Resolved:** burn a fraction of *both* on-chain protocol fees and validator network fees (dual sources, P3-5.3), start at 0%, keep the hook. Reserve a public-goods routing slot alongside `{validatorPool, treasury, burn, storage}` now even though it stays unfunded initially. |
@@ -242,13 +242,13 @@ Decisions that must be made (with owner + roadmap slot) before DevNet 2.0 contra
 5. **Emission schedule shape + MAX_SUPPLY** — ✅ **Partially resolved.** Geometric decay per epoch and a GI-lifecycle-tied inflation guard are confirmed. `MAX_SUPPLY` is deliberately left **open/dynamic for now** — no hard cap at freeze time; supply is governed by issuance vs. burn, with a hard cap possible later via governance once the economics are proven. Decay rate/epoch length numbers and the simulation bar (stable validator income at target / 10× / 0.1× participation) are unchanged from §7. Owner: Umer (design), Robbert (contract).
 6. **Per-model stake requirement bounds** — P3-5.1. Owner: Umer.
 7. **Dispute bond size & window length** — ✅ **Denomination resolved: DIN** (slashing-pattern security deposit, not a §8 validator network fee — see [`slashing-taxonomy.md`](slashing-taxonomy.md)). Size & window length still open — P3-4.3. Owner: Umer (design), Robbert (contract).
-8. **`depositAndMint` cap/retirement plan for testnet** — ✅ **Resolved.** Keep active (faucet mode) on DevNet; cap on testnet; retire on mainnet, replaced by either a proper on-ramp/ICO or a validator-airdrop program rewarding testnet participants — both kept open, final distribution model still TBD. Owner: Umer.
+8. **`depositAndMint` cap/retirement plan for testnet** — ✅ **Resolved.** Keep active (faucet mode) on DevNet; cap on testnet; retire on mainnet, replaced by the fair-launch validator/active-participant distribution recorded in [BL-18](../BACK_LOG.md). No ICO, pre-sale, or VC allocation is in the current plan; eligibility rules and amounts remain unset. Owner: Umer.
 9. **Burn policy** — ✅ **Resolved.** Burn from both on-chain protocol fees *and* validator network fees (dual sources), plus the existing slashed-stake burn share (item 1). Reserve the public-goods routing slot in the fee router now (`{validatorPool, treasury, burn, storage, publicGoods}`) even though it stays unfunded initially — see §8. Owner: Umer, P3-5.3.
 10. **White paper §46 scope items** — ✅ **Resolved.** DPoS delegation stays parked to P5+ (confirms existing default, §3). Encrypted test dataset (paper §5.2.3b) — adopt in 2.0. Test-set resampling (paper §5.2) — adopt in 2.0. Commit-then-reveal between auditors (paper §5.2) — in scope for P3 (§6 scoring hardening). Non-coin-based voting credits (DPPs) — din-dao itself is deferred to post-mainnet (2026-08-04, see [DESIGN_DECISIONS.md DD-1/DD-2](DESIGN_DECISIONS.md#dd-2--dao-voting-power-model-coin-weighted-vs-quadratic-vs-non-coin-based)), so the stance-documentation ask carries over to whenever that design work resumes; P3 still ships `onlyOwner` governance only. Owner: Umer, P3-SCR / P3-DOC7.
 11. **White paper §8.1 delegator/removal semantics** — ✅ **Resolved for 2.0:** jail/blacklist, not permanent removal (§4 jailing). Full §8.1 alignment (delegator penalties, forced re-registration) is deferred until delegation lands (item 10 / §3 open decisions).
 12. **Slashing-framework translation** — flagged, not resolved: Abraham's Ethereum-DPoS framing (double-signing, surrounding votes, 1/32 immediate penalty) is consensus-validator language that doesn't map directly onto DIN's liveness/correctness conditions (S1–S6 above). Needs a translation pass before it's a drop-in spec for item 2, not just a restatement of Ethereum's numbers.
 13. **`dinPerEth` rate-setting authority** — not resolved, and not previously tracked as a numbered decision here: today it's a bare `owner()`-settable admin parameter with no formula, peg target, or DAO gate ([issues/tokenomics.md](../issues/tokenomics.md) Gap 1). §9-8 resolves the faucet's *lifecycle* (active → capped → retired) but not who sets the rate or by what rule while it's active on DevNet/testnet. Owner: Umer.
-14. **ICO / token-sale mechanics** — not resolved. §9-8 names "a proper on-ramp/ICO" as one of two options for replacing the faucet at mainnet retirement, but nothing defines quantity offered, pricing mechanism, the operating/legal entity, or KYC posture if that branch is chosen over the validator-airdrop alternative. Distinct from `MAX_SUPPLY` (item 5, which is about total possible supply, left open/dynamic) — this is about how any one distribution event would actually run. Owner: TBD (Abraham/Umer).
+14. **ICO vs. validator distribution** — ✅ **Resolved in favor of the fair-launch validator/active-participant path.** [BL-18](../BACK_LOG.md) records Abraham’s Jul 31, 2026 decision: no ICO, pre-sale, or VC allocation. Eligibility rules and amounts remain unset; [issue #75](https://github.com/InfiniteZeroFoundation/DevNet/issues/75) tracks the distribution work. This does not guarantee testnet participants an allocation or resolve `MAX_SUPPLY` (item 5).
 
 ---
 

diff --git a/Documentation/README.md b/Documentation/README.md
@@ -14,6 +14,8 @@ Documentation for the DIN Protocol DevNet as implemented on the `develop` branch
 | Document | Purpose |
 |---|---|
 | [Getting Started](public/getting-started.md) | Onboarding guide for Model_0 on the live devnet (`sepolia-op-devnet`) |
+| [What can I train on DIN?](public/what-can-be-trained.md) | DevNet 2.0 model fit, custom services, practical limits, and the path to trying a new task |
+| [Explore DIN with your community](public/partner-introduction.md) | A short introduction for groups considering a testnet trial |
 | [Setup Guide](public/setup.md) | Installing and configuring `dincli`: venv, wallet, network, logging, demo mode, IPFS |
 | [CLI Reference](public/cli-reference.md) | Common `dincli` reference across all roles |
 | [Manifest](public/manifest.md) | The per-model `manifest.json`: metadata, services, contract addresses |

diff --git a/Documentation/public/getting-started.md b/Documentation/public/getting-started.md
@@ -6,6 +6,8 @@
 
 Welcome to the onboarding guide for **Model_0** on the Infinite Zero Network.
 
+Planning a different model or dataset? Read [What can I train on DIN?](what-can-be-trained.md) to understand the tested reference, custom-service path, and practical limits.
+
 Infinite Zero Network devnet has been launched as `sepolia-op-devnet`.
 
 Model_0 is the first active model registered on the Infinite Zero Network and serves as the pioneer deployment of Infinite Zero's  model-specific smart contracts.

diff --git a/Documentation/public/partner-introduction.md b/Documentation/public/partner-introduction.md
@@ -0,0 +1,55 @@
+# Explore DIN with your community
+
+DIN is an experimental network for training shared AI models across different people and organizations. In its reference workflow, contributors train on their own devices and share model updates, while independent participants check and combine those updates. This can help a community learn from data held in different places without collecting everyone's raw training data in one place. A project's own code and data handling still need review: model updates can reveal information, and keeping raw data local is not an automatic privacy guarantee.
+
+> **Current scope:** This page describes DevNet 2.0 as represented by the code on `develop`. The [Getting Started guide](getting-started.md) covers the current public Model_0 example on Optimism Sepolia, which may differ. DIN is an experimental testnet project; participation terms and parameters can change.
+
+## Why take part?
+
+Your community may have a model it wants to improve using data that members cannot or do not want to pool. You may also want to test how shared training works, help improve the tools, or give feedback while the network is still taking shape. The [guide to what can be trained](what-can-be-trained.md) explains which path has been tested and what a new project would need to build.
+
+Participation is an opportunity to experiment and contribute. It is **not** a promise of income, a future token allocation, or a particular model result.
+
+## Ways to participate
+
+| Your role | What you would do |
+|---|---|
+| **Client** | Train a model on your local data and submit a model update. You can contribute to an existing project without starting one yourself. |
+| **Auditor** | Evaluate submitted models using test data supplied for the project. |
+| **Aggregator** | Combine accepted updates into a new shared model. |
+| **Model owner** | Bring a training project, prepare the model and evaluation method, and coordinate its training rounds and participants. |
+| **Developer or tester** | Improve the protocol, command-line tools, documentation, or tests. See [Contributing](../../Developer/CONTRIBUTING.md). |
+
+Auditors and aggregators are **validators**. They lock DIN test tokens as a stake and can lose part of it if they fail certain duties. Clients do not need to stake to train in the reference workflow. A person or organization can take more than one role, using separate accounts where the workflow requires them.
+
+## What would your team need?
+
+- **Time during a training round.** The model owner opens and closes each stage. Clients, auditors, and aggregators need to be available when their stage is active; this is not yet a hands-off service with a guaranteed schedule.
+- **A computer suited to the project.** The tested handwritten-digit example lists a standard CPU, 4 GB RAM, and about 30 GB of disk space. These are **Model_0-only starting figures**, not requirements for every project. Larger models may need far more memory, storage, computing power, and network bandwidth. See [Getting Started](getting-started.md).
+- **Basic setup.** Participants use Python 3.12 or later, the `dincli` command-line tool, a wallet, and access to IPFS for model files. The current public Model_0 example uses Optimism Sepolia test ETH for transactions; confirm the network details for any new trial. Start with [Setup](setup.md), [Wallet Setup](guides/wallet-setup.md), and [IPFS Setup](guides/ipfs.md). Use an encrypted keystore and review any project-provided code before running it.
+- **Test tokens and operating costs.** Validators obtain DIN test tokens by depositing test ETH and must meet the current minimum stake. Model owners pay registration and manifest-update fees in test ETH; open-source and proprietary projects have different fees. Blockchain transactions use test ETH. The token and fee values can change, and running hardware or storage can have real costs. Check the [role guides](roles/model-owner.md) and current network values before committing resources.
+
+The only end-to-end training example identified so far is Model_0, which recognizes handwritten digits. A new model or dataset needs project-specific training, scoring, and aggregation code and a full trial run. [What can I train on DIN?](what-can-be-trained.md) walks through that fit check.
+
+## From interest to a first training round
+
+1. **Choose your role and project.** Join an existing model as a client, auditor, or aggregator, or describe a project you want to bring as a model owner.
+2. **Discuss the trial.** Share your model goal, the kind of data contributors hold, the people and devices available, and any privacy constraints. Confirm who will coordinate the round and support onboarding.
+3. **Set up and test.** Follow the guides for your role, prepare a wallet and test tokens, and try the Model_0 path before running a new project. Validators must stake before joining their role's registration stage.
+4. **Join a round.** The model owner schedules the stages; clients train, auditors check submissions, and aggregators produce the next model. The [model workflow](workflows/model-workflow.md) has the full sequence.
+
+## What is settled, and what is still being decided?
+
+| Topic | Current position |
+|---|---|
+| **Fees** | **In the code:** model registration and manifest updates have separate fees, paid in test ETH, for open-source and proprietary projects. The amounts can be changed. Fee-routing code exists; check the selected deployment before assuming a particular destination for payments. |
+| **Validator rewards** | **Not yet a reliable participation promise:** reward and emission mechanisms exist in the code, but the testnet schedule and amounts are still being set in [issue #155](https://github.com/InfiniteZeroFoundation/DevNet/issues/155). Do not budget for a particular payout. |
+| **Slashing** | **In the code, with parameters under review:** auditors and aggregators can lose stake for specified failures. The exact fractions and other testnet settings are still being reviewed in [issue #155](https://github.com/InfiniteZeroFoundation/DevNet/issues/155). Review the rules for your model before staking. |
+| **Future token distribution** | **Direction, not an offer:** the team is developing a fair-launch distribution for validators and active participants, with no ICO, pre-sale, or VC allocation in the current plan. A claim contract exists, but eligibility rules and amounts have not been set; see [issue #75](https://github.com/InfiniteZeroFoundation/DevNet/issues/75). Testnet participation does **not** currently guarantee eligibility. |
+| **Testnet resets** | **Open:** whether balances, stakes, models, or participation records carry over between testnet versions has not been confirmed. Treat testnet assets and state as temporary. |
+
+The network is still experimental. Bugs, interruptions, changed parameters, and resets are possible. The current code and example do not establish a production security audit or guarantee that model-owner code is safe. New models and manifest changes pass a registry approval step before they take effect, but participants should still inspect the code and dependencies they run.
+
+## Start a conversation
+
+If your community wants to try DIN, [email the team](mailto:abrahamnash@protonmail.com). Say which role interests you, what kind of project or data you have, how many people may participate, and any hardware or privacy constraints. This gives the team a starting point for discussing a suitable trial. You can explore the public [Getting Started guide](getting-started.md) in the meantime. For bugs or questions while testing DevNet 2.0 code, use the separate [pre-launch discussion](https://github.com/InfiniteZeroFoundation/DevNet/discussions/102).