Skip to content

DIN Representative

Jump to bottom
umermjd11 edited this page Oct 5, 2026 · 4 revisions

DIN-Representative

🚧 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 DIN-Representative is the network's governance and admission authority: the entity that operates the Platform Contracts on behalf of the protocol. Today it is a single admin key, held by a trusted representative of the InfiniteZero Foundation, and it is the owner() of the platform contracts. On-chain DIN-DAO governance is deferred to post-mainnet. Until then, governance happens off-chain (see DIN DAO).

The role's philosophy: the DIN-Representative controls who and what enters the network and never touches the training itself. Model owners run their models, validators stake and work, and clients keep their data. The Representative guards the perimeter.

Its commands live under dincli dinrep.

Responsibilities

Platform deployment

The Representative deploys the seven platform contracts (DinTreasury, DinToken, DinFeeRouter, DinCoordinator, DinValidatorStake, DINModelRegistry, DinEmission), each behind an OpenZeppelin Transparent Proxy, with the Foundry script foundry/script/DeployPlatform.s.sol. The script deploys, initializes and wires everything in 22 transactions, then writes the addresses to foundry/deployments/<network>.json. That file is then imported into dincli:

cd foundry && npm ci && forge clean
forge script script/DeployPlatform.s.sol --rpc-url <rpc> --broadcast --account <keystore> --sender <din_rep_address>
cd .. && dincli --network <network> system import-deployments

The deploying address becomes the owner of every platform contract and every ProxyAdmin. A native dincli dinrep deploy is planned but not implemented.

Protocol parameters

The Representative administers the platform's economic settings. Most are owner calls on the contracts, with no dincli command yet:

  • DIN supply:
    • dinPerEth, the ETH → DIN purchase rate (default 1,000,000 DIN per ETH);
    • mintCap, the total supply cap (0 = uncapped);
    • retireFaucet(), which permanently ends both minting paths (one-way).
  • Staking: the minimum stake, the unbonding period, and the S5 repeat-offence settings on DinValidatorStake.
  • Fee routing: the DinFeeRouter splits and its fee-source allowlist.
  • Emission: the DinEmission schedule (initial per-GI emission, decay, epoch length, max epochs).

Slasher authorization: the gate before the gate

Before any model can even request registration, its Task Contracts must be authorized as slashers on DinValidatorStake. The model owner asks off-chain (Discord, Telegram or email). The Representative reviews before authorizing:

  • both contracts were deployed by the stated model-owner address;
  • the coordinator implements the expected interface and references the correct stake contract;
  • the auditor contract is correctly linked to the coordinator;
  • there is no malicious or unauthorized slashing logic.

Only then does the Representative authorize them:

dincli dinrep add-slasher --taskCoordinator     # or --taskAuditor, or --contract <address>

This review is what stops an arbitrary contract from gaining the power to slash validators' stakes.

Model and manifest admission

Every model registration and every manifest update is a request the Representative approves or rejects:

dincli dinrep registry list-pending-requests [-t model|manifest]
dincli dinrep registry explore-request -t model <requestId>
dincli dinrep registry approve-registration-request <requestId>
dincli dinrep registry reject-registration-request  <requestId>
dincli dinrep registry approve-manifest-update      <requestId>
dincli dinrep registry reject-manifest-update       <requestId>
dincli dinrep registry total-models

Approval re-validates the task contracts at execution time. If they have lost slasher status or changed owner since the request, the approval reverts. Fees are kept whether a request is approved or rejected, which protects against spam.

Disabling a model

dincli dinrep registry disable-model <modelId>
dincli dinrep registry enable-model  <modelId>

Disabling blocks new manifest update requests and approvals for the model. Nothing is deleted, on-chain history is preserved, and the model can be re-enabled. The task contracts don't read this flag, so disabling a model does not stop its running GIs, submissions or slashing.

Fees

The four registry fees (open-source and proprietary, for registration and for updates) can be set individually or atomically in one transaction:

dincli dinrep registry set-open-source-fee <eth>      # also: set-proprietary-fee, set-open-source-update-fee, set-proprietary-update-fee
dincli dinrep registry set-fees --open-source <eth> --proprietary <eth> --open-source-update <eth> --proprietary-update <eth>

Collected ETH stays where it was received until the Representative sweeps it to DinFeeRouter. There is no withdraw():

dincli dinrep registry sweep-fees       # registration and manifest-update fees
dincli dinrep coordinator sweep-fees    # ETH received from DIN purchases (depositAndMint)

The router splits each sweep. With the default split (95% validator pool, 5% treasury), only the treasury share reaches DinTreasury today. The rest stays in the router until the contracts that will consume it ship.

Validator discipline

Beyond the automated per-GI slashing that task contracts carry out, the Representative can blacklist a validator address directly on DinValidatorStake, which blocks staking, exits and withdrawal claims, and can unblacklist it.

What the Representative cannot do

Some limits are worth stating explicitly:

  • It cannot slash arbitrarily. Only authorized task contracts slash, by their on-chain rules. The Representative authorizes contracts, not individual penalties.
  • It cannot mint DIN directly. DIN is minted only through DinCoordinator.depositAndMint() (ETH deposits at the published rate) and mintEmission() (called only by DinEmission on its schedule). Both are bounded by mintCap and end for good at retireFaucet(). The Representative's control over supply is limited to setting those parameters.
  • It cannot touch training data or artifacts. Data never leaves clients' devices, and models live on IPFS under CIDs recorded by the participants' own submissions.

Ownership and the path forward

There is no single set-admin switch. Each platform contract changes owner with OpenZeppelin transferOwnership, and each of the seven ProxyAdmins has its own owner. On-chain governance (the DIN DAO) is deferred to post-mainnet under design decision DD-3. Until then the owner-controlled setters are how the protocol is run, and any near-term multisig would hold treasury funds only, not protocol roles. Contact channels for model onboarding are listed in the Model Workflow.

Further reading

Introduction

DIN Components

Network Roles

Clone this wiki locally