Becoming a validator: deposits, duties, and rewards

From miner to validator

In the previous guide you saw why proof of stake replaced proof of work: instead of burning electricity to make attacks expensive, the network asks participants to lock up capital that can be destroyed if they cheat. This guide zooms in on the person doing the locking — the validator — and walks its entire life: the deposit, the waiting line, the everyday duties, and the paycheck.

Picture the contrast. A proof-of-work miner is a warehouse of humming ASICs converting megawatts into hashes. A validator is almost boring by comparison: 32 ETH locked as a stake, plus a small always-on computer running two programs that mostly just sign short messages saying *"this block looks valid to me."* No noise, no heat — the security comes from the money at risk, not from the energy spent.

Why exactly 32 ETH, and not 1 or 1000? The deposit is a Sybil-resistance knob. If identities were free, an attacker could spin up millions of fake validators and outvote everyone. Pricing each validator at 32 ETH makes fake identities costly, yet keeps the number small enough that the active set is huge — by 2025 the chain had more than a million validators securing over 30 million ETH — which is what keeps voting power spread out and the chain decentralized.

The deposit and the lifecycle

Becoming a validator starts on the execution layer: you send 32 ETH to the deposit contract, attaching three things — a BLS signing public key (the validator's on-chain identity), withdrawal credentials (an address that says where the money may eventually return), and a signature proving you control the key. The beacon chain watches the deposit contract and, once it sees your deposit, schedules your validator for activation.

{
  "pubkey":                 "0x933ad9...8f7329267a8811c397529dac52ae1342ba58c95",
  "withdrawal_credentials": "0x010000000000000000000000 3cd4a...e91",
  "amount":                 32000000000,        // 32 ETH expressed in gwei
  "signature":              "0xa1f3...c0",      // BLS signature over the above
  "deposit_data_root":      "0x9b4f...2a"
}

From there a validator moves through a fixed set of states. It can't jump straight to active — entries and exits are rate-limited by a churn limit, so only a bounded number of validators can join or leave per epoch. That deliberate slowness keeps the active set from changing faster than the protocol's safety assumptions can tolerate.

deposited            # 32 ETH seen by the deposit contract
  -> pending         # waiting in the activation queue (rate-limited by churn)
  -> active          # attesting every epoch, occasionally proposing
       -> slashed    # caught cheating -> forcibly exited (next guide)
  -> exiting         # voluntary exit requested, draining the exit queue
  -> withdrawable    # stake unlocked and swept to the withdrawal address

Slots, epochs, and the two duties

Time on the beacon chain is chopped into 12-second slots, and 32 slots make one epoch (≈ 6.4 minutes). Two things happen on this clock. Every slot has exactly one block proposer. And every epoch, every active validator is sorted into a committee and owes the network one attestation — a vote on what it currently believes the chain looks like.

An attestation is not a vague thumbs-up; it is a precise three-part vote: the source checkpoint (the last justified point it agrees on), the target checkpoint (the epoch boundary it is voting to justify), and the head block (the tip of the chain it currently sees). Those three votes are what the finality machinery in the next guides feeds on. You sign your attestation and gossip it; specialized aggregators then combine thousands of identical votes into a single BLS-aggregated signature so the chain doesn't drown in messages.

1. At the start of the epoch, your validator client learns which committee it's in and which slot it's assigned to attest in.
2. When that slot arrives, it looks at the chain and decides the current head block (using the fork-choice rule).
3. It builds the vote: source checkpoint, target checkpoint, head block.
4. It signs the vote with its validator key and broadcasts it to peers.
5. Aggregators bundle many matching votes into one attestation that a later block proposer includes on-chain.

The proposal lottery

Who gets to propose each slot? A lottery. The protocol maintains a shared, unpredictable seed called RANDAO: each block proposer mixes in a fresh random contribution, so over time no single party controls the result. For every slot, the seed is used to pick one proposer from the active set, weighted by effective balance — bigger stakes win proportionally more often.

# How the protocol picks the proposer for a slot (rejection sampling).
def compute_proposer_index(validators, active_indices, seed):
    i = 0
    total = len(active_indices)
    while True:
        candidate = active_indices[compute_shuffled_index(i % total, total, seed)]
        random_byte = hash(seed + to_bytes(i // 32))[i % 32]   # 0..255
        eff = validators[candidate].effective_balance
        # accept with probability proportional to effective balance
        if eff * 255 >= MAX_EFFECTIVE_BALANCE * random_byte:
            return candidate          # this validator proposes the slot
        i += 1                        # rejected, try the next candidate

Notice effective balance, not raw balance, drives both proposal odds and attestation weight. Effective balance is capped (classically at 32 ETH) and quantized in 1-ETH steps with hysteresis, so it changes only in clean increments. A practical consequence: under the original design, rewards that pushed your balance above 32 ETH did not compound — your weight stayed pinned at 32 until you withdrew the surplus.

Where the rewards come from — and why they shrink as more people stake

A validator earns from two separate streams. Consensus-layer rewards are freshly issued ETH the protocol pays for doing your duties — attesting on time, proposing when chosen, and serving on the sync committee. Execution-layer rewards are the priority tips and any MEV captured inside the block you propose; many validators outsource block-building via MEV-Boost to maximize this. The first stream is steady and small; the second is lumpy and only arrives on the rare slots you propose.

The consensus reward each epoch is built on a single quantity called the base reward, and its formula hides the most important fact in all of validator economics: the base reward is inversely proportional to the square root of the total amount staked.

# Ethereum consensus spec, all values in gwei
EFFECTIVE_BALANCE_INCREMENT = 1_000_000_000        # 1 ETH
BASE_REWARD_FACTOR          = 64

def base_reward_per_increment(total_active_balance):
    return EFFECTIVE_BALANCE_INCREMENT * BASE_REWARD_FACTOR \
           // integer_sqrt(total_active_balance)

def base_reward(effective_balance, total_active_balance):
    increments = effective_balance // EFFECTIVE_BALANCE_INCREMENT   # 32 for a full validator
    return increments * base_reward_per_increment(total_active_balance)

# Because of the integer_sqrt, base_reward ~ 1 / sqrt(total stake):
# quadruple the ETH staked and the per-validator reward halves.

Put real numbers in. With about 32 million ETH staked, `integer_sqrt(total)` makes the base reward per 1-ETH increment ≈ 358 gwei, so a full 32-ETH validator earns ≈ 11,400 gwei per epoch. Multiply by ~82,000 epochs in a year and that's ≈ 0.94 ETH/year, about a 2.9% yield — before tips and MEV. Now quadruple the stake to 128 million ETH: the square root doubles, the base reward halves, and that yield falls to roughly 1.5%. More stakers means more total security but a thinner slice each — by design.

That base reward is split by weight across the duties. Of every 64 parts: the target vote earns 26 (it's the one that drives finality, so it pays most), the source vote 14, the head vote 14, sync-committee duty 2, and the proposer who includes your attestation gets 8. Timeliness is everything — a vote that lands late, or names the wrong target, earns a reduced reward or none at all.

Cashing out, and the four ways to take part

Money locked in must be able to come out. Since the Capella/Shanghai upgrade (April 2023), a validator with 0x01 (execution) withdrawal credentials gets automatic partial withdrawals — anything above 32 ETH is swept to its withdrawal address every few days — and a full withdrawal by submitting a voluntary exit, draining the exit queue, and then having its remaining balance swept once it becomes withdrawable. The same churn limit that throttled entry also throttles the exit, which is exactly what stops a malicious supermajority from attacking and fleeing in one block.

Not everyone runs their own box. There are four broad ways to stake, trading control for convenience:

1. Solo staking — you run your own node and hold your own keys. Full rewards, full control, and full responsibility for uptime; this is the most decentralizing choice.
2. Staking-as-a-service / pools — you supply 32 ETH (or a share of it) but a service operates the node for a fee, so you avoid the hardware and ops burden.
3. Liquid staking — you deposit any amount into a protocol (e.g. Lido) and receive a token (like stETH) that represents your staked position and can be used elsewhere in DeFi while it earns.
4. Centralized exchange — fully custodial: the exchange holds the keys and the ETH, and pays you a yield. Easiest, but you are trusting a third party.

Whichever path, the software underneath is the same shape: a consensus client (the beacon node that follows proof of stake and tells you your duties) paired with a validator client that holds the signing keys and produces attestations and blocks. The one discipline you must never skip is keeping slashing-protection enabled, so that a crash, a restart, or a botched failover can never make your key sign two conflicting messages — the offense that triggers the punishment we turn to next.