Repository navigation
D. Network Features and Participation
This section introduces DMD Diamond’s network features and the ways coin holders, delegators, validator pool owners, and node operators participate. It explains the role of smart contracts and cooperative consensus, followed by validator eligibility, availability, rewards, and governance participation.
On this page
- Mission
- Features and Benefits
- Interoperability and Migration for DApps
- Smart Contract Support
- Secure Consensus
- Network Participants
- Governance
DMD Diamond's mission is to support financial independence through an open, community-governed blockchain. The network combines a limited-supply native coin with a platform for smart contracts, enabling people to hold and transfer value, build applications, and participate in securing and governing the network.
The project develops open-source protocols, tools, and services with a focus on accessible participation and long-term operation. Its vision includes cooperation across blockchain ecosystems, giving developers and users the freedom to choose the infrastructure that suits their needs.
DMD Diamond v4 combines cooperative consensus, EVM-compatible smart contracts, and on-chain governance. HoneyBadgerBFT (HBBFT) enables validators to construct blocks together, while POSDAO selects a rotating active validator set. This architecture supports the following capabilities:
-
Protocol-level front-running mitigation. Threshold-encrypted validator contributions and random sender-order shuffling limit discretionary transaction ordering. Transaction fees alone do not guarantee priority in the final order. This is a defining feature of DMD Diamond and is explained in Protocol-Level Front-Running Mitigation.
-
A fixed maximum coin supply. The maximum supply is 4,380,000 DMD, allocated at the v4 genesis. Network rewards redistribute coins within this limit rather than minting additional coins beyond it. Allocation at genesis does not mean that all coins are immediately in circulation.
-
EVM-compatible smart contracts. Developers can deploy Solidity contracts and adapt applications using familiar Ethereum tools. EVM compatibility supports application portability; transfers of assets or messages between blockchains require separate cross-chain integrations.
-
Cooperative consensus and instant finality. Validators construct blocks cooperatively under shared protocol rules. Once finalized by consensus, a block is treated as irreversible under the protocol’s fault-tolerance assumptions. Cooperative block creation avoids competing block proposals and the orphan blocks that can result from them.
-
Performance and demand-driven block production. Performance estimates and testing indicate throughput of 400 transactions per second or more, with achievable throughput depending on transaction complexity, node resources, and network conditions. Block production responds to transaction demand rather than continuously producing empty blocks. During periods without transactions, a small heartbeat block may be produced after more than 10 minutes of inactivity.
-
Rotating validator participation. POSDAO selects the active validator set using stake, Bonus Score, and randomness. Epochs normally last 12 hours, with network security procedures allowing earlier transitions. Pool staking limits and rotation are designed to distribute participation without guaranteeing that every candidate is selected in a particular epoch.
-
Censorship resistance through shared block creation. Multiple validators contribute transactions, reducing reliance on a single block proposer. Threshold encryption protects contributions during agreement, while the protocol's collective decision-making limits unilateral control over the resulting block.
-
Built-in randomness. Protocol-generated randomness supports functions such as validator selection and sender-order shuffling. These mechanisms help distribute participation and determine transaction order under shared rules.
-
On-chain community governance. The DAO provides public processes for proposing and voting on ecosystem funding, network parameters, and smart contract upgrades. Pool owners vote with weight that includes their own stake and delegated DMD; delegators participate indirectly through their choice of pool.
-
Long-term network incentives. The Delta Pot and Reinsert Pot fund rewards within the fixed maximum supply. Transaction fees and defined categories of unclaimed migration allocations and abandoned validator stakes are redistributed under protocol rules. These mechanisms do not provide general recovery of coins from wallets with lost private keys. See the Coin Economy for details.
-
DMD Naming System. Human-readable names provide a more accessible way to identify wallet addresses within the DMD ecosystem. See the DMD Naming System section for registration, management, and moderation rules.
Transaction ordering can affect the outcome of a swap, a mint, or another smart contract interaction. When a block proposer can choose the order of transactions, that control can be used to extract value from other users. Front-running and sandwich attacks are examples of ordering-based maximal extractable value (MEV).
DMD Diamond uses cooperative block creation to limit discretionary transaction ordering. Transactions are visible in the public mempool. Validators’ contributions are threshold-encrypted before being shared and decrypted after agreement on the contribution set. The final sender order is determined by random shuffling under shared protocol rules. Together, these mechanisms limit discretionary transaction ordering and prevent transaction fees alone from guaranteeing priority in the final order.
How the mechanism works
-
Transactions enter the public mempool. Users broadcast transactions to the network, where pending transactions are visible before validators assemble their contributions.
-
Validators encrypt their contributions. Each validator selects a transaction batch and threshold-encrypts its contribution before sharing it in the consensus process. Encryption applies to validator contributions, rather than to transactions when users broadcast them.
-
Agreement precedes decryption. Validators agree on the set of encrypted contributions. The agreed contributions are then decrypted using the required decryption shares and processed under common protocol rules.
-
Random shuffling determines sender order. Protocol-generated randomness determines the final order of senders. Validators apply the same transaction-processing rules to the agreed contributions; transaction fees alone do not guarantee a position in that order.
-
Validators construct the same block. Validators execute the ordered transactions, construct the same block, and contribute to its threshold signature. Nodes verify the resulting block under the shared consensus and validity rules.
Figure: From public mempool transactions to encrypted validator contributions, agreement and decryption, random sender-order shuffling, and cooperative block creation.
What this means for applications
For decentralized exchanges and other applications sensitive to transaction order, DMD provides a shared protocol mechanism for combining validator contributions and determining sender order. Validators commit their encrypted contributions before the agreed set is decrypted, and the final sender order follows protocol randomness rather than a single block proposer's discretion.
This mechanism concerns transaction ordering at the consensus layer. Pending transactions remain public; application behavior and execution prices depend on contract rules and market conditions.
The underlying consensus process and its fault-tolerance assumptions are described in HoneyBadgerBFT Protocol.
DMD Diamond provides an EVM-compatible environment for deploying applications developed for Ethereum and other EVM networks. Developers can reuse familiar contract languages, development tools, and Ethereum-style addresses while configuring their applications for the DMD network.
Application migration involves deploying contracts to DMD, configuring network connections, and adapting dependencies on external services or chain-specific functionality. EVM compatibility facilitates this process, but existing application state and assets do not automatically move between networks.
Cross-chain bridges and messaging services can connect independent networks where suitable integrations are available. These services have their own deployment requirements and security assumptions. They are separate from DMD's EVM compatibility and should not be understood as built-in connectivity to every blockchain.
DMD Diamond v4 supports smart contracts through the Ethereum Virtual Machine. Developers can use Solidity and other languages that compile to bytecode supported by the network's EVM implementation to build decentralized exchanges, digital asset applications, governance tools, and other programmable services.
The DMD node client is based on OpenEthereum and incorporates DMD-specific consensus and system-contract integrations. Applications execute under DMD's network rules, with DMD used to pay transaction fees. Developers should configure compilation and deployment for the EVM features supported by the DMD client and test their contracts and external integrations on the target network.
Cooperative consensus, instant finality, and protocol-level transaction ordering provide the execution environment described in this Whitepaper. Application security also depends on contract design, access controls, and the services an application uses.
DMD Diamond combines two complementary mechanisms: HBBFT provides cooperative consensus, while POSDAO selects the validators that participate in it. The active set normally contains 25 validators and rotates at epoch boundaries. Epochs normally last 12 hours, although network security procedures can trigger an earlier transition. The network can also operate with a smaller active set when fewer eligible candidates are available.
During an epoch, validators contribute transactions and construct blocks under shared protocol rules. Agreement requires the protocol's validator quorum, described as a supermajority of more than two thirds of the active set. Consensus safety and finality depend on the protocol's fault-tolerance assumptions; they should not be interpreted as unconditional guarantees under every possible network failure.
The cooperative block-creation process is illustrated in HoneyBadgerBFT Protocol.
Validator selection combines stake, Bonus Score, and randomness. Delegation increases a pool's stake, while Bonus Score reflects the behavior tracked by the network's security mechanisms. Selection is not determined by stake alone and does not guarantee a particular candidate a place in each epoch.
At the current minimum owner stake of 10,000 DMD, the maximum supply of 4,380,000 DMD implies a theoretical ceiling of 438 simultaneously funded validator candidates if the entire supply were available for that purpose. This is not a limit on the number of full nodes or a statement about the current candidate count. Earlier planning estimates anticipated 50–75 candidates; the actual number depends on participation and available stake.
Active pools that meet the reward conditions receive epoch rewards, which are then allocated between the pool owner, any configured operator, and delegators. Unavailability or failures during validator preparation can affect rewards, Bonus Score, and eligibility for subsequent selection. Recovery and any temporary restrictions follow the relevant protocol procedures rather than a guaranteed return after a fixed number of epochs.
For details, see Node Selection Through POSDAO, Validator Reward, and the Network Security System.
Participants can interact with the network in several roles:
- Coin holders and delegators use compatible wallets to hold and transfer DMD, interact with applications, and delegate stake to validator pools. Delegators participate indirectly in governance by choosing pools whose owners represent their interests.
- Validator pool owners register a pool, provide the required owner stake, and arrange reliable operation of the associated validator node. They may operate the node themselves or engage a technical operator.
- Node operators maintain a synchronized copy of the blockchain, run the DMD client, and maintain validator infrastructure, either for their own pool or on behalf of a separate pool owner. A configured operator reward share compensates this role without transferring control of the owner’s stake or governance rights.
A full node can also run without participating as an active validator; running a full node alone does not confer validator rewards.
Staking is available through the Diamond UI, using a compatible wallet configured for the DMD network. The current minimum initial delegation is 100 DMD and can be changed through DAO governance. Subsequent top-ups to an existing delegation can be smaller.
The current 50,000 DMD pool staking limit restricts additional deposits. Rewards can increase the pool's balance above this value, so it is not an absolute ceiling on the balance displayed in the UI.
Holders with eligible DMDv3 migration allocations can follow the Claiming v4 Coins User Guide to claim their DMDv4 coins.
Validators participate in cooperative block creation and transaction execution when their pools are selected for the active set. A validator pool consists of the owner's stake and any delegated stake associated with that validator. The term pool refers to staking and reward allocation; DMD v4 does not use Proof-of-Work mining.
Validator candidates require:
- A synchronized DMD v4 full node with the HBBFT/POSDAO extensions and the required validator configuration, running on Linux or a compatible environment.
- A static IP address and reliable connectivity for continuous operation.
- At least the current minimum of 10,000 DMD in owner stake.
- Separate staking and validator node addresses configured for their respective roles.
- Pool registration and staking through the network's contracts, accessible through the Diamond UI.
The staking address controls the owner's stake and pool-related actions. The validator node address identifies the node that performs consensus duties. These addresses serve different purposes and should not be treated as interchangeable.
Epoch rewards are added to stake under the reward mechanism. Deposits, withdrawals, and changes of delegation follow the applicable staking and locking rules:
- Where stake is immediately withdrawable, the user can unstake and then stake with another pool.
- Where stake is locked, the user orders a withdrawal, waits until it becomes claimable, claims it, and can then stake elsewhere.
The Diamond UI's Unstake action provides the applicable withdrawal flow. Eligibility and timing depend on the pool and stake state; not every adjustment takes effect at the next epoch.
Contract-level sets and availability
The contracts track several related sets and conditions. These are not a second list of UI statuses, and membership can overlap:
| Contract concept | Meaning |
|---|---|
| Pools to Be Elected | Pools that meet the eligibility conditions, including the required owner stake and announced validator availability, and can be considered for the next active set. |
| Pending Pools | Pools selected for the upcoming epoch while the transition and validator preparation are in progress. Selection uses stake, Bonus Score, and randomness. |
| Active Pools | Pools whose validators form the active set for the current epoch. |
| Unavailable Pools | Pools whose validators have not announced availability or have been marked unavailable. New staking is disabled; withdrawals remain subject to the applicable staking rules. |
Diamond UI statuses
| Status | Meaning |
|---|---|
| Active | The validator is part of the current active set. Reward eligibility also depends on availability and the applicable performance conditions. |
| Standby | The validator is not currently active but is eligible for selection. |
| Invalid | The pool does not meet the required conditions, for example because its validator is unavailable or its owner stake is below the required minimum. |
Eligible Candidates groups Active and Standby candidates in the UI; it is not a fourth status. Pending selection is a contract-level transition concept and is distinct from these three labels.
A Standby pool does not earn DMD validation rewards for an epoch in which it is not active. Its Bonus Score can nevertheless increase while it remains available under the rules described in the Bonus Score System.
Availability records a validator's readiness to participate in consensus. A candidate can be available without being selected for the current active set.
A validator can be marked unavailable after failing to submit required key-generation data, such as PARTS or ACKS during preparation for an epoch. Connectivity reports can also lead to unavailability through the Connectivity Monitoring and Epoch Transitions.
The contract's validatorAvailableSince(address) value tracks announced availability; a zero value indicates that the validator is currently unavailable. A synchronized validator can reannounce availability through announceAvailability, supplying the required recent block number and block hash. The contract checks this evidence before accepting the announcement.
Unavailability affects several aspects of participation:
- Rewards: validators marked unavailable do not receive rewards for the affected epoch. Reannouncing availability during that epoch does not restore reward eligibility for its remainder.
- Selection: the validator must regain the required availability and eligibility before being considered for subsequent active sets.
- Bonus Score: penalties depend on the event. Some are fixed deductions, while others depend on the duration of unavailability or disconnection. Not every penalty is proportional to elapsed time.
The Network Security System describes the relevant detection, recovery, and scoring procedures.
Eligibility requirements
A candidate becomes eligible by maintaining a correctly configured and synchronized node, providing the required owner stake, registering the pool, and announcing availability. Continuous operation and a static IP address support the node's readiness to participate.
Selection mechanism
POSDAO selects the upcoming validator set using three inputs:
- Stake: the owner's stake and delegated DMD contribute to the pool's selection weight.
- Bonus Score: the network's scoring rules account for availability and behavior during validator duties and preparation. See Bonus Score System for score adjustments and examples.
- Randomness: random selection operates together with the stake and score inputs to determine the upcoming set.
A larger stake alone does not guarantee selection, and delegation does not guarantee that a pool will be active in the next epoch. The pool staking limit constrains new deposits, while reward accumulation can increase the balance beyond that limit.
Becoming an active validator
Selected candidates enter the pending set and complete the required preparation, including key generation, before taking their place in the active set. Missing required submissions can lead to removal from the pending set, score penalties, and unavailability under the transition rules. Active validators then cooperate in creating blocks, validating transactions, and executing smart contracts.
For an illustration of the staking and validator-selection process, see Node Selection Through POSDAO.
Delegator contributions
Delegation contributes to the pool's total stake and selection weight. Delegators can support candidates based on their operational performance and governance decisions.
Rewards and accountability
Reward distribution is separate from selection. Once a pool qualifies for rewards, its allocation follows the rules described in Validator Reward. Delegators receive their share of the stake-proportional allocation; they do not receive a guaranteed reward merely because their pool is eligible for selection. Validators must maintain availability and complete their required duties.
A validator pool is treated as abandoned when 10 years have elapsed since its last recorded availability, as determined by the contract's abandonment rules. This criterion is independent of when the validator was last selected for the active set. Remaining available while not being selected is not, by itself, abandonment.
The abandonment mechanism covers both the owner's stake and delegated DMD in the pool. When the abandoned funds are transferred, 50% goes to the Governance Pot and 50% to the Reinsert Pot. Staking and withdrawals are unavailable once the pool has been marked as abandoned under this process.
The Diamond UI provides an action to trigger the transfer of abandoned funds and an indicator for pools already marked as abandoned. This is a protocol mechanism for abandoned validator stakes, not a general recovery service for lost wallet keys. The Coin Economy explains the roles of the receiving pots.
Epoch rewards are funded by the Delta Pot and Reinsert Pot. A configurable share is allocated to the Governance Pot, and eligible active pools receive their validator allocation. A pool must meet the reward conditions; being registered or selected does not make the reward unconditional.
Epoch and pool allocation
The calculation can be expressed in separate steps:
Base epoch reward budget = (Reinsert Pot balance + Delta Pot balance) / 6000
Duration factor = min(actual epoch duration / 12 hours, 1)
Adjusted epoch reward budget = Base epoch reward budget × Duration factor
Reward per eligible active pool = Adjusted epoch reward budget × (1 − Governance Pot Share) / 25
Governance Pot Share is expressed as a fraction. Its current value is 0.10 (10%), and it can be changed through DAO governance. The divisor 25 is the reference validator count used to calculate each pool’s reward, regardless of how many pools are eligible for rewards in a particular epoch. It is not replaced by the actual number of eligible validators.
A shorter epoch reduces the reward proportionally. An epoch longer than 12 hours does not increase it beyond the full-epoch amount. If fewer than 25 validators are eligible, the per-pool allocation is not increased to redistribute the shares of missing or ineligible validators.
Allocation within a pool
Of the reward allocated to an eligible pool:
- 20% forms the upfront pool owner allocation. Any configured node operator share is paid from this portion.
- 80% is distributed proportionally to stake, including the owner's stake and all delegations.
The owner therefore receives the remaining upfront allocation after any operator payment, plus the owner's stake-proportional share of the 80% portion. The percentages below refer to the pool's allocated reward, after the Governance Pot allocation.
| Example | Owner stake | Delegated stake | Owner upfront share | Owner stake-based share | Delegators' combined share |
|---|---|---|---|---|---|
| 1 | 10,000 DMD | 40,000 DMD | 20% | 16% | 64% |
| 2 | 25,000 DMD | 25,000 DMD | 20% | 40% | 40% |
These examples assume no separate node operator share. They illustrate the allocation proportions, not a guaranteed amount of DMD earned. Each delegator's portion is proportional to their stake within the pool. See Node Operator Share for the operator allocation.
A pool owner can appoint a technical operator and configure part of the upfront owner allocation to be paid to a separate operator address. This allows the owner to retain control of the stake and governance participation while another party maintains the validator infrastructure.
The operator setting is expressed as a percentage of the pool's total allocated epoch reward, paid from the 20% upfront owner portion. It is not a percentage applied again to that 20%. A configured share can range from 0.01% to 20%; setting 20% assigns the entire upfront portion to the operator. The remaining 80% continues to be distributed according to stake.
For example, if a pool receives 100 DMD and the operator share is 5%:
| Allocation | Amount |
|---|---|
| Node operator | 5 DMD |
| Pool owner, remaining upfront portion | 15 DMD |
| Stake-proportional distribution to the owner and delegators | 80 DMD |
The pool owner also receives their stake-proportional share of the 80 DMD. A technical operator does not acquire rights to withdraw the owner's stake or cast the pool's DAO votes merely by receiving an operator share. If the same person also owns a pool, those rights arise from the ownership role.
The operator address can be configured during pool creation or later through the pool owner's profile in the Diamond UI. It can be changed once per epoch, and only one recipient address is active at a time. Replacing the address replaces the previous recipient.
The owner remains responsible for choosing a reliable operator. Operational failures can affect the pool's availability, Bonus Score, selection prospects, and rewards, including those of its delegators.
DMD Diamond's DAO provides on-chain processes for ecosystem funding, network parameter changes, smart contract upgrades, and other supported proposal types, including DAO Names Moderation. Proposals, votes, and outcomes are publicly recorded so that participants can review how governance decisions are made.
DAO governance and POSDAO serve different purposes. The DAO enables participants to propose and vote on decisions. POSDAO manages staking-related mechanisms and automated selection of the active validator set. DAO participation should not be confused with being selected to create blocks in a particular epoch.
Registered validator pool owners exercise the pool's voting rights, with voting weight that includes their own stake and delegated DMD under the DAO's rules. Delegators participate indirectly by choosing owners whose decisions align with their interests. A technical node operator does not receive these voting rights merely through an operator reward arrangement.
Delegators can review public voting activity and choose a different pool. Moving stake follows the applicable unstaking and locking rules; it is not always an immediate switch or a change completed automatically at the next epoch.
The DAO Governance describes proposal types, participation requirements, approval thresholds, and the voting process. The Diamond UI provides the interfaces for staking and governance participation.
