Overview#
Masternodes, once unique to the Dash network, are now becoming popularas the technology is forked into other blockchains. This section of thedocumentation describes the principles and mechanisms of masternodes andthe services they provide to the Dash network specifically.
Simply put, a masternode is a server with a full copy of the Dashblockchain, which guarantees a certain minimum level of performance andfunctionality to perform certain tasks related to block validation, aswell as InstantSend and CoinJoin, as the and instant transaction andprivacy features in Dash are called. The masternodes are paid forthis service, using a concept known as Proof of Service. This is inaddition to the Proof of Work done by miners to secure the blockchain.Masternodes are also allowed to vote on governance and fundingproposals, with each masternode receiving one vote(yes/no/abstain) on each proposal submitted to the system.
Anyone can run a masternode. The objective is to have enoughdecentralization to ensure that no single person controls a significantfraction of the masternodes. However, to avoid bloating the network withunnecessary masternodes or encouraging reckless operators, there is onecondition that needs to be fulfilled: proof of ownership of DASH collateral.The coins don’t need to be in the masternode, but they need to be keptin a certain way that is transparent to the entire network. If the ownermoves or spends those coins, the masternode stops working and paymentceases.
Masternodes are paid by the network for the InstantSend, CoinJoin andgovernance services they provide. 20% of the block subsidy goes to the budgetwith the remaining 80% split between miners and masternodes per thisblock reward reallocation table.Then, every 16,616 blocks (approximately 30.29 days), asuperblock is created that contains the entire 20% payout to the budgetproposal winners. Masternodes are selected for payment in each block(approximately every 2.6 minutes) from a deterministic masternode list,and moved to the back of the list after payment. As more masternodes arecreated, the duration between payments increases. If the collateralbehind a masternode is spent, or if a masternode stops providingservices to the network for more than one hour, it is removed from thelist until normal service resumes. In this way, masternodes are givenincentive to provide efficient and reliable services to the network.
Having so many servers holding a full copy of the blockchain and workingfor the coin can be extremely useful. Thanks to the reward system, thereis no risk of not having enough masternodes, and the developers can relyon them quickly deploying any new decentralized feature they want toimplement. This is where the true strength of Dash lies - anincentivized system of thousands of distributed servers working 24x7means that Dash can scale more efficiently and deploy services morequickly than a blockchain run entirely by unpaid volunteers. The moremasternodes, the better and safer the Dash network.
As of July 2024, the Dash network has over 3000 masternodes located in over 20countries andhosted on over 140 ISPs. The blockreward is approximately 1.9 Dash, so the selected masternode receives1.4 Dash per payment or approximately 6.5 Dash per month. The blockreward decreases by 7.14% approximately once per year, so the annualearnings for a masternode owner is approximately 7% of the collateral,and will decrease over time as calculated here.See this tool to calculatereal-time payment rates, and this site for various real-timestatistics on the masternode network.
Evolution Masternodes (evonodes)#
Evolution Masternodes (evonodes) are a subset of masternodes that have been created to host DashPlatform. Evonodes are similar to regular masternodes, but have these differences:
Masternode | Evolution Masternode | |
|---|---|---|
Collateral | 1000 DASH | 4000 DASH |
Service(s) | Only Dash Core | Both Dash Core and Platform |
Voting Weight | 1 (collateral amount / 1000) | 4 (collateral amount / 1000) |
Evonodes also have higher hardware requirements than regularmasternodes due to the additional Dash Platform services they host. See DIP28 for more information about evonodes.
Masternode Concepts#
A list of available documentation appears below:
Full masternode setup guide
Information for users of hosted masternodes
Information for operators of hosted masternodes
Important concepts:
Masternodes are “registered” and begin offering services when a ProRegTxspecial transaction containing aparticular key is written to the blockchain.
The ProRegTx references the transaction id (txid) and index holding thecollateral. The IP address and port of the masternode are also defined in thistransaction.
The ProRegTx contains 2 Dash addresses (also called public keys) and one BLSpublic key, which represent 3 different roles in the masternode and defineupdate and voting rights. The keys are:
ownerKeyAddr: This is a Dash address (public key) controlled bythe masternode owner. It is different from the address used for thecollateral. Because the owner uses the private key associated withthis address to issue ProUpRegTxtransactions, it must be unique for each masternode.operatorPubKey: This is the BLS public key of the masternodeoperator. Only the operator is allowed to issue ProUpServTx transactions. Because the operator key isused during live masternode operation to sign masternode-relatedP2P messages, quorum-related messages and governance trigger votes,the BLS key must be unique for each masternode.votingKeyAddr: This is a Dash address (public key) used forproposal voting. Votes signed with the corresponding private keyare valid while the masternode is in the registered set.
Masternode owners should specify an address different from the collateral toreceive payments in the ProRegTx. The owner may optionally specify a non-zeropercentage as payment to a separate masternode operator, if applicable.
The masternode configuration can later be updated using ProUpServTx,ProUpRegTx and ProUpRevTx transactions. See Updating MasternodeInformationin DIP003 and Updating Masternode Information in this documentation for moredetails.
The process of setting up or upgrading a masternode is as follows:
Set up your server and operating system
Install the Dash software and synchronize the blockchain
Generate a BLS key pair and enter the private key on the masternode
Prepare a ProRegTx transaction
Sign the ProRegTx transaction
Submit the signed ProRegTx transaction
Step 1 can be omitted if you have an existing server. Steps 2 and 3require direct access to the masternode. Steps 3 and 4 require access toa Dash Wallet (or DMT). Step 5 requires access to the wallet actuallyholding the collateral. Step 6 requires a Dash balance to pay thetransaction fee.
Masternodes vs. mining#
Dash, like Bitcoin and most other cryptocurrencies, is based on adecentralized ledger of all transactions, known as a blockchain. Thisblockchain is secured through a consensus mechanism; in the case of bothDash and Bitcoin, the consensus mechanism is Proof of Work (PoW).Miners attempt to solve difficult problems withspecialized computers, and when they solve the problem, they receive theright to add a new block to the blockchain. If all the other peoplerunning the software agree that the problem was solved correctly, theblock is added to the blockchain and the miner is rewarded.
Dash works a little differently from Bitcoin, however, because it has atwo-tier network. The second tier is powered by masternodes (FullNodes), which enable financial privacy (CoinJoin), instanttransactions (InstantSend), and the decentralized governance and budgetsystem. Because this second tier is so important, masternodes are alsorewarded when miners discover new blocks. The breakdown is as follows:80% of the block subsidy is split between the miner and a masternodeper the distribution found here, while20% is reserved for the budget system (created by superblocks everymonth).
The masternode system is referred to as Proof of Service (PoSe), sincethe masternodes provide crucial services to the network. In fact, theentire network is overseen by the masternodes, which have the power toreject improperly formed blocks from miners. If a miner tried to takethe entire block reward for themselves or tried to run an old version ofthe Dash software, the masternode network would orphan that block, andit would not be added to the blockchain.
In short, miners power the first tier, which is the basic sending andreceiving of funds and prevention of doublespending. Masternodes powerthe second tier, which provide the added features that make Dashdifferent from other cryptocurrencies. Masternodes do not mine, andmining computers cannot serve as masternodes. Additionally, eachmasternode is “secured” by DASH collateral. Those DASH remain under the solecontrol of their owner at all times, and can still be freely spent. Thefunds are not locked in any way. However, if the funds are moved orspent, the associated masternode will go offline and stop receivingrewards.
Payment logic#
Masternodes payments all originate on the Core chain. The Core chain pays out 62.5% of themasternode portion of Core block rewards. The remaining 37.5% is put into the credit pooland used for evonode rewards on Platform. Masternodes and evonodes also receive a portion oftransaction fees on the Core chain, while evonodes receive all fees from Platform.
Because the reward distribution percentages are fixed, the number of evonodes isexpected to stabilize around a fixed number based on the total number ofmasternodes (considering the current number of ~3850 Masternodes, ~450 evonodesare expected). This is because if there are more than that fixed number of evonodes,running a regular MN will be more profitable than running an evonode, and hostswill convert their evonodes into MNs.
Reward reallocation#
Since the masternode reward reallocation hard fork activated in August 2024 at block 2128896,part of the coinbase masternode subsidy is moved into the credit pool each time a block ismined. Now, evonodes receive a single reward per payment cycle on the Core chain instead of rewardsfrom four sequential blocks, as in Dash Core v19/v20.
Masternode payment frequency and payment amount have both been affected by this fork, as described inthe following sections. Although masternodes initially saw a significant drop in rewards, amarket-driven point of equilibrium between regular masternodes and evonodes is expected whererewards are similar to what they were before the fork.
Tip
Until the network reaches a point of equilibrium, the number of masternodes and evonodes is expectedto fluctuate. As more masternodes are converted to evonodes, payment frequency (and therefore rewards)on the Core chain will continue to increase. See the Evonode FAQ,DIP28, andthe proposal approving evonodes for more information.
Payment frequency#
The frequency of Core chain masternode payments has increased as fewer payments are made per cycle.Around the time of the hard fork, the network had approximately 2600 enabled masternodes andapproximately 175 enabled evonodes. This resulted in a reduction from 3330 payments per cycle(2600 + (175 * 4)) before the fork to only 2775 (2600 + 175) after the fork. See thefollowing table for the outcomes of this change.
Pre-fork | Post-fork | Difference | Outcome | |
|---|---|---|---|---|
Payment (blocks) | 3300 | 2775 | -525 | More frequent payment |
Payment (days) | 5.73 | 4.82 | -0.91 | More frequent payment |
Payments / year | 64 | 76 | 12 | More payments |
Payment amount#
The increased payment frequency is balanced against the reduction per-block payment amount on theCore chain. This reduction resulted from the moving of some funds to the credit pool for DashPlatform. The table below compares the miner, credit pool, and Core chain masternode payments from ablock immediately beforethe hard fork with the block immediately after it.
Category | Pre-Fork | Post-Fork | Difference |
|---|---|---|---|
Miner | 0.48 | 0.48 | No change |
Credit pool | 0.54 | +0.54 | |
Masternode | 1.43 | 0.89 | -0.54 |
Total | 1.91 | 1.91 | No change |
Tip
As more masternodes are converted to evonodes, payment frequency will increase,and the difference between overall pre-fork and post-fork rewards per year onthe Core chain will decrease.
Core block rewards#
Since Dash version 0.13.0, masternode payments are entirely deterministicand based on a simple list sort algorithm. Dash version 0.13.0 implemented DIP003 which definestwo sets of masternodes.
The full set, which contains all registered masternodes that have notspent their collateral funding transactions.
The valid set, a subset of the full set which contains allmasternodes which are not marked as Proof of Service (PoSe) banned.
Each masternode in the set of valid masternodes, identified by itsregistration transaction ID, is associated with the block at which itwas last paid. If it has never received payment or was banned forfailing to meet the PoSe requirements, then the block at which it wasfirst registered or at which service was restored is used instead. Thelist is sorted in ascending order by this block height and ProRegTx hash(as a tie breaker in case two masternodes were registered in the sameblock), and the first entry is selected for payment.
The Core block reward rules apply uniformly to regular masternodes and evonodes. Each are paid onceper payment cycle and receive the same block subsidy amount.
Platform rewards#
Evonode rewards are based on participation in Platform consensus. Specifically, evonodes are paidfor the blocks they propose while in the active validator set. At the end of each Platform epoch(9.125 days), block rewards are paid to the masternode identities associated with the participatingevonodes.
Proof of Service#
Proof of Service (PoSe) is a scoring system used to determine if amasternode is providing network services in good faith. A number ofmetrics are involved in the calculation, so it is not possible to gamethe system by causing masternodes to be PoSe banned for failing torespond to ping requests by e.g. a DDoS attack just prior to payment.Each failure to provide service results in an increase in the PoSe scorerelative to the maximum score, which is equal to the number ofregistered masternodes. If the score reaches the number of registeredmasternodes, a PoSe ban is enacted and the masternode must be repairedto ensure it provides reliable service and registered in the list againusing a ProUpServTx. The current scoringrules as of Dash 0.14 are:
Failure to participate in DKG= 66% punishment
Each subsequent block reduces PoSe score by 1
Quorum selection#
In past versions of Dash, quorums of 10 masternodes were formedspontaneously to lock InstantSend transactions. As of Dash 0.14, quorumsare deterministically formed, contain more masternodes and remain alivefor a longer period of time. While they remain responsible forInstantSend transactions, the locking mechanism has changed toautomatically attempt locks on most network transactions according tothe requirements described here. Masternodes arenow also responsible for more network consensus functions, such asChainLocks. Masternode quorums are formed through aprocess of distributed key generation.Failure to participate in DKG will eventually result in a PoSe ban asdescribed above.
Masternode requirements#
DASH collateral: Hosting a masternode requires a large amount of DASH collateral.Arguably the hardest part. Dash can be obtained fromexchanges such as Poloniex, Bittrex, Kraken and LiveCoin. Shapeshift’sservice is also an excellent way.
A server or VPS running Linux: Most recent guides use Ubuntu 22.04LTS. We recommend VPS services such as Vultr and DigitalOcean,although any decent provider will do.
A dedicated IP address: These usually come with the VPS/server.
In addition to the DASH held in collateral, masternodes also haveminimum hardware requirements. For Dash versions 20.0 and higher, theserequirements are as follows:
Regular masternodes#
Minimum | Recommended | |
|---|---|---|
CPU | 2x 2 GHz | 3x 2 GHz |
RAM | 4 GB + 2 GB swap | 8 GB + 4 GB swap |
Disk | 60 GB | 80 GB |
Network | 750 GB/mth | 1 TB/mth |
Evonodes#
Evonodes have higher hardware requirements since they host Dash Platform services along with DashCore. To support the network effectively, the following requirements are recommended:
Recommended | |
|---|---|
CPU | 4x 2.4 GHz |
RAM | 8 GB + 2 GB swap |
Disk | 200 GB |
Network | 1 TB/mth |
Masternode bandwidth use varies and will grow as the network does.
