What Is a Blockchain Validator?
A validator is a node that proposes new blocks, checks the transactions inside them, and votes on whether the network should accept them, and it only gets to keep doing that job if enough other validators agree it's playing by the rules. That's the whole function in one sentence. Everything else, staking, penalties, committees, algorithms, exists to make that voting process trustworthy among strangers who have no reason to trust each other by default.
The core loop
Picture a blockchain as a shared, append-only ledger that many independent computers hold copies of. Someone has to decide, block by block, what gets added next, which transactions are valid, in what order, and when the addition becomes permanent. That's the job validators do, on a rotating or randomly-selected basis:
- A validator is chosen (by turn, by random selection, or by some other rule specific to the network) to propose the next block, a batch of pending transactions, bundled and ordered.
- Other validators check the proposal: is every transaction properly signed, does the sender actually have the funds or permissions the transaction requires, is the block built on the correct prior block.
- If the proposal checks out, validators vote to accept it. Once enough of them, a quorum, typically a supermajority, have voted yes, the block is considered final: it won't be reversed, rewritten, or contested later.
That loop repeats continuously. No single validator decides anything alone; agreement is the product of many independent nodes converging on the same answer, which is what makes the ledger hard to falsify: a would-be attacker has to convince a quorum, not one gatekeeper.
The rules governing how proposals get made, checked, and voted on are called a consensus mechanism. Different blockchains use different ones, but the role validators play, propose, verify, vote, is common to almost all of them.
Why validators exist at all
The reason any of this needs a validator role, rather than one trusted server, comes down to a hard problem: how do you get a group of computers run by mutually distrusting parties, spread across the internet, to agree on a single shared history, without a referee? Two broad families of answer exist.
Proof-of-work chains (Bitcoin being the best-known example) don't use validators in this sense at all. Instead, "miners" compete to solve a computationally expensive puzzle, and whoever solves it first gets to propose the next block. The security comes from cost: rewriting history would require redoing an enormous amount of wasted computation, which is prohibitively expensive to fake at scale.
Validator-based chains, proof-of-stake, proof-of-authority, and BFT-style (Byzantine Fault Tolerant) designs, replace that computational cost with an economic or reputational one. A validator typically has to bond stake: lock up some amount of the network's native asset as collateral before it's allowed to participate. If it behaves honestly, it keeps that stake and may earn compensation for the work of validating. If it behaves dishonestly, proposing conflicting blocks, voting on both sides of a fork, going offline for extended periods: the protocol can destroy or confiscate part of its stake, a mechanism generally called slashing. The validator has something to lose, and that's what disciplines its behavior, instead of a puzzle that burns electricity.
This is the distinction worth holding onto: proof-of-work spends computation to make cheating expensive; validator-based consensus spends bonded capital instead (Byzantine Fault Tolerant designs specifically add a mathematical bound on how many participants can misbehave before the network's guarantees break down). Neither approach requires trusting any single party, both just locate the cost of trust in a different place.
What it costs to be a validator
Running a validator is not free, and the costs aren't only financial.
- Bonded stake. Most validator-based networks require locking up a meaningful amount of the native asset before a node can participate. This capital is at risk, reducible or destroyable if the validator misbehaves, which is the point: the stake is what the validator has to lose.
- Uptime. A validator that's offline can't propose or vote, and a network with too many absent validators struggles to reach the quorum it needs to finalize blocks. Many networks penalize prolonged downtime separately from active misbehavior, because an idle validator is still one the network was counting on.
- Correct behavior under penalty. Provable misbehavior, double-signing two conflicting blocks, voting for two different histories at the same height, is the kind of fault slashing exists to punish, even when it comes from a misconfigured setup rather than malice.
- Operational overhead. Running the software reliably, keeping it patched, keeping keys secure, and monitoring for the network's specific failure modes is ongoing work, not a one-time setup step.
None of this is unique to any one chain. It's the general shape of what "being a validator" costs, across the networks that use this model.
Where Solidus fits into this
That framing matters for the one distinction this page exists to draw: installing the solidus-node binary is not the same thing as becoming a validator.
Running the software gets a node onto the network as a participant that can sync and observe the chain. Becoming a validator, one of the nodes that actually proposes blocks and votes on consensus, requires two additional things: bonding stake, and registering a decentralized identifier (DID) as part of validator eligibility.
This is worth saying plainly rather than letting it blur, because "download and run a node" is a much easier claim to make, and a much weaker one, than "become a validator." They are not interchangeable, on Solidus or on any chain that gates validator status behind staking.
Roadmap](/shipped-vs-roadmap). For what makes Solidus's specific approach to validator eligibility different from staking alone, gating admission on a verified human identity rather than capital by itself, see Proof-of-Identity.
The compact reference version of everything on this page lives in the Lexicon: Validator.