A validator is a network participant that locks up stake and runs software to propose new blocks and vote on their validity proposed by others. In consensus mechanisms based on proof of stake and Byzantine fault tolerance, validators replace the miners of proof of work: their right to take part comes from economic collateral rather than from computing power.
Validators earn rewards for correct, timely participation and face penalties and slashing for being offline or for provably dishonest behavior. This combination of reward and loss is what makes it costly to attack the network, because an attacker would need a large share of the total stake and would risk losing it.
How a validator works in consensus mechanisms
A validator works by registering stake, running a synchronized node and signing consensus messages with a dedicated validator key. The protocol selects validators, usually pseudo-randomly and weighted by stake, to perform specific duties at specific times.
The two main duties are block proposal and attestation or voting. A proposer assembles transactions into a block and broadcasts it; other validators check the block and sign votes for it. When votes representing a supermajority of stake, typically two thirds, support a block or checkpoint, the network treats it as justified and eventually final.
The following table lists the duties of a validator and what each requires from the operator.
| Duty | What the validator does | Operational requirement |
|---|---|---|
| Block proposal | Builds and signs a new block when selected | Low latency and a healthy mempool view |
| Attestation or voting | Signs votes on the chain head and checkpoints | Continuous uptime and accurate clock |
| Committee participation | Joins sync or aggregation committees when assigned | Reliable networking |
| Key management | Protects signing keys from theft and double use | Secure, single active signer |
| Software upgrades | Follows protocol upgrades and hard forks | Timely client updates |
Stake, rewards and penalties
Validator economics rest on stake as collateral. On Ethereum, a validator requires a minimum of 32 ETH; other networks set a minimum self-bond, admit only the top validators by delegated stake, or let any amount participate through delegation. The share of total stake a validator controls usually determines how often it is selected and how much voting weight it carries.
Rewards come from newly issued tokens and transaction fees, and they are paid for correct and timely duties. Penalties are small deductions for missed duties, such as being offline. Slashing is a severe, protocol-enforced loss of stake for provable faults, together with forced removal from the validator set.
| Outcome | Cause | Typical size | Effect on validator |
|---|---|---|---|
| Reward | Correct, timely proposals and votes | Small, steady yield on stake | Balance grows |
| Inactivity penalty | Missed votes or downtime | Roughly equal to rewards missed | Balance shrinks slowly |
| Inactivity leak | Network cannot finalize for an extended period | Grows over time for offline validators | Offline stake drained until finality returns |
| Slashing | Double signing or contradictory votes | Partial to large share of stake | Forced exit and loss of stake |
The most common cause of slashing is not malice but operational error: running the same validator key on two machines at once, for example during a careless failover. Both machines sign conflicting messages, which the protocol cannot distinguish from an attack.
Validator compared with miners and other roles
A validator differs from a miner in the resource it commits. A miner spends electricity and hardware on proof of work; a validator commits capital in proof of stake. A validator also differs from a delegator, who supplies stake to a validator but does not run infrastructure, and from an ordinary full node, which verifies blocks but does not vote on them.
| Role | Resource committed | Produces blocks | Main risk |
|---|---|---|---|
| Validator | Staked tokens plus infrastructure | Yes, when selected | Slashing and penalties |
| Miner | Hash rate and electricity | Yes, when it finds a valid block | Hardware and energy cost |
| Delegator | Tokens delegated to a validator | No | Shares validator slashing on many networks |
| Full node | Hardware and bandwidth | No | Operating cost only |
| Proof-of-authority signer | Approved identity | Yes, by rotation | Loss of reputation or approval |
In delegated proof of stake, token holders elect a limited number of validators, often a few dozen to a few hundred. This raises throughput and simplifies coordination, but it concentrates block production in fewer hands than open validator sets.
Running a validator in practice
Operating a validator is an infrastructure job with financial consequences. The operator must keep a node synchronized, sign duties on time, apply upgrades promptly and protect keys, because both downtime and mistakes cost money.
| Approach | Control of keys | Effort | Main trade-off |
|---|---|---|---|
| Solo validator | Full | High | Maximum independence, full operational risk |
| Staking service | Operator holds signing keys | Low | Fees and counterparty risk |
| Liquid staking protocol | Protocol and its operators | Very low | Smart contract and concentration risk |
| Distributed validator technology | Split across several operators | Medium | Fault tolerance with added complexity |
Good practice includes slashing protection databases, which refuse to sign anything that conflicts with earlier signatures, separate withdrawal credentials stored offline, monitoring with alerts for missed duties, and running a minority client to reduce exposure to a single software bug.
Risks and limitations of validator-based consensus
The main structural risk is stake concentration. If a few large staking services control a large share of validators, they could censor transactions or, above one third of stake, delay finality. Above two thirds they could finalize blocks on their own, which is why networks monitor validator distribution closely.
- Correlated failures: many validators on one cloud provider or client can go offline together and incur larger penalties.
- Long-range attacks: old keys could rewrite distant history, which proof-of-stake networks counter with checkpoints and weak subjectivity.
- Regulatory exposure: staking services may face licensing or securities questions in some jurisdictions.
- Exit queues: leaving the validator set can take time, so staked funds are not instantly liquid.
In plain words
A validator is like a notary who has posted a large security deposit. The notary checks and stamps new records, earns a fee for honest work and loses part of the deposit if caught stamping two conflicting documents.
Because cheating costs real money, validators have a strong reason to follow the rules. The key takeaway is that validators secure proof-of-stake blockchains with locked-up funds instead of with energy-hungry mining machines.
A real-world example
A small infrastructure company runs ten Ethereum validators for its own treasury, each with 32 ETH. It operates a primary server and a standby server in another data center, and it uses a slashing protection database shared by both.
One night the primary server loses connectivity. Instead of starting the standby automatically, the team’s procedure requires confirming that the primary is fully stopped first. The validators miss about an hour of duties, costing only the rewards for that hour, and no slashing occurs because the same keys never signed on two machines at once.