DIN DAO

DIN DAO

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

⏸️ Status: deferred to post-mainnet. Design decision DD-3 (resolved 2026-08-04) moved all DIN-DAO work out of active scope, Stages A through D. That includes the earlier work on PR #27 and issue #23. DevNet 2.0 launches without on-chain governance. This page records the long-term direction, not a schedule.

How DIN is governed today

During DevNet 2.0, governance runs off-chain, following Ethereum's model: team coordination and public discussion (forums and GitHub discussions, the equivalent of All Core Devs calls). No multisig sits between the community and protocol changes.

• The DIN-Representative holds a single admin key and is the owner() of the Platform Contracts. It uses that key for fee parameters, model admission, slasher authorization, blacklisting and contract upgrades.
• The CLI commands for this role are dincli dinrep …. There is no dincli dindao.
• If a multisig is used in the near term, it is a plain Safe for treasury funds only, never for protocol roles.
• The contracts' owner-controlled setters are simply how the protocol is run for now. They are not a stepping stone to a particular on-chain design.

The long-term direction

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 can change unilaterally, and blacklist, slashing and upgrade authority are a standing centralization risk. A DAO doesn't remove governance risk, but it makes authority transparent, rule-bound, auditable and contestable.

When governance work resumes after mainnet, the governance design doc is the starting point. It explored:

• Multisig and timelock. These would replace single-key admin actions with N-of-M approval, and make every governance action visible on-chain before it runs, with a window to cancel it.
• Governance staking. Voting power would come from locked DIN (non-transferable, measured at a snapshot, delegable), not from raw wallet balances.
• Governor. On-chain proposals, voting, quorum and execution.
• Guardian. A narrow emergency path whose actions expire unless normal governance ratifies them.

The design doc also recommends against raw quadratic voting, because transferable tokens make Sybil-splitting trivial, and against free-balance voting. How voting power is measured (DD-1, DD-2) is still an open, deferred decision.

Further reading

• Design decisions: DD-1, DD-2 and DD-3, with the reasoning behind the deferral
• Governance design doc: governance domains, the rationale for voting power, and the proposal lifecycle
• DIN-Representative guide: the admin surface as it exists today
• DIN-Representative: the role holding that authority
• Platform Contracts: the contracts a future DAO would govern