What is proof of stake?

Proof of stake (PoS) is a category of consensus mechanism that protects a blockchain through staked assets and protocol rules. Participants place the asset the network specifies into a state the protocol can act on, becoming or supporting a validator. The protocol then assigns block proposal and voting duties among validators, and issues rewards or applies penalties according to whether those duties are carried out correctly.

"Stake" here is not company equity, and it does not mean that holding a token lets anyone change the ledger directly. Staking mainly does two things: it limits who can influence consensus, and it gives rule-breakers assets they stand to lose. A block a validator proposes still has to be checked by other nodes. A block that breaks transaction or protocol rules does not become valid just because its proposer staked a large amount.

The problem proof of stake addresses

An open network cannot allocate the right to keep records by counting accounts or nodes, because the same participant can create any number of identities. Proof of stake ties influence over consensus to a stake that is verifiable inside the protocol, so creating empty accounts in bulk cannot by itself obtain equivalent weight.

It also has to solve the coordination problems every blockchain shares: who proposes the next batch of transactions, how other participants check and vote on it, which branch is adopted when several valid blocks appear at once, and when a transaction reaches the final state the protocol defines.

Unlike proof of work, proof of stake generally does not require participants to keep performing large numbers of hash attempts to compete for block production. It builds its security constraints from locked or committed assets, validator messages, and rewards and penalties. That usually lowers the energy and specialized equipment consensus computation needs, but it does not remove costs such as servers, network communication, software maintenance or concentration of participation.

From staking to block confirmation

Proof-of-stake networks differ widely in selection algorithm, voting threshold and penalty rules. What follows is a common process, not a fixed sequence that every network follows identically.

Joining the validator set

A participant first stakes the amount of assets the protocol requires and runs validator software. The stake may come from the validator, or from delegators — people who assign their stake weight for a validator to use without necessarily transferring control of the assets. Some networks set a minimum amount, an activation wait and an exit period; others allow smaller amounts to be delegated directly to an existing validator.

Becoming a validator is not simply a matter of placing assets in an address. A validator usually also has to safeguard signing keys, keep equipment online, receive blocks promptly, and send protocol messages within the required time. Whether staked assets can be withdrawn at any time, how long exiting takes, and whether delegators keep control of their assets are all determined by the particular network and service arrangement.

Assigning block proposers

The protocol assigns participants from the current validator set to propose new blocks. A common approach combines random selection with stake weight: higher stake weight usually means a greater chance of receiving duties over a period, but it does not guarantee selection every time.

Randomness is used to reduce the risk that the next proposer is manipulated or attacked in advance. A given network may introduce slots, rounds, committees or rotating proposers; a committee is a group of validators the protocol selects temporarily to carry out voting duties together. "A lottery weighted by stake" therefore summarizes only part of these mechanisms and cannot stand in for the actual protocol rules.

Checking the block and sending votes

The selected proposer assembles and broadcasts a candidate block. Other validators or nodes check conditions such as transaction signatures, asset state, block format and proposal eligibility. Validators carrying consensus duties also send signed messages stating which block they consider valid, which branch should currently be followed, or which checkpoint can be confirmed. A checkpoint is a reference block the protocol periodically selects as the focus of concentrated voting.

These signed messages are often called attestations or votes. The protocol counts them by each validator's effective stake weight rather than simply counting messages. Splitting the same stake across several validator identities does not normally create additional total weight out of nothing.

Handling competing branches and finality

Network latency or a misbehaving proposer can leave nodes temporarily seeing several valid candidates. A fork choice rule determines which branch a node currently follows, commonly based on the stake weight represented by validators' latest votes. A recent branch can still change as new messages arrive.

Some proof-of-stake networks additionally have explicit finality rules: once voting passes a defined threshold, a block or checkpoint is marked as finalized. Conflicting final results generally mean that enough stake weight has violated the security assumptions the protocol relies on; on networks with slashing, provably conflicting signatures may also trigger it. Other networks may use a different confirmation model, so Ethereum's voting thresholds or timing cannot be treated as the standard for every PoS network.

Stake weight is not direct voting by token holders

"More stake means more influence" captures only part of the relationship. What the protocol actually counts is usually the valid messages that have entered the consensus process, satisfy activation conditions and are signed by validator keys — not the balance of every asset in a wallet.

A token holder may run a validator, delegate assets to another validator, or use a staking service. Delegation usually changes the weight a given validator represents, but a delegator does not necessarily run a node, check each block or send votes. For example, Cardano's delegation mechanism lets holders retain the right to use their assets while assigning block production weight to a stake pool. When a provider operates on someone's behalf, asset custody arrangements, withdrawal permissions, operational failures and fees add risks that sit outside the protocol.

Stake weight is also not a general voting right over the rules. Validators judge blocks according to the software they currently run; whether a protocol upgrade is adopted also depends on how node operators, developers, applications, users and other participants choose software and chains. Consensus execution and protocol governance are related, but they are not the same thing.

Rewards, ordinary penalties and slashing

Proof of stake generally uses rewards to encourage validators to propose blocks on time, send correct votes and stay online. A validator that misses duties may not receive the corresponding reward, and some networks also deduct a small amount of staked assets. Consequences of this kind, arising from being offline or late, can be distinguished from penalties for serious misconduct.

Slashing is a heavier penalty applied to behaviour that can be clearly proven, such as the same validator signing conflicting blocks where that is not permitted. The protocol can confirm such behaviour from the signature evidence a validator leaves behind, and may deduct part of the stake, force an exit, or do both.

Not every proof-of-stake network has the same slashing conditions, and not every software failure causes the loss of an entire stake. The specific outcome depends on network rules, the type of violation, how many validators violated at the same time, and the service agreement a user has accepted. Handing assets to a staking service also does not mean a platform automatically absorbs protocol risk and provider risk.

Finality comes with security assumptions

A block explicitly marked as final is usually harder to replace than a recent block that has not been finalized, but "final" still rests on the protocol's security assumptions. If enough stake weight violates the rules at the same time, if validator software has a serious defect, or if the network stays partitioned for a long time, the system may stop finalizing, or even produce conflicting results.

Ethereum is one example: it uses the stake weight represented by validator votes to choose the current chain head, and forms finality through checkpoint votes. Reaching finality requires support from a defined proportion of stake weight, and the conditions for preventing finalization differ from those for overturning a block that has already been finalized. This illustrates that proposal, fork choice and finality are separate stages; it does not mean other PoS networks use the same thresholds.

A node that rejoins the network after a long time offline may also need a trusted recent checkpoint so that it is not misled by a long history produced by former validators. This "weak subjectivity" problem and the ways of handling it are not the same in every PoS protocol, but it shows that syncing a new node on a staked chain is not necessarily solved by comparing data from the genesis block alone.

What a large stake can do

A participant controlling more effective stake weight usually gains more proposal or voting influence. They may delay certain transactions, affect recent branch selection, or prevent the network from reaching finality. At higher thresholds, combined with specific misconduct, they may also produce conflicting confirmations or attempt to reorganize history.

But a staking advantage cannot make an invalid transaction take effect. Full nodes that follow the rules and check blocks independently still reject blocks with forged signatures, assets created out of nothing, or violations of state transition rules. A large stake influences the choice and confirmation among valid candidates; it is not an administrator permission that bypasses every protocol rule.

Actual attack capability depends on the specific protocol's voting thresholds, slashing conditions, validator distribution, client implementations and network state. A "51% attack" cannot be transferred directly from proof of work to every proof-of-stake network, and the balance of a single address does not reveal who actually controls validator keys and votes.

The main trade-offs

Proof of stake avoids the continuous large-scale hash competition of proof of work, but it shifts security resources from external computation to protocol assets and validation infrastructure. Common trade-offs include:

• Stake concentration: large holders, custodial platforms, staking protocols that pool substantial delegated assets, or a small number of node operators may accumulate considerable validation weight.
• Barriers to entry: minimum stake amounts, hardware requirements, technical maintenance and exit waiting periods can limit direct participation.
• Penalty risk: key misuse, duplicate signing, software misconfiguration or provider failures can lead to lost rewards or slashing.
• Liquidity and price risk: assets may be unavailable during staking or an exit period, and their market value also changes.
• Software and network dependencies: client defects, an excessive share held by a single implementation, or a network outage can take many validators offline or cause them to send incorrect messages at the same time.
• Governance and recovery: recovering from a serious attack may require nodes, applications and the wider community to coordinate outside the protocol on which history to adopt.

Staking yield is not risk-free interest. Rewards come from a network's issuance, fees or other protocol income. Staking itself can carry asset price, lock-up and penalty risk, and using a staking service or contract may add provider and smart contract risk.

Proof of stake and related ideas

Proof of stake is a category of consensus mechanism; staking is the tool it uses to constrain participation rights and behaviour. Not everything called "staking" takes part in base-layer consensus: platform lock-up rewards, liquidity incentives in decentralized finance products, or governance token locking may also be called staking while serving a different purpose and carrying different risks.

Delegated proof of stake generally lets holders delegate weight to validators, which run the infrastructure and take part in block production or voting. That name covers a range of different designs, so the word "delegated" alone does not reveal the election method, the number of validators, how assets are held, or who bears penalty liability.

Proof of stake also does not mean node validation disappears. A full node without any stake can still check whether blocks follow the rules; it simply does not usually carry the proposal and voting duties that require validator signatures. Whether someone stakes, whether they run a validator, and whether they run a full node that only validates data are three separate questions.

FAQ

Does holding tokens automatically make someone a validator?

Usually not. A participant also has to meet staking, activation, software and key management requirements, or delegate assets to a participant that provides validation services. The specific rules are set by the network.

Does more stake always produce more blocks?

Not necessarily. Stake weight usually improves the chance of being selected or voting over a period, but a single selection may involve randomness, and a protocol may also set weight caps, committees or other limits.

Does proof of stake use no energy at all?

No. Validators and nodes still have to run servers, store data and communicate. It usually avoids the large-scale hash competition of proof of work, but energy consumption does not fall to zero.

Are slashing and investment loss the same thing?

No. Slashing is the protocol deducting stake for provably improper behaviour; losses from falling market prices, service fees, inability to exit promptly or contract defects belong to other categories of risk.

Is a finalized block absolutely unchangeable?

Not unconditionally. Finality means that, under the participation ratio, network and software assumptions the protocol sets, overturning a block requires serious misconduct at high cost. When those security assumptions are broken, coordination outside the protocol may still be needed.

Related concepts

Continue with consensus mechanism, proof of work, block and blockchain node, or return to the Crypto Glossary.

Sources

• NISTIR 8202: Blockchain Technology Overview — the general definition of proof of stake, stake weight and block publication.
• Ethereum.org: proof of stake — validator duties, proposals, votes, fork choice, finality and examples of staking penalties.
• Ethereum.org: rewards and penalties — offline penalties, slashable behaviour and Ethereum's recovery mechanisms.
• Ethereum.org: proof-of-stake FAQs — fork choice, finality, weak subjectivity and the boundaries of Ethereum-specific design.
• Cardano Docs: delegation — delegation, the right to use assets and stake pool duties in another PoS implementation.