DIN Representative

DIN-Representative

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 trusted representative of the Infinite Zero Foundation; by design it evolves into the DIN-DAO, with the role's powers handed to community governance (the admin role is transferable on-chain to a multisig or timelock without redeploying anything).

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

Responsibilities

Platform operation

Deploys the platform contracts (DinCoordinator → DinValidatorStake → DinModelRegistry, in dependency order) and administers their parameters: the ETH→DIN exchange rate, the validator-stake contract reference, and treasury withdrawals.

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 requests this off-chain (Discord/Telegram/email), and 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 is correctly linked to the coordinator;
• no malicious or unauthorized slashing logic is embedded.

Only then: dincli dindao add-slasher. This review is what stops an arbitrary contract from gaining the power to slash validators' stakes.

Model & manifest admission

Every model registration and every manifest update is a request the Representative approves or rejects (dincli dindao registry approve-model / reject-model / approve-manifest-update / ...). Approval re-validates the task contracts at execution time — if they lost slasher status or changed owner since the request, the approval reverts. Fees are retained whether approved or rejected (spam protection).

Kill switch

disable-model <modelId> stops a misbehaving model immediately: manifest updates are blocked and downstream contracts check the flag before executing tasks. Nothing is deleted — on-chain history is preserved, and the model can be re-enabled.

Fee governance

All four registry fees (open-source/proprietary × registration/update) are Representative-adjustable, individually or atomically in one transaction (the atomic form is preferred for future governance proposals). Accumulated fees are withdrawable to fund the ecosystem.

Validator discipline

Beyond the automated, per-GI slashing executed by task contracts, the Representative can blacklist a validator address directly on DinValidatorStake — blocking staking, exits, and withdrawal claims — and unblacklist it.

What the Representative cannot do

Bounds worth stating explicitly:

• Cannot slash arbitrarily — slashing is executed only by authorized task contracts according to their on-chain rules; the Representative authorizes the contracts, not individual penalties.
• Cannot mint DIN at will — minting is bound to DinCoordinator.depositAndMint(), driven by ETH deposits at the published rate.
• Cannot touch training data or artifacts — data never leaves clients' devices, and models live on IPFS addressed by CIDs recorded through the participants' own submissions.

Path to the DIN-DAO

The role is deliberately built to be handed over: a single transferable admin (set-admin, e.g. to a multisig or timelock), atomic fee-setting shaped for governance proposals, and request/approval flows that map naturally onto proposal/vote. Contact channels for model onboarding are listed in the Model Workflow.

Further reading

• DIN DAO command reference — every dincli dindao command
• Platform Contracts — the contracts this role deploys and administers
• Model Owner — the counterpart role in the admission flow