Delegated Proof of Stake

What it is

Delegated Proof of Stake (DPoS) is a consensus mechanism where instead of every staker validating directly, token holders vote for a limited number of delegates (often called witnesses, block producers, or validators) who actually run the nodes and produce blocks. It trades some decentralization for speed and efficiency: fewer, elected validators can typically produce blocks faster and cheaper than a large, permissionless validator set.

How it works

1. Token holders use their holdings as voting weight to elect a fixed-size set of block producers (commonly somewhere between 20 and 100), often by staking or "approval voting" for candidates.
2. The elected producers take turns, usually in a round-robin schedule, proposing and signing blocks within their term.
3. Voters can typically re-delegate or change their vote at any time, and producer rankings update continuously based on current vote totals — so underperforming or misbehaving producers can be voted out.
4. Block rewards (new token issuance plus transaction fees) are distributed to producers and, in many implementations, shared back with the voters who backed them, creating an ongoing incentive to vote actively.
5. Because the validator set is small and known, blocks can be produced and finalized quickly with a simple communication pattern between producers, giving DPoS chains higher throughput and lower latency than large permissionless proof-of-stake or proof-of-work sets.
6. Some designs add a standby list of runner-up candidates who can be rotated in immediately if an elected producer goes offline or is removed by a vote.

Why designers use it

• Achieves much higher transaction throughput and lower latency than large validator sets, since coordination overhead scales with the number of block producers.
• Gives token holders an ongoing, low-friction accountability lever — bad or lazy producers can be voted out quickly rather than needing a hard fork.
• Lowers the hardware and bandwidth bar for individual holders to participate, since they delegate rather than run infrastructure themselves.

Failure modes

• Voter apathy is common: most token holders don't actively vote or reassess their votes, letting the same small clique of producers entrench themselves indefinitely.
• Vote-buying and cartel formation are easy when producers can share rewards with voters — producers effectively bid for votes, which can favor collusion over competence.
• The small validator set concentrates power: a handful of colluding producers can censor transactions or reorder blocks in ways a large permissionless set would find much harder.
• Plutocracy risk: since voting power is proportional to token holdings, a few large holders (exchanges, founders, whales) can dominate producer elections regardless of broader community preference.

What to check before using it

• Look at real voter turnout and producer concentration over time, not just the theoretical voting design.
• Check whether producers are required to run independent infrastructure/geography, or whether several "different" producers are secretly run by the same operator.
• Understand the reward-sharing rules between producers and voters, since these shape whether votes reflect merit or just bribery.
• Verify how quickly a misbehaving or censoring producer can actually be removed in practice, including any minimum notice period or vote-weight thresholds.