From 50db085e301c6da7d1545fc5ca8389d490c446b1 Mon Sep 17 00:00:00 2001 From: santiagocetran Date: Mon, 28 Sep 2026 14:19:38 -0300 Subject: [PATCH 1/3] docs: explain what can be trained on DIN --- Documentation/README.md | 1 + Documentation/public/getting-started.md | 2 + Documentation/public/what-can-be-trained.md | 56 +++++++++++++++++++++ 3 files changed, 59 insertions(+) create mode 100644 Documentation/public/what-can-be-trained.md diff --git a/Documentation/README.md b/Documentation/README.md index 160a48d..bfddef8 100644 --- a/Documentation/README.md +++ b/Documentation/README.md @@ -14,6 +14,7 @@ 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 be trained 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 | | [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 index 4be5d1e..f60ed1b 100644 --- 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 be trained 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/what-can-be-trained.md b/Documentation/public/what-can-be-trained.md new file mode 100644 index 0000000..5aa89c0 --- /dev/null +++ b/Documentation/public/what-can-be-trained.md @@ -0,0 +1,56 @@ +# What can I train on DIN? + +DIN is designed to let a group of people train a shared AI model while keeping their training data on their own devices. Clients train locally, auditors check the results, and aggregators combine the accepted updates into a new shared model. + +> **Which version does this describe?** This page covers DevNet 2.0 as represented by the code on the `develop` branch. The [Model_0 getting-started guide](getting-started.md) describes the current public example on Optimism Sepolia, which may differ from DevNet 2.0. + +## The short answer + +**Many kinds of models can fit DIN, but bringing a new one takes some setup.** DIN does not require a particular model architecture or framework. The model owner supplies the code that tells participants how to train, check, and combine updates. The size of the model is mainly limited by the devices and network connections of the people running it. + +The **MNIST handwritten-digit model** is the end-to-end example tested in this repository. If you want to train a different model or use a different dataset, you will need to adapt and test that example's workflow. DIN does not yet offer a one-click way to upload any model and start training it. + +| Your idea | Where to start | +|---|---| +| Train a model on similar data held by different people, such as images or rows with the same fields | This is closest to the tested MNIST example. You will need your own model, data preparation, and evaluation code. | +| Train a tabular, language, or other model | Potentially possible with custom code. Test the full training and evaluation workflow before inviting participants. | +| Fine-tune a large language model | A possible approach is to share small adapter updates rather than the full model. This has **not** been tested end to end on DIN; participants would still need access to the base model and suitable hardware. | +| Train when participants can submit at any time | DIN currently works in rounds with scheduled stages, so a fully asynchronous project would need further development. | + +The same principle applies to frameworks and training methods: the reference uses PyTorch, while TensorFlow, scikit-learn, JAX, and other Python tools may be usable through custom services. Methods for personalized training, different device sizes, or participants holding different features are possibilities to design and test, not ready-made options. + +## What would I need to bring? + +You, as the **model owner**, would prepare: + +1. **A model and a clear task.** Define what participants are trying to predict or learn, how their data should be prepared, and what a useful result looks like. +2. **Local training code.** Participants called *clients* run this code with their own training data. For the tested example, raw client training data stays on their devices; you should check that your own code behaves the same way. +3. **A separate test dataset and a way to score results.** Participants called *auditors* use test data provided by the model owner to check submitted models. The score should make sense for your task: an image-classification score may not make sense for a regression or language model. +4. **Code to combine updates.** Participants called *aggregators* turn accepted local results into the next shared model. +5. **People and resources to run the task.** You need available clients, auditors, and aggregators, plus enough computing power and storage for the model. Model files are transferred through IPFS, so larger files also mean more upload, download, and storage work. + +DIN calls the model-specific Python files **services**. It also uses a **manifest** to tell participants where to find those files, their dependencies, and other task information. The [services guide](services.md) and [manifest guide](manifest.md) explain the details when you are ready to build. + +## How does a training round work? + +1. The model owner publishes a starting model and opens a training round. +2. Clients train on their local data and submit model updates. +3. Auditors test the submissions using evaluation data from the model owner. +4. Aggregators combine accepted updates into a new shared model. +5. The model owner checks the new model and can start another round. + +The model owner moves the task through these stages, so participants need to be available at the right times. The exact training, scoring, and combining rules come from the model's services. See the [model workflow](workflows/model-workflow.md) for the full sequence. + +## What should I check before starting? + +- **Fit:** Can your project use rounds of local training, checking, and combining results? Start with the [MNIST example](guides/client-onboarding.md) to see the tested path. Its image format and settings are specific to that example. +- **Resources:** Can the participants' devices train, evaluate, or combine your model? The system requirements in [Getting Started](getting-started.md) apply only to Model_0. Measure the needs of your own model. +- **Data and privacy:** Clients can keep raw training data locally, but submitted model updates and other task files are shared. Check what your services send and who can access the evaluation data. Optional [differential privacy settings](../technical/services/clients.md#manifest-driven-dp-configuration) exist in the reference client service, but are off by default and need careful review before making privacy promises. +- **People:** Arrange enough clients, auditors, and aggregators to participate. DIN can show registered models, but the model owner still needs to help people discover the task and join it. +- **Costs:** Allow for transaction fees, model-registration fees, IPFS storage and transfers, participant hardware, and staking by validators. Registration fees differ for open-source and proprietary models and can change; see the [model-owner guide](roles/model-owner.md) before budgeting. + +## How do I try it? + +If you are new to DIN, follow [Getting Started](getting-started.md) to try the MNIST example first. To bring your own model, use the [model-owner guide](roles/model-owner.md) and [services guide](services.md) to prepare and test your task. A new model must be reviewed before it appears in the registry; later changes to its manifest also require approval. Participants should review the code they are asked to run. + +If you are exploring a project with the team, share the model type, the kind and size of data held by each participant, how you would measure success, your expected number of participants, and any hardware or privacy constraints. Those details make it possible to assess the work needed for a first training round. For a broader introduction to collaborating with DIN, see the [partner-introduction discussion](https://github.com/InfiniteZeroFoundation/DevNet/issues/158). From 51cb27a74db300dbd2012c6157dd14c234cb9729 Mon Sep 17 00:00:00 2001 From: santiagocetran Date: Mon, 28 Sep 2026 14:31:49 -0300 Subject: [PATCH 2/3] docs: introduce DIN to potential testnet partners --- Documentation/README.md | 1 + Documentation/public/partner-introduction.md | 55 ++++++++++++++++++++ Documentation/public/what-can-be-trained.md | 2 +- 3 files changed, 57 insertions(+), 1 deletion(-) create mode 100644 Documentation/public/partner-introduction.md diff --git a/Documentation/README.md b/Documentation/README.md index bfddef8..1a56400 100644 --- a/Documentation/README.md +++ b/Documentation/README.md @@ -15,6 +15,7 @@ Documentation for the DIN Protocol DevNet as implemented on the `develop` branch |---|---| | [Getting Started](public/getting-started.md) | Onboarding guide for Model_0 on the live devnet (`sepolia-op-devnet`) | | [What can be trained 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/partner-introduction.md b/Documentation/public/partner-introduction.md new file mode 100644 index 0000000..f356c5d --- /dev/null +++ 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 fees; 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 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). diff --git a/Documentation/public/what-can-be-trained.md b/Documentation/public/what-can-be-trained.md index 5aa89c0..113f70c 100644 --- a/Documentation/public/what-can-be-trained.md +++ b/Documentation/public/what-can-be-trained.md @@ -53,4 +53,4 @@ The model owner moves the task through these stages, so participants need to be If you are new to DIN, follow [Getting Started](getting-started.md) to try the MNIST example first. To bring your own model, use the [model-owner guide](roles/model-owner.md) and [services guide](services.md) to prepare and test your task. A new model must be reviewed before it appears in the registry; later changes to its manifest also require approval. Participants should review the code they are asked to run. -If you are exploring a project with the team, share the model type, the kind and size of data held by each participant, how you would measure success, your expected number of participants, and any hardware or privacy constraints. Those details make it possible to assess the work needed for a first training round. For a broader introduction to collaborating with DIN, see the [partner-introduction discussion](https://github.com/InfiniteZeroFoundation/DevNet/issues/158). +If you are exploring a project with the team, share the model type, the kind and size of data held by each participant, how you would measure success, your expected number of participants, and any hardware or privacy constraints. Those details make it possible to assess the work needed for a first training round. For a broader introduction to collaborating with DIN, see [Explore DIN with your community](partner-introduction.md). From 2d3c3bec95a935b61b0ce2bae8d6456dd062f11d Mon Sep 17 00:00:00 2001 From: Santiagocetran <108505846+Santiagocetran@users.noreply.github.com> Date: Mon, 5 Oct 2026 15:11:37 -0300 Subject: [PATCH 3/3] docs: address model-fit and partner guide review feedback --- Developer/design/MECHANISM_DESIGN.md | 6 +++--- Documentation/README.md | 2 +- Documentation/public/getting-started.md | 2 +- Documentation/public/partner-introduction.md | 4 ++-- Documentation/public/what-can-be-trained.md | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/Developer/design/MECHANISM_DESIGN.md b/Developer/design/MECHANISM_DESIGN.md index 4180537..17958af 100644 --- 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 index 1a56400..467d1b1 100644 --- a/Documentation/README.md +++ b/Documentation/README.md @@ -14,7 +14,7 @@ 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 be trained 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 | +| [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 | diff --git a/Documentation/public/getting-started.md b/Documentation/public/getting-started.md index f60ed1b..0767938 100644 --- a/Documentation/public/getting-started.md +++ b/Documentation/public/getting-started.md @@ -6,7 +6,7 @@ Welcome to the onboarding guide for **Model_0** on the Infinite Zero Network. -Planning a different model or dataset? Read [What can be trained on DIN?](what-can-be-trained.md) to understand the tested reference, custom-service path, and practical limits. +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`. diff --git a/Documentation/public/partner-introduction.md b/Documentation/public/partner-introduction.md index f356c5d..6630f53 100644 --- a/Documentation/public/partner-introduction.md +++ b/Documentation/public/partner-introduction.md @@ -27,7 +27,7 @@ Auditors and aggregators are **validators**. They lock DIN test tokens as a stak - **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 fees; 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. +- **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. @@ -42,7 +42,7 @@ The only end-to-end training example identified so far is Model_0, which recogni | Topic | Current position | |---|---| -| **Fees** | **In the code:** model registration and manifest updates have separate fees 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. | +| **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. | diff --git a/Documentation/public/what-can-be-trained.md b/Documentation/public/what-can-be-trained.md index 113f70c..4ed469a 100644 --- a/Documentation/public/what-can-be-trained.md +++ b/Documentation/public/what-can-be-trained.md @@ -51,6 +51,6 @@ The model owner moves the task through these stages, so participants need to be ## How do I try it? -If you are new to DIN, follow [Getting Started](getting-started.md) to try the MNIST example first. To bring your own model, use the [model-owner guide](roles/model-owner.md) and [services guide](services.md) to prepare and test your task. A new model must be reviewed before it appears in the registry; later changes to its manifest also require approval. Participants should review the code they are asked to run. +If you are new to DIN, follow [Getting Started](getting-started.md) to try the MNIST example first. To bring your own model, use the [model-owner guide](roles/model-owner.md) and [services guide](services.md) to prepare and test your task. Before registration, the DIN-Representative must authorize the model’s task coordinator and task auditor contracts as slashers; see the [model workflow](workflows/model-workflow.md). A new model must then be reviewed before it appears in the registry; later changes to its manifest also require approval. Participants should review the code they are asked to run. If you are exploring a project with the team, share the model type, the kind and size of data held by each participant, how you would measure success, your expected number of participants, and any hardware or privacy constraints. Those details make it possible to assess the work needed for a first training round. For a broader introduction to collaborating with DIN, see [Explore DIN with your community](partner-introduction.md).