Model Owner

Model Owner

🚧 This wiki describes DevNet 2.0, soon to be launched. It follows the contracts and dincli on the develop branch; 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 has a lot of power within its own model and none outside it. A model owner runs their model's lifecycle and triggers slashing of its misbehaving validators. But admission to the network is gated by the DIN-Representative, 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, in this order:

1. Deploy the task contracts. dincli model-owner deploy task-coordinator, then dincli 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 a modelId constructor argument that dincli model-owner deploy doesn't pass yet. See the known gap on Task Contracts.

2. 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

3. Write the manifest and service files. These hold the model's architecture and the logic for each role (model.py, modelowner.py, client.py, auditor.py, aggregator.py). They are pinned to IPFS and referenced by CID in manifest.json. This is where the model owner's ML expertise lives; the protocol only ever sees CIDs. See Manifest and Services.
4. 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

5. Request model registration. Submit a request to DINModelRegistry and 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 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.

Action	Open-source	Proprietary
Register a new model	0.000001 ETH	0.00001 ETH
Request a manifest update	0.0000001 ETH	0.000001 ETH

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 act only while their phase is open.

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 (dincli task gi show-state, lms show-models, aggregation 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-testdataset uses the owner's X25519 key, kept in the dincli config directory (owner_x25519.key).
• Contract-only actions. These have no dincli command 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 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: 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