Validators

In brief

“Validator” is a role, not one machine design. On Ethereum it is a protocol object with a 32 ETH activation minimum, an effective balance that can reach 2,048 ETH, keys, and duties to propose and attest in a 12-second slot clock. On Solana it is a node that votes and takes scheduled leader slots, usually backed by delegated stake and paid through a commission. On Cosmos SDK chains it is typically one of a bonded set that signs BFT votes, with delegators sharing slashing risk through an unbonding window. A validator is not automatically its operator, delegator or staker. Software, keys, uptime and client diversity all matter. The term does not mean “the server that decides whether your transaction is allowed.”

The word means different things

In proof-of-work Bitcoin, the closest everyday word is miner: someone searching for a valid block. In proof of stake, validator took over as the usual name for a consensus participant. Behind the name sit different job descriptions.

ethereum.org’s staking FAQ is precise for Ethereum: a validator is a virtual entity on the protocol — a balance, a public key, other properties. A validator client is software that holds the corresponding private key and acts for that entity. One client process can run many validators.

Solana’s staking documentation talks about validators who process transactions and write to the ledger, and about delegators who assign stake to them. The node and the stake account are separate objects.

Cosmos documentation talks about an active set of bonded validators. Holders delegate tokens to those validators. A validator that double-signs can be tombstoned — that consensus key cannot be reused on that chain.

If someone says “I run a validator,” ask: on which network, with whose stake, and with which duties?

What validators actually do

Across these systems the work clusters into a few tasks. Not every network assigns every task the same way.

Verify. Re-execute or re-check a proposed block. On Ethereum, other nodes re-run the execution payload and check the beacon-block wrapper. Invalid blocks are ignored. This is the same idea as a Bitcoin full node rejecting a miner’s invalid block.

Propose / lead. Occasionally produce the next block. Ethereum picks one proposer per slot. Solana assigns leaders on a schedule weighted by stake. CometBFT/Tendermint-style systems give proposers weighted turns among the bonded set.

Attest / vote. Sign a message that this block (or this fork) is the one to build on. Ethereum calls these attestations. Solana validators vote; Tower BFT stacks those votes into lockouts. CometBFT/Tendermint-style validators prevote and precommit.

Gossip and stay online. A validator that is powered off cannot vote. Missed votes usually mean missed rewards and, on some chains, small penalties. They do not mean the chain “rejected your user’s payment.”

Validators do not typically:

• decide whether Alice is allowed to send Bob coins, beyond “is this transaction valid under the rules?”;
• reverse a finalized transfer on request;
• replace a wallet or a smart-contract’s own permission checks.

Ethereum: keys, clients, slots

To activate, an Ethereum validator still needs at least 32 ETH. Pectra’s EIP-7251 raised the maximum effective balance to 2,048 ETH for compounding validators; it did not raise the entry requirement. The operator runs three pieces of software: an execution client, a consensus client, and a validator client. After The Merge (15 September 2022) a full node is two layers talking to each other; proposing blocks also needs the validator signing key.

Time is 12-second slots and 32-slot epochs. Each slot has one proposer. Committees of attesters are chosen so that every active validator votes every epoch without all of them voting every slot.

Keys are not “the ETH in a hot wallet.” Validator signing keys and withdrawal credentials are separate. Staking-as-a-service pages on ethereum.org note that a signing key may be entrusted to an operator while the owner keeps control of the withdrawal address or credentials. The operator can then sign bad consensus messages and trigger slashing, but the signing key alone should not let it spend or redirect the principal when withdrawals are configured correctly.

Rewards come from performing duties and, for proposers, from priority fees (and any MEV they capture) sent to a fee-recipient address. Penalties apply for being offline. Slashing applies to proven contradictory proposals or attestations, with a correlation penalty if many validators are slashed together, then a forced exit.

Hardware for Ethereum consensus is closer to “always-on reliable computer and bandwidth” than to a mining warehouse. ethereum.org’s comparison table says a validator node can be run on a normal laptop. That is a minimum-capability claim, not a recommendation to run production stake on a consumer laptop without backups.

Solana: leaders, votes, commission

A Solana validator runs client software such as Agave. It votes on forks and, when scheduled, produces blocks for its slots. Proof of History is the clock; Tower BFT is the vote-and-lockout consensus. The validator is not “PoH.”

Stake is usually delegated. Official docs: the more stake delegated, the more often the validator is chosen to write transactions; more successful work means more rewards for the validator and its delegators. The validator takes a commission — a percentage of those rewards — to cover operations. Commission is a fee on rewards, not a seizure of the delegated principal.

Official staking docs state there is no in-protocol slashing today. Delegators still take validator-performance risk (downtime means fewer rewards) and custody risk if they stake through a custodian rather than a stake account they control. A self-controlled Solana stake account separates stake authority from withdrawal authority; delegation does not require handing either authority to the validator.

A Solana validator is also operationally heavier than a typical Ethereum consensus node: Anza’s current requirements call for high-end CPU, memory, NVMe storage and fast symmetric networking. Exact specifications can change, so this article does not freeze the numbers. Hardware affordability is a decentralization dimension, not a moral score.

Cosmos SDK: bonded set and unbonding

On a Cosmos SDK chain such as the Hub (Gaia), validators are a bonded set. They sign consensus votes. Delegators share in rewards and, unlike current Solana, typically share in slashing if that validator double-signs or misses too much of a signed-block window.

The Cosmos Hub’s validator FAQ specifies a 3-week unbonding period for ATOM. The SDK staking module describes the general mechanism: when you undelegate, tokens wait out the chain’s UnbondingTime and remain slashable for offenses from the time they were bonded. Tombstoning permanently retires a double-signing consensus key on that chain.

Those numbers are chain parameters. Another Cosmos SDK chain can choose different unbonding times and slash fractions. Do not quote “21 days” as a law of all Cosmos chains without checking that chain.

Operators versus delegators

Keep the identities and people straight:

| Role | Meaning | Main exposure | | --- | --- | --- | | Validator | Protocol identity or record that proposes and/or votes | Rewards, penalties and slashing assigned by the protocol | | Validator operator | Runs machines and software and controls validator signing keys | Downtime, slashable signing mistakes, operating cost and reputation | | Delegator | Assigns stake weight to an operator’s validator without running it; one kind of staker | Validator performance, passed-through slashing where applicable and unbonding | | Staker | Broad capital role: whoever supplies coins that are actually bonded to consensus | Asset price, lockup and the risks of the chosen solo, delegated, pooled or custodial route | | Custodial staking customer | Holds an exchange or provider claim while the custodian controls the coins | Custodian failure plus the underlying validator and protocol risks |

A large operator may run thousands of Ethereum validator keys on one fleet. That looks like “many validators” in the protocol and “one operator” in the real world. Decentralization has both counts.

Software, clients and diversity

The protocol is a spec. Clients are programs that implement it. Ethereum’s security story includes multiple independent execution and consensus clients so that one bug does not look like a supermajority. On any chain, validator count alone does not reveal whether operators share one client, hosting provider or control plane.

A validator is not “the official server.” Anyone who meets the protocol’s rules can run one — subject to stake, hardware and, on some chains, a limited active set.

Uptime is a duty, not a vibe

Protocols assume validators respond on time. “Always on” is the job. Brief outages usually cost rewards. Long outages can jail a Cosmos validator or leak Ethereum stake if the chain is not finalizing. Redundant internet, disk, and key management are operational security, not optional flavor.

Decentralization is several axes

• How many independent operators?
• How concentrated is stake?
• How many clients?
• How expensive is the hardware?
• Who holds keys — operator, delegator, exchange?
• Can the set be censored by cloud providers or nation-states?

A thousand validators in one data center are not a thousand independent judges.

What this article is not saying

A validator is not a bank. It is not automatically honest because it has a website. It is not the same job on every chain. Running one is not “free yield.” The companion articles Proof of stake and Staking cover the consensus family and the holder’s choices.