Skip to content

DIN DAO

Jump to bottom
umeradl edited this page Jul 8, 2026 · 2 revisions

DIN DAO

📋 Status: Planned — the DIN DAO contracts do not exist yet. This page describes the design intent per the governance design doc and the project roadmap; details may change as the design is finalized.

Naming note: in today's documentation and CLI, "DIN DAO" (dincli dindao ...) refers to the DIN-Representative — a single administrative account that deploys the platform contracts and approves registrations. The DIN DAO described here is the planned replacement of that centralized authority with on-chain governance. Same name, opposite trust model.

What it will be

The DIN DAO is the planned governance layer of the DIN network: a set of contracts that progressively take over the authority currently held by the DIN-Representative's admin key over the Platform Contracts — fee parameters, model registration approvals, slasher authorization, validator blacklisting, treasury withdrawals, and contract upgrades.

Planned contract modules:

  • Multisig — N-of-M approval with per-category thresholds, replacing single-key admin actions
  • Timelock — every governance action becomes visible on-chain before it executes, with a cancellation window; the timelock ultimately owns the platform contracts
  • Governance staking — voting power from locked DIN (non-transferable, snapshot-based, delegable), not raw wallet balances
  • Governor — on-chain proposals, voting, quorum, and execution through the timelock
  • Guardian — a narrow emergency path (e.g. disabling a malicious model) whose actions expire unless ratified by normal governance

Why it exists

DIN is a protocol with shared rules, incentives, and security assumptions. As long as those rules sit behind one admin key, participants must trust the operator: economic policy could change unilaterally, and blacklist, slashing, and upgrade authority would be a standing centralization risk. A DAO doesn't remove governance risk, but it makes authority transparent, rule-bound, auditable, and contestable — a requirement for a credible testnet and beyond, not a nice-to-have.

Two design decisions are already settled in the governance design doc:

  • No raw quadratic voting. Transferable tokens make Sybil-splitting trivial; quadratic mechanisms are at most future non-binding signaling.
  • No free-balance voting. Binding votes come from staked or locked DIN measured at a snapshot, so governance power reflects commitment to the protocol rather than momentary balances.

The staged rollout

Decentralization arrives in stages, each mapped to a network milestone — nothing activates before devnet 3.0:

Stage What changes Target
A — Multisig N-of-M multisig shadow-operates admin actions devnet 2.0
B — Timelock Timelock becomes owner() of the platform contracts; all admin actions get an on-chain delay devnet 3.0
C — Token vote Governor + locked-DIN voting power; proposals, quorum, delegation testnet 1.0–2.0
D — Guardian Narrow emergency powers, expiring unless ratified with Stage C

How it fits

   DIN holders ──lock──▶ governance staking (voting power)
                              │ vote
                              ▼
                          Governor ──queue──▶ Timelock ──owns──▶ Platform Contracts
                              ▲                  ▲                (fees, registry,
                     propose  │                  │ propose/cancel  staking, upgrades)
                              └── Multisig ──────┘
                                     │
                                Guardian (emergency, expiring)

Governance actions flow through proposals rather than direct admin calls; the DIN Indexer later provides the read layer for proposal lists, voter histories, and governance dashboards.

Status & sequencing

Design-first: an architecture document precedes the Solidity work, and the contracts land on a feature branch well before any activation. The near-term protocol work (staking, slashing, fees) deliberately ships with plain owner-controlled parameter setters — exactly the surface the timelock takes over later without redesign. Binding token-vote governance is a testnet-era milestone.

Further reading

Introduction

DIN Components

Network Roles

Clone this wiki locally