Skip to content

Platform Contracts

Jump to bottom
umeradl edited this page Jul 8, 2026 · 1 revision

Platform Contracts

The platform contracts are the foundation of the DIN Protocol: four Solidity contracts deployed once by the DIN-Representative (later, the DIN-DAO) that every model, validator, and client on the network builds on. On the live DevNet they run on Optimism Sepolia (chainId 11155420).

They are distinct from the Task Contracts, which are deployed per model by each model owner.

                    DIN-Representative (owner)
                              │
              ┌───────────────┼─────────────────┐
              ▼               ▼                 ▼
      DinCoordinator   DinValidatorStake   DinModelRegistry
          │    │              ▲
 deploys  │    │ authorizes   │ slash()
          ▼    └──────────────┤
       DinToken        Task contracts (per model)

DinCoordinator

The entry-point and treasury contract of the protocol. It has two core jobs:

  1. Token issuance — anyone can deposit ETH via depositAndMint() and receive freshly minted DIN tokens at the current exchange rate (dinPerEth, default 1 ETH → 1,000,000 DIN; a tentative workaround until a DEX such as Uniswap V3 takes over the exchange).
  2. Slasher management — it is the only address allowed to register or de-register slasher contracts on DinValidatorStake. This is how the DIN-Representative authorizes a model's task contracts to slash misbehaving validators.

The DIN-Representative (as owner) can also withdraw accumulated ETH, update the exchange rate, and set the validator stake contract reference. At deployment, DinCoordinator deploys DinToken itself and becomes its immutable minting authority.

DinToken

The ERC-20 utility token of the network ("DIN Token", symbol DIN, 18 decimals, no pre-mint). It is deliberately minimal:

  • Minting authority is permanently bound to DinCoordinator — set once as an immutable at deployment, it can never be transferred.
  • The only supply mechanism is DinCoordinator.depositAndMint(); there is no burn function.

DIN is the staking and slashing currency: validators acquire it by depositing ETH, then lock it in DinValidatorStake to participate.

DinValidatorStake

The staking ledger for validators (auditors and aggregators). It holds staked DIN, tracks each validator's lifecycle, and lets authorized slasher contracts penalize misbehavior.

Key rules:

  • Minimum stake: each stake() call must be at least MIN_STAKE (currently 10 DIN). A validator is only eligible for work while Active.
  • Unbonding: unstaking starts a 7-day unbonding period before funds can be claimed — and pending withdrawals remain slashable until actually claimed, so a validator cannot dodge a penalty by exiting.
  • Slashing: only contracts registered in the slasher registry (a model's DINTaskCoordinator / DINTaskAuditor, added via DinCoordinator) may call slash(). Slashing is capped at the validator's total slashable funds.
  • Blacklisting: the contract owner can blacklist a validator address, blocking staking, exits, and withdrawal claims.

Validator status moves through None → Active → Exiting (plus Jailed reserved for future use and Blacklisted). If active stake falls below the minimum, the validator drops out of Active.

DinModelRegistry

The governed admission gateway for models. Every model on the network is registered here and gets a unique ID; admission works on a request/approval basis:

  • Two-phase registration: the model owner submits a registration request (requestModelRegistration); the DIN-Representative reviews and approves or rejects it. Only approved models receive an ID and become active.
  • Two-phase manifest updates: changing a model's manifest CID — which can change its training logic and parameters — follows the same flow: the owner submits an update request (requestManifestUpdate), and the DIN-Representative approves or rejects it.
  • Prerequisite: a model's DINTaskCoordinator and DINTaskAuditor must already be authorized as slashers on DinValidatorStake (via DinCoordinator) before a registration request is valid — this guarantees every registered model can enforce accountability from day one.
  • Two model types:
    • Open-source models — the trained model may be freely used by anyone.
    • Proprietary models — the trained model belongs to the owner and can be used commercially; registration carries a higher fee.
  • Governed fees: registration and manifest-update fees (separate rates for open-source and proprietary models) are small ETH amounts, adjustable by the DIN-Representative, that fund the ecosystem.
  • Kill switch: the DIN-Representative can disable any model instantly if it misbehaves.

Deployment & initialization sequence

1. Deploy DinCoordinator
      └── DinToken is deployed automatically (DinCoordinator becomes its minter)
2. Deploy DinValidatorStake (needs DinToken + DinCoordinator addresses)
3. DinCoordinator.updateValidatorStakeContract(stakeAddress)
4. Deploy DinModelRegistry
5. Per model, later:
      DinCoordinator.addSlasherContract(taskCoordinator / taskAuditor)
      → model owner requests registration → DIN-Representative approves

Further reading

Introduction

DIN Components

Network Roles

Clone this wiki locally