Masternode coins: how a masternode works, how to build one, and why most clones failed

A masternode is a blockchain node that locks a fixed amount of the network's coin as collateral. In return for extra services, such as instant payments, coin mixing or governance votes, it receives part of the block reward, a model Dash introduced in 2014. This guide explains how masternodes work, how a masternode coin is built, and why most of the clones from 2017 and 2018 failed.

What a masternode is

A full node checks and relays blocks. A masternode is a full node with two additions:

• A collateral deposit backs each masternode; on Dash, a regular masternode needs 1,000 DASH held in one specific unspent output.
• The node performs services that the protocol depends on.

The collateral is large and visible on the blockchain, so the network can give masternodes duties, group them into quorums, and penalize or drop nodes that stop serving.

Dash added masternode services over the years:

• InstantSend. A quorum of masternodes locks the inputs of a transaction within seconds, which prevents a double spend before a miner includes the transaction in a block.
• ChainLocks. A quorum signs the first block it sees at each height. The signature makes chain reorganizations much harder, so many 51% attacks no longer work.
• CoinJoin mixing. Masternodes coordinate mixing rounds, a feature Dash first called PrivateSend.
• Governance. Each masternode votes on budget proposals, and a treasury share of each block reward pays for the approved proposals.

Dash later added evonodes, which lock 4,000 DASH and also host Dash Platform, the network's data and application layer.

Masternodes compared with other node models

The last row explains why few new projects choose masternodes today. In modern proof of stake, validators produce blocks directly, lose stake through slashing when they misbehave, and accept delegation from small holders. Those features cover most of what masternodes added on top of proof of work. The how to create an altcoin guide compares current chain frameworks.

Parts of a masternode coin

Collateral and registration

Early designs only checked for an output of the right size and a signed broadcast message. Dash's improvement proposal DIP3 moved registration onto the blockchain, where a special provider transaction now records four items:

• the collateral output
• the owner key, which can update the registration
• the operator key, which signs service and quorum messages
• the payout address

A separate voting key signs governance votes. Because the owner key and the operator key are different, a holder can keep the collateral in cold storage while a hosting company runs the server.

Payment selection

Each block pays one masternode from a fixed queue, so every node can check that the right masternode got paid. On Dash, the queue is sorted by the block height of each node's last payment, and a paid node moves to the back of the queue.

Proof of service

The network needs proof that each masternode is online and answers requests. Dash raises a node's proof-of-service (PoSe) score each time the node fails a duty, such as taking part in quorum key generation. A node whose score reaches the limit is banned from payments until the operator repairs it and sends an update transaction. A weak proof-of-service check lets operators collect rewards from servers that barely work and add no security.

Quorums and threshold signatures

Dash forms long-lived masternode quorums through distributed key generation. Members use BLS threshold signatures, so part of a quorum can produce one short signature for an InstantSend lock or a ChainLock. The quorum code is the most complex and security-critical part of the system, and it is the main difference between a serious masternode design and a copy that only renames the coin.

Reward split and treasury

The block reward is shared among miners or stakers, masternodes and often a treasury. On Dash, the treasury budget takes 20% of the block subsidy, and miners and masternodes share the other 80%. A large masternode share sends more rewards to large holders. A treasury funds development without a premine, but it needs a working governance process.

The 2017 and 2018 masternode coin wave

During the 2017 and 2018 market, hundreds of projects forked Dash or PIVX code, changed the name and the settings, and advertised yearly masternode "returns" of large percentages, while websites ranked coins by masternode ROI. Most of these projects are now abandoned or delisted.

The "return" was paid in newly issued coins. If nobody outside the network wants the coin, new coins dilute existing holders and the price falls, so a high ROI measured inflation, not profit. Many clones also had these problems:

• Many clones kept none of Dash's quorum services, so their masternodes did no useful work.
• Founders held large premines and sold coins to buyers who needed collateral.
• The teams stopped merging security fixes from the original code, so known flaws stayed open.
• The coins traded in small volumes on small exchanges that later closed.

A project whose pitch is mainly "buy collateral and earn X% a year" looks like the yield promises in the crypto MLM software guide, and regulators may treat such an offer as an investment contract.

When a masternode design still fits

Collateral-backed service nodes suit three cases:

• A network needs a known set of service providers that is costly to fake, for instant settlement, data storage or relaying.
• A network wants on-chain governance where voting weight follows locked collateral.
• A team extends an existing proof-of-work chain and wants finality without a move to proof of stake.

Similar ideas appear today under other names, such as staked service providers, oracle networks with staked operators, and restaking networks that secure outside services. For a new project, these models usually cost less than a classic masternode fork. The DeFi staking platform guide covers staking on smart-contract chains.

How to build a masternode coin

1. Define the service. Write down what masternodes will provide that the network cannot get another way. If there is no answer, the project does not need masternodes.
2. Choose a base codebase. A fork of a maintained project, such as Dash Core or PIVX, gives you mature code but obliges you to merge changes from the original project for as long as the chain runs. Check the license and the size of the changes you will maintain.
3. Set the economics. Decide the collateral size, reward split, emission schedule, treasury share and any premine. Model inflation and the dilution of holders without masternodes over five years.
4. Change the network identity. Create a new genesis block, chain settings, ports, address prefixes and network magic bytes, so nobody can confuse the chain with its parent.
5. Build and test the services. Test quorum formation, threshold signatures, proof of service and payment selection on a public testnet with outside operators.
6. Order a security review of consensus and quorum code from specialists in node software, not only in smart contracts.
7. Launch with documentation for node operators, exchanges and wallets, and a plan for coordinated upgrades.

Hosting and centralization

Many masternode holders do not run servers and let hosting services run the nodes for them. With separate owner and operator keys, the holder keeps control of the collateral.

Hosting concentrates risk. If a few hosting providers run most masternodes, quorum security depends on those companies' servers and honesty. Shared masternode pools let small holders combine funds to reach the collateral amount, but the pool operator then controls the collateral, which adds custody risk.

A design that relies on masternode quorums should measure how concentrated the operators are, and it can reward operators who spread across regions and providers. Proof-of-stake networks track client and hosting concentration among validators in the same way.

Cost and timeline estimates

A fork that only changes settings compiles quickly, and forks of this kind produced most of the dead coins. A masternode chain with working quorum services needs these skills:

• C++ engineers who know Bitcoin-based codebases.
• DevOps staff for seed nodes and explorers.
• Wallet developers.

A reasonable estimate is a team of four to six engineers for six to twelve months before mainnet, with permanent maintenance after the launch. The estimate is based on the scope above, not on quotes. Security review of consensus code is specialized and expensive, and exchanges take longer to integrate coins with unusual node software. The crypto exchange listing guide covers what exchanges check.

Frequently asked questions