Validators & Staking 32 ETH
The overview made the swap at a high level: The Merge replaced miners burning electricity with validators locking up capital. That page answered what changed. This page answers the very first practical question underneath it: how do you actually become one of the parties that gets a say?
The throughline of this whole book is how untrusting strangers agree on the state of a shared world computer — and what does it cost to run one? In proof-of-work, “buying a say” meant buying hardware and electricity. In proof-of-stake, it means one concrete action: deposit exactly 32 ETH into a contract, and the protocol mints you a validator. Everything else in this part — committees, attestations, finality, slashing, rewards — is about what that validator then does and what its stake is worth. This page builds the atom the rest of the part is made of.
A validator is a 32-ETH deposit
Section titled “A validator is a 32-ETH deposit”Strip away the mystique. A validator is not a special server, a licence, or a login. It is a record in the consensus-layer state, brought into existence by sending exactly 32 ETH to a single, well-known smart contract on the execution layer — the deposit contract.
You (someone with 32 ETH) │ send exactly 32 ETH + your keys ▼ ┌──────────────────────────────┐ │ Deposit contract (on L1) │ a plain, audited, deliberately tiny contract │ address: 0x00000000219ab...705Fa │ deployed once, in 2020 └──────────────┬───────────────┘ │ emits a Deposit log ▼ Consensus layer notices the log, and after a delay MINTS a new validator record: { pubkey, withdrawal_credentials, effective_balance, status }Two keys go into the deposit, and the split matters:
- A signing key (BLS) — the “hot” key the validator uses thousands of times a day to sign attestations and block proposals. It must live on an online machine, so it is the one most exposed to compromise.
- Withdrawal credentials — the “cold” side that says who ultimately owns this stake and where it can be withdrawn to. You can set this to a withdrawal address you control. Separating the two means a stolen signing key can misbehave (and get slashed) but cannot steal the 32 ETH — the money only ever flows to the withdrawal credentials.
That is the whole creation story. No permission, no gatekeeper, no registration with a foundation. The deposit contract is the only door in, and it is open to anyone holding 32 ETH. That permissionlessness is the point: untrusting strangers must be able to join the validator set without asking anyone.
The stake is the bond, not a fee
Section titled “The stake is the bond, not a fee”Why lock up capital at all? Because consensus needs influence to be expensive to acquire and expensive to abuse — otherwise a stranger with a laptop could spin up a million identities and outvote everyone (a Sybil attack). Proof-of-work made influence expensive by tying it to a physical, unforgeable cost: energy. Proof-of-stake makes it expensive by tying it to scarce capital you have put at risk.
Read that carefully: the 32 ETH is not spent, the way electricity is burned. It is bonded — locked, and slashable. This is the deepest substitution The Merge performed:
Proof-of-Work Proof-of-Stake ─────────────────────────── ─────────────────────────── scarce ENERGY (burned) scarce CAPITAL (bonded, at risk) cost is EXTERNAL: you pay the cost is INTERNAL: you pledge the grid, forever, to stay in very asset you'd be attacking misbehave → you already spent misbehave → your bond is SLASHED the energy; nothing extra (destroyed) — a punishment that is destroyed as punishment only exists because the bond existsThe bond is what turns “please be honest” into “it is against your own interest to cheat.” A validator that signs two conflicting blocks doesn’t just fail to earn — it can have a chunk of its 32 ETH destroyed. The stake is the collateral that makes that threat credible. Take the bond away and slashing has nothing to bite; the entire security argument of proof-of-stake collapses into a polite request.
This is also why staking pays a yield rather than charging a fee. The validator is providing a service — being honestly online and voting correctly — and the protocol pays it for that, drawing on issuance and priority fees (see Withdrawals, Rewards & the Validator Economy). The capital is the price of admission and good behaviour, and the reward is the interest on capital that behaves.
Why 32 ETH specifically?
Section titled “Why 32 ETH specifically?”Why not 1 ETH, or 1,000? The number is not arbitrary, and it is not primarily about “making staking exclusive.” It is an engineering knob that sets two things at once.
It sets the granularity of skin-in-the-game
Section titled “It sets the granularity of skin-in-the-game”The bond has to be large enough that being slashed genuinely hurts — a validator with trivial stake would shrug off penalties, and the deterrent evaporates. 32 ETH is a deliberately meaningful amount of capital to put at risk for each independent vote. Smaller, and misbehaviour is cheap; the punishment stops deterring.
It bounds the validator set and the aggregation load
Section titled “It bounds the validator set and the aggregation load”This is the constraint most people miss, and it is the sharper one. Every validator’s vote must be gathered, verified, and combined every single slot. The consensus layer leans hard on BLS signature aggregation — thousands of individual attestations get folded into one aggregate signature the network can verify cheaply. But aggregation is not free, and the number of validators the network must schedule, shuffle into committees, and aggregate over grows with the count of validators, not the total ETH.
So there is a direct tension:
lower the minimum (say 1 ETH) raise the minimum (say 1,000 ETH) ──────────────────────────── ──────────────────────────────── MORE validators for the same ETH FEWER validators, easier to → more accessible to small holders aggregate and schedule → BUT: more messages to gossip, → BUT: only the wealthy can solo-stake more signatures to aggregate, → concentration, fewer independent bigger committees, heavier verifiers per-slot work → the network strains under its own headcount32 ETH is the compromise the protocol picked: large enough that slashing stings and the validator count stays within what BLS aggregation and committee scheduling can handle each slot, small enough that staking is not reserved for institutions alone. It is the granularity of the whole system — the quantum in which “a say in consensus” is sold.
Effective balance — the number that actually votes
Section titled “Effective balance — the number that actually votes”Here is a subtlety that trips up everyone: a validator’s actual balance and its effective balance are two different numbers, and it is the effective balance that determines the validator’s weight in everything — proposals, attestations, and rewards.
Effective balance is a capped, coarse-grained version of the real balance:
- It is capped at 32 ETH. Deposit 40 ETH into one validator and only 32 of it counts toward consensus weight; the extra earns you nothing. A validator’s influence is capped at exactly one 32-ETH “unit”. (This is the pre-EIP-7251 rule this book teaches as the baseline; a later upgrade raised the maximum effective balance for consolidated validators, but the 32-ETH activation floor and the one-unit mental model remain the foundation.)
- It is coarse-grained — it moves in whole-ETH steps and uses hysteresis (a deadband), so it does not jitter with every tiny reward or penalty. This keeps the “who has how much weight” table stable enough that it does not have to be recomputed every block.
actual balance: 32.041 ETH ──┐ 32.500 ETH ──┼──► effective balance = 32 ETH (capped) 40.000 ETH ──┘ │ └─► THIS is what votes / earns / is at risk
actual balance: 30.7 ETH ──────► effective balance drops (e.g. to 30 ETH) └─► less weight, smaller rewardsWhy route everything through this synthetic number instead of the raw balance? Because consensus math must be cheap and stable. Committee selection, reward calculation, and attestation weighting all read effective balance; if that number changed by a few gwei every block, every one of those calculations would churn constantly. The cap plus hysteresis gives the protocol a slow-moving, whole-number weight per validator — which, combined with the 32-ETH minimum, means almost every validator has an effective balance of exactly 32, and the consensus arithmetic gets to treat validators as nearly-uniform units. That uniformity is a feature: it makes the whole system easier to reason about and faster to compute.
The validator lifecycle — and why there is a queue
Section titled “The validator lifecycle — and why there is a queue”A validator is not “on” the instant you deposit. It moves through a small state machine, and the reason each state exists is worth understanding.
deposited │ (waiting to be let in) ▼ ACTIVATION QUEUE ─────────► ACTIVE ─────────► EXITING ─────────► WITHDRAWABLE │ rate-limited │ │ │ │ entry │ proposes & │ voluntary exit │ funds │ │ attests; earns │ OR forced by │ claimable │ │ rewards, risks │ slashing │ to withdrawal │ │ slashing │ │ credentials- Activation queue. Newly deposited validators wait here. Crucially, entry is rate-limited — only so many validators may activate per epoch. This is not bureaucracy; it is a safety limit. If a huge number of validators could join (or leave) instantly, the validator set — and therefore the security assumptions and the committee structure — could swing violently in a single epoch. An attacker could also flood in, do damage, and flee before finality caught up. The queue caps the rate of change of the validator set, keeping finality and committee shuffling on stable ground.
- Active. The validator is doing its job: it gets assigned to committees, proposes blocks when selected, attests every epoch, earns rewards, and is exposed to slashing. This is where the 32-ETH bond is actually at work.
- Exiting. Triggered by a voluntary exit (you signed a message asking to leave) or involuntarily by slashing. Exits are rate-limited by a symmetric queue, for the same reason entries are: the set must not empty out faster than the protocol can safely absorb.
- Withdrawable. After a mandatory delay, the stake (plus rewards, minus any penalties) becomes claimable to the withdrawal credentials set at deposit time. Only now does the 32 ETH stop being a bond and become spendable money again — covered in Withdrawals, Rewards & the Validator Economy.
The single idea tying the queues together: the validator set is a security-critical quantity, so the protocol governs how fast it can grow or shrink. A chain whose voter roll can double or vanish in seconds cannot make stable guarantees about finality. The queue is the governor on that engine.
Under the hood — the deposit contract is deliberately dumb
Section titled “Under the hood — the deposit contract is deliberately dumb”You might expect the contract that mints validators to be a sophisticated staking manager. It is the opposite: it is intentionally minimal, one-directional, and boring.
// Sketch of the deposit contract's shape (illustrative, not the exact source).// The real contract is a small, heavily-audited, formally-verified contract// deployed once in 2020 and never upgraded.contract DepositContract { // A running Merkle tree of all deposits ever made. bytes32[DEPOSIT_TREE_DEPTH] branch; uint256 deposit_count;
function deposit( bytes calldata pubkey, // 48-byte BLS signing key bytes calldata withdrawal_credentials,// where the stake can exit to bytes calldata signature, // proof you hold the signing key bytes32 deposit_data_root // integrity check on the above ) external payable { require(msg.value == 32 ether, "must deposit exactly 32 ETH"); // ... append to the Merkle tree, bump the count ... emit DepositEvent(pubkey, withdrawal_credentials, /* ... */); }}Two design choices are load-bearing:
- It only accepts deposits — it never pays out. Withdrawals are handled entirely by the consensus layer, not by this contract. A contract that could send ETH out would be a giant honeypot with attack surface; a contract that can only receive and log is far harder to exploit. The one-directional design shrinks the blast radius to nearly nothing.
- It requires
msg.value == 32 etherexactly. The 32-ETH granularity is enforced right here, in onerequire. There is no “deposit whatever you like” path at the base of the system — the quantum is a hard rule of the front door.
The contract’s real job is tiny: witness a deposit and record it in a Merkle tree so the consensus layer can verify, permissionlessly, that a given validator’s 32 ETH really was posted. Everything intelligent — activation, attestation weighting, rewards, slashing, withdrawal — happens on the consensus layer reading this contract’s logs. This clean split (execution layer holds the money and logs the deposit; consensus layer runs the validator) is the same separation of concerns The Merge exploited to swap consensus without touching execution.
Solo staking vs pooled staking — the centralization pressure of 32
Section titled “Solo staking vs pooled staking — the centralization pressure of 32”The 32-ETH quantum has a social consequence the protocol designers openly acknowledge: it is a lot of money. Not everyone who wants to help secure Ethereum has 32 ETH, and running a validator also demands an always-online, well-maintained machine. This creates a fork in how people participate.
- Solo staking. You hold 32 ETH, run your own node and validator client, custody your own keys, and keep your machine online. You get the full reward, you are your own operator, and — most importantly for the network — you are an independent verifier answerable to no one. This is the ideal the protocol optimizes for: many small, geographically-spread, independent validators.
- Pooled / liquid staking. You have less than 32 ETH (or don’t want to run hardware), so you send your ETH to a pool that aggregates many people’s deposits into whole 32-ETH validators and runs them on your behalf. Liquid staking goes further: it hands you a tradeable token (representing your staked share plus accruing rewards) that you can use elsewhere in DeFi while your ETH stays staked.
Pooling makes staking accessible — a genuine good — but it applies centralization pressure precisely because of the 32-ETH granularity:
Person with 4 ETH ─┐ Person with 9 ETH ─┤ can't make a validator alone (need 32) Person with 1 ETH ─┘ │ ▼ ┌─────────────────┐ │ Staking pool / │ runs the actual validators, │ liquid staking │ holds the keys, casts the votes └─────────────────┘ │ controls the CONSENSUS BEHAVIOUR of thousands of validators funded by many peopleThe people supplied the capital, but the pool casts the votes and controls the keys. If one liquid-staking provider grows to run a large fraction of all validators, then a small number of operators effectively steer a large share of consensus — the opposite of the “many independent verifiers” the design wants. This is why the community watches staking-provider concentration closely, and why lowering the effective barrier to solo staking is an active research goal. The 32-ETH minimum keeps the validator count tractable (its job), but the very same number, by being large, nudges smaller holders toward pools — and pools re-concentrate what staking was meant to spread out. Holding both truths at once is the literacy here.
The architect’s lens
Section titled “The architect’s lens”- Why does it exist? The 32-ETH validator exists to give proof-of-stake a unit of Sybil-resistant, punishable influence — a bonded quantum of “a say in consensus” that is expensive to acquire and expensive to abuse, replacing proof-of-work’s unit of burned energy.
- What problem does it solve? It answers how untrusting strangers buy a permissionless vote without a gatekeeper: post exactly 32 ETH to one open contract and the protocol mints you a validator whose misbehaviour it can financially punish via slashing.
- What are the trade-offs? A high minimum keeps the validator count low enough for BLS aggregation and committee scheduling to handle each slot, but it prices small holders out of solo staking and pushes them into pools — trading raw accessibility (and some decentralization) for a coordinatable network. Effective-balance capping trades fine-grained fairness for cheap, stable consensus math.
- When should I avoid it? As a user, avoid solo staking when you can’t keep a machine reliably online or safely custody keys — the slashing and inactivity risk is real; pooled staking exists exactly for that case. As a designer, don’t reach for a fixed high stake-minimum in a system where validator headcount isn’t your bottleneck; the 32 is a fix for aggregation load, not a universal virtue.
- What breaks if I remove it? Remove the bond and slashing has nothing to destroy — the security model becomes an honour system. Remove the fixed minimum and let anyone stake any amount, and the validator count explodes, overwhelming per-slot signature aggregation and committee scheduling until home validators can’t keep up. Remove effective-balance capping and consensus weight tracks raw balances that jitter every block, forcing constant recomputation and letting the wealthy buy unbounded influence per validator.
Check your understanding
Section titled “Check your understanding”- Describe, step by step, exactly what happens when someone becomes a validator. What single action creates one, what contract is involved, and what two keys are supplied — and why is the key split important?
- The 32 ETH is called a bond, not a fee. Explain the difference, and why proof-of-stake’s entire security argument depends on the stake being bonded (and slashable) rather than spent.
- Give the two distinct reasons the minimum is 32 ETH specifically. Which of the two is really about signature-aggregation load, and why does raising the minimum reduce that load even while total ETH staked stays the same?
- What is effective balance, how does it differ from a validator’s actual balance, and name two properties (a cap and one other) that make it suitable for driving consensus math cheaply. What weight does a validator with 45 ETH actual balance carry?
- Why is there an activation queue at all — what would go wrong if validators could activate (or exit) instantly? Then explain how the 32-ETH granularity creates centralization pressure toward pooled/liquid staking despite pooling being a genuine accessibility win.
Show answers
- You send exactly 32 ETH to the deposit contract on the execution layer; it emits a
Depositlog; the consensus layer sees the log and, after the activation queue, mints a validator record. Two keys are supplied: a BLS signing key (hot, used constantly to attest/propose) and withdrawal credentials (cold, defining who owns the stake and where it can exit to). The split matters because a stolen signing key can misbehave and get slashed but cannot steal the 32 ETH — funds only ever flow to the withdrawal credentials. No gatekeeper is involved; the contract is the only, permissionless, door in. - A fee is spent and gone (like proof-of-work’s burned electricity); a bond is locked and slashable — still yours unless you misbehave. Proof-of-stake security rests on the threat that provable misbehaviour destroys part of your stake. That threat is only credible if there is bonded capital to destroy; if the stake were merely spent up front, slashing would have nothing to bite, and “please be honest” would have no teeth.
- (a) It sets the granularity of skin-in-the-game: the bond must be large enough that being slashed genuinely hurts, or the deterrent evaporates. (b) It bounds the validator count so per-slot BLS signature aggregation, committee scheduling, and gossip stay tractable. Reason (b) is the aggregation-load one. Raising the minimum reduces load because aggregation cost scales with the count of validators, not the total ETH — the same 32M ETH split into 1M validators (32 each) is 32× fewer signatures to gather and verify each slot than splitting it into 32M validators (1 each), even though security (total ETH at stake) is identical.
- Effective balance is a capped, coarse-grained version of the actual balance used to weight proposals, attestations, and rewards. It differs from actual balance by being capped at 32 ETH and by moving in whole-ETH steps with hysteresis (a deadband) so it doesn’t jitter every block. Those two properties make consensus math cheap and stable. A validator with 45 ETH actual balance carries an effective balance of 32 ETH — the excess earns nothing (under the 32-ETH-cap baseline this book teaches).
- Instant activation/exit would let the validator set swing violently in one epoch, destabilizing committee structure and finality, and would let an attacker flood in, do damage, and flee before finality caught up. The queue rate-limits how fast the set can change, keeping security assumptions stable. Centralization pressure: because 32 ETH is a lot of money (and needs an always-online node), holders with less than 32 ETH can’t solo-stake, so they join pools / liquid staking. Pooling is accessible and good, but the pool then holds the keys and casts the votes for many people’s capital — so if one provider grows large, a few operators steer a big share of consensus, re-concentrating exactly the influence the many-independent-verifiers design tried to spread out.