Repository navigation
G. DAO Governance
This section explains how governance decisions are proposed, voted on, and carried out in DMD Diamond. It covers participation, proposal types, voting weight and approval thresholds, configurable parameters, and the proposal lifecycle and fees.
On this page
- Governance Model and Participation
- Proposal Types
- Voting Weight and Approval Thresholds
- Governance Parameters
- Proposal Lifecycle and Fees
The DMD Diamond Decentralized Autonomous Organization (DAO) provides on-chain governance for ecosystem funding, network parameters, DAO-controlled contracts, and name moderation. Proposals, votes, and outcomes are publicly recorded and can be reviewed through the Diamond UI.
- Proposers submit proposals during the proposal phase and pay the applicable proposal and network fees. Creating a proposal does not require ownership of a validator pool.
- Validator pool owners cast votes with weight that includes their own stake and delegated DMD under the DAO's voting rules. Voting participation is not restricted to the active validator set.
- Delegators participate indirectly by choosing pools whose owners represent their interests. Their delegated stake contributes to the pool's voting weight. Changing delegation follows the applicable staking and withdrawal rules.
A technical node operator does not acquire the pool's governance rights merely by receiving an operator reward share. The participant roles are described in Network Participants.
DAO governance is separate from POSDAO validator selection: governance determines community decisions, while validator selection determines which pools participate in block creation. Governance funding and its sources are explained in Epoch Rewards and Governance Funding.
The DAO supports the following proposal types. Low Majority and High Majority refer to the approval thresholds defined in Voting Weight and Approval Thresholds.
| Proposal type | Purpose | Approval category |
|---|---|---|
| Open Proposal | Community initiatives and funding requests, with payments to specified externally owned accounts (EOAs). | Low Majority for funding within the Low Majority Contract's available balance; High Majority when funding must come from the Governance Pot. |
| Ecosystem Parameter Change | Changes to supported network and governance parameters within their permitted values. | Low Majority. |
| Contract Upgrade | Changes to DAO-controlled contracts, specified by a target address and encoded call data. | High Majority. |
| DAO Names Moderation | Community decisions to blacklist inappropriate names and apply the associated registration and display restrictions. | High Majority. |
Low Majority Fill is a subtype of Contract Upgrade used to replenish the Low Majority Contract for Open Proposal funding. It follows High Majority approval rules.
DAO Names Moderation connects governance to the DMD Naming System. Approved moderation decisions govern name restrictions and filtering in the hosted interface; the Naming System section explains their scope and local-interface filtering preferences.
Contract Upgrade proposals require review of the target contract and executable call data, as well as the proposal description. The Contract Upgrade Proposal Guide covers technical preparation. The existing upgrade guidance advises against approving Contract Upgrade proposals using the CREATE2 opcode. The executable action must be reviewed independently of its description.
Votes are weighted by stake under the DAO's rules, rather than counted by the number of wallets or validators. A pool's voting weight includes its owner's stake and delegated stake. For a proposal, let W be the total DAO voting weight used for the calculation, Y the weight voting Yes, and N the weight voting No.
- Participation = (Y + N) / W.
- Exceeding Yes = (Y − N) / W.
Both measures use total DAO voting weight as their denominator. Exceeding Yes is the net support after subtracting No votes; it is not the percentage of participating votes that chose Yes.
| Approval category | Required participation | Required Exceeding Yes |
|---|---|---|
| Low Majority | One third of total DAO voting weight | One third of total DAO voting weight |
| High Majority | 50% of total DAO voting weight | 50% of total DAO voting weight |
A proposal must satisfy both applicable thresholds at the end of voting.
Example. With total DAO voting weight of 1,000,000 DMD, Yes votes representing 650,000 DMD and No votes representing 100,000 DMD give 75% participation and 55% Exceeding Yes. This satisfies both High Majority thresholds.
Unsuccessful vote. With the same total DAO voting weight of 1,000,000 DMD, Yes votes representing 350,000 DMD and No votes representing 250,000 DMD give 60% participation but only 10% Exceeding Yes. Although Yes outweighs No and participation exceeds the required threshold, the proposal fails even the Low Majority approval threshold.
Pool owners can change a vote from Yes to No, or from No to Yes, during the voting phase. A submitted vote cannot simply be withdrawn. Delegators can review public voting records when choosing the pools they support.
Ecosystem Parameter Change proposals adjust supported parameters within predefined value sets. Changes outside the permitted parameter-change rules require the Contract Upgrade route and High Majority approval. Each parameter is subject to the DAO's change-frequency and execution restrictions; the described governance schedule allows one change per monthly cycle.
Competing parameter proposals. Several proposals to change the same parameter may meet the voting thresholds in one cycle. The community must coordinate which approved change is taken forward for execution, subject to the one-change-per-cycle restriction. Passing the vote does not mean that every competing change can be applied in that cycle.
The table lists permitted values and the initial values documented for the DAO launch. Initial values are historical reference points, not a statement of current on-chain settings. The applicable contract state determines the value in use.
| Parameter | Purpose | Permitted values | Initial value |
|---|---|---|---|
Minimum Delegation Stake — delegateMinStake
|
Minimum initial delegation to a validator pool. | 50, 100, 150, 200, 250 DMD | 100 DMD |
Minimum Gas Price — minimumGasPrice
|
Minimum transaction gas price. | 0.1, 0.2, 0.4, 0.6, 0.8, 1, 2, 4, 6, 8, 10, 15, 20, 30, 40, 50 Gwei | 1 Gwei |
Block Gas Limit — blockGasLimit
|
Maximum gas available for transaction execution in a block. | 100–1,000 million gas, in steps of 100 million | 300 million gas |
Minimum Block Time — minBlockTime
|
Minimum time to add a new block to the chain. | 1, 2, 3, 4, 5 minutes | 3 minutes |
Maximum Block Time — maxBlockTime
|
Maximum time to add a new block to the chain. | 60, 300, 600, 1200, 1800 minutes | 600 minutes |
Proposal Fee — proposalFee
|
Fee paid when submitting a proposal, separate from transaction gas fees. | 10–90 DMD, in steps of 10 DMD | 50 DMD |
Governance Pot Share — governancePotShareNominator
|
Share of the epoch reward allocation directed to the Governance Pot. | 10–20%, in steps of 1 percentage point | 10% |
Report Disallow Period — reportDisallowPeriod
|
Interval after the start of an epoch during which connectivity reporting is disallowed. | 3–30 minutes, in steps of 3 minutes | 15 minutes |
Bonus Score Gain per Epoch — scoreGainPerEpoch
|
Score increment for candidates meeting the applicable eligibility conditions during an epoch. | 10–50 points, in steps of 5 points | 20 points |
Block-production behavior is described in Block Validation.
The effects of reward and staking parameters are described in Coin Economy and Network Features and Participation. Connectivity reporting and Bonus Score rules are covered in the Network Security System.
Mainnet governance alternates between a 14-day proposal phase and a 14-day voting phase. Proposals are submitted during the proposal phase. Voting follows immediately; new proposals cannot be submitted during the voting phase.
| Stage | What happens |
|---|---|
| Submission | The proposer defines the proposal and its requested action, then pays the proposal fee and transaction gas fee. |
| Dismissal, if requested | The proposer may dismiss the proposal during the proposal phase. A dismissed proposal does not proceed to voting, and its proposal fee is forfeited. |
| Voting | Eligible pool owners vote Yes or No and may change their choice until the voting phase ends. |
| Finalization | After voting, the outcome is recorded and the proposal fee is settled. Both accepted and rejected proposals require finalization. |
| Execution | An accepted, finalized proposal is executed to apply its approved action, subject to its execution conditions and deadline. |
Fees. The proposal fee was initialized at 50 DMD and is configurable through governance. At finalization, accepted proposals have their proposal fee refunded to the proposer; rejected proposals have it transferred to the Reinsert Pot. Dismissal does not refund the proposal fee. Network gas fees are separate and are not refunded by the DAO.
Finalization. Any participant can finalize a proposal after voting ends. Outstanding proposals from the previous voting phase must be finalized before new proposals can be submitted. Finalization records the result and settles the proposal fee; it does not execute the approved action.
Execution. The execution window covers the following proposal and voting phases, a total of 28 days under the described mainnet schedule. An accepted proposal cannot be executed after its window expires. Contract Upgrade execution must be initiated by the proposer. Unexecuted proposals do not, by themselves, prevent the next cycle's proposal submission and voting. Finalization and execution require transactions and the associated network gas fees.
Public record and interface. Proposal history and voting results remain available on-chain. The Diamond UI provides access to governance records and available actions. The DAO Proposal and Voting Guide contains the step-by-step submission and voting workflows.
