Model Owner
The Model Owner is the actor who brings a model to the network and runs its training from start to finish. They deploy the model's Task Contracts, define its logic through the manifest and service files, seed it with a genesis model, and orchestrate every Global Iteration — opening and closing each phase that Clients, Auditors, and Aggregators act within.
🚧 This wiki describes DevNet 2.0, soon to be launched. It follows the contracts and
dinclion thedevelopbranch; the currently running DevNet may still use older contracts and commands. Pre-launch discussion: #102.
The Model Owner brings a model to the network and runs its training from start to finish. They:
- deploy the model's Task Contracts;
- define its logic through the manifest and service files;
- seed it with a genesis model;
- fund each round's reward pool;
- run every Global Iteration, opening and closing each phase that Clients, Auditors and Aggregators work in.
The role is deliberately powerfulhas a lot of power within its own model and powerlessnone outside it:. aA model owner drivesruns their model's lifecycle and can triggertriggers slashing of its misbehaving validators,. bBut admission to the network itself is gated by the DIN-Representative, and validator stakes live in the shared platform contracts, and the owner is held to account too: an owner who publishes bad test data loses part of the reward pool.
Onboarding a model
A one-time setup path, in this order:
-
Deploy the task contracts —
dincli model-owner deploy task-coordinator/task-auditor, one pair per model. -
Request slasher authorization — ask the DIN-Representative (off-chain, via the official channels) to authorize both contracts as slashers on
DinValidatorStake; then confirm the authorization on the task side (dincli model-owner add-slasher). -
Deploy the task contracts.
dincli model-owner deploy task-coordinator, thendincli model-owner deploy task-auditor: one pair per model. The second command also links the auditor to the coordinator.⚠️ The DevNet 2.0 contracts take amodelIdconstructor argument thatdincli model-owner deploydoesn't pass yet. See the known gap on Task Contracts. -
Get slasher authorization. Ask the DIN-Representative, off-chain through the official channels, to authorize both contracts as slashers on
DinValidatorStake. Then confirm each on the task side, one at a time:dincli model-owner add-slasher --taskCoordinator dincli model-owner add-slasher --taskAuditor
-
Write the manifest
&and service files. These hold the model's architecture androlethe logic for each role (model.py,modelowner.py,client.py,auditor.py,aggregator.py). They are pinned to IPFS and referenced by CID inmanifest.json. This is where the model owner's ML expertise lives; the protocol onlynever seesthe code, only itsCIDs. See Manifest and Services. -
Create & submit the genesis model — the initial weights every client starts from (
dincli model-owner model create-genesis/submit-genesis); its score against the owner's test dataset sets the eligibility threshold for local models. -
Request model registration — submit a registration request to
DinModelRegistry(open-source or proprietary, with the corresponding fee); the DIN-Representative approves and the model receives its model ID. -
Create and submit the genesis model. These are the starting weights every client trains from:
dincli model-owner model create-genesis-model dincli model-owner model submit-genesis-model
-
Request model registration. Submit a request to
DINModelRegistryand pay the matching fee:dincli task model-owner register-request [--isOpenSource]. Once the DIN-Representative approves it, the model receives its model ID.
Registration fees
Fees are charged on submission (approved or rejected — spam protection) and held by the registry for the ecosystem:
Fees are charged when a request is submitted and are kept whether it is approved or rejected, which protects against spam. An overpayment is refunded. The DIN-Representative later sweeps collected fees to DinFeeRouter.
Running a Global Iteration
Once registered, training proceeds in GIs, each producing a new global model. The model owner is the conductor: every phase is opened and closed by their explicit command, and participants can only actact only while their phase is open.
| Phase | Model owner's job |
|---|---|
| Start GI |
gi start — optionally setting the local-model score threshold (defaults to 5% below the latest global model's accuracy) |
| Registration | open/close the aggregator and auditor registration windows |
| LMS | open/close the window in which clients submit trained local models |
| Auditor assignment | create audit batches and generate/submit the test dataset auditors evaluate against |
| Evaluation | start/close the scoring phase, review results per auditor and per model |
| Aggregation | create T1/T2 batches, start/close Tier-1 and Tier-2 aggregation |
| Slash & end | trigger slashing of non-compliant auditors and aggregators, then gi end — the finalized T2 output becomes the next GI's starting model |
| Phase | Model owner's job (dincli model-owner …) |
|---|---|
| Fund | Fund the GI's reward pool in DIN (depositRewards on the auditor contract; no dincli command yet). The GI can't start without it |
| Start GI |
gi start <id>: sets the pass score to the latest global model's accuracy minus a threshold (--threshold, the manifest's audit_scoring_policy, or 5 by default) |
| Registration |
gi reg aggregators-open/close, then gi reg auditors-open/close
|
| LMS |
lms open / lms close, the window in which clients submit trained local models |
| Audit batches |
auditor-batches create (waits for and locks the audit seed), then auditor-batches create-testdataset --submit. This encrypts the test data for each batch's auditors and adds the owner's encryption key to the manifest, which must be re-uploaded |
| Evaluation |
lms-evaluation start (auditors commit) → lms-evaluation start-reveal (auditors reveal) → lms-evaluation close. Review results with lms-evaluation show
|
| Aggregation |
aggregation create-t1nt2-batches, then for each of T1 and T2: aggregation T1 start → aggregation T1 start-reveal → aggregation T1 close (and the same with T2) |
| Slash & end |
slash auditors, then slash aggregators, then gi end. Ending settles the reward pool, and the finalized T2 output becomes the next GI's starting model |
Forgetting a start-reveal step stalls the GI in its commit window, because finalizing reverts. It doesn't corrupt any state.
Monitoring commands (show-statedincli task gi show-state, show-modelslms show-models, show-t1-batchesaggregation show-t1-batches, …) give a live view at every step.
Accountability and other owner duties
-
Test-data disputes. An auditor who can't decrypt or verify its batch's test data can open a dispute. The owner must answer within the window (about one day) by revealing the dataset key.
- Silence or a wrong key: the dispute is upheld. 25% of the GI's reward pool is forfeited (unless the GI settled while the dispute was open) and the batch must be reassigned.
- Aggregation disputes. The owner adjudicates disputes that validators raise against finalized aggregation results.
-
Encryption key.
create-testdatasetuses the owner's X25519 key, kept in thedincliconfig directory (owner_x25519.key). -
Contract-only actions. These have no
dinclicommand yet:- funding rewards;
-
setDinToken(on both contracts); - resolving disputes;
-
releaseGIRegistrationSlots; - tuning slashing fractions, the reward split and dispute parameters.
What the model owner provides vs. what the network provides
| Model owner brings | Network provides |
|---|---|
| Model architecture & training logic (service files) | Sandboxed execution of that logic on participants' machines |
| Genesis model & test datasets | Clients' private data (never shared — only trained weights return) |
| Phase orchestration each GI | Staked, slashable validators to audit and aggregate honestly |
| Registration & update fees | Registry, staking, and settlement infrastructure |
| Model owner brings | Network provides |
|---|---|
| Model architecture and training logic (service files) | Sandboxed execution of that logic on participants' machines |
| Genesis model and encrypted test datasets | Clients' private data (never shared; only trained weights return) |
| A funded reward pool each GI | Staked, slashable validators who audit and aggregate honestly |
| Phase orchestration each GI | Registry, staking, rewards and settlement infrastructure |
| Registration and update fees |
Further reading
- Model Owner command reference — every command with options
- Model Owner command reference: commands and options
- Model Workflow: the full onboarding and GI walkthrough, in order
- Task Contracts: the contracts this role deploys and drives
- Manifest · Services: the model-definition format