Grinding the Beacon: Why Ethereum’s RANDAO Randomness Is Biasable by a Proposer Willing to Burn a Slot

Ethereum’s beacon chain derives its in-protocol randomness from a RANDAO accumulator. Every block proposer contributes a single, verifiable value — a BLS signature over the current epoch number — and the protocol mixes it into the accumulator with XOR. The design is elegant, and it is also biasable. A proposer who is willing to forgo one block proposal can choose between two possible RANDAO states: the one that includes its contribution, and the one that does not. That is a one-bit choice per slot, and it is enough to grind the beacon.

This article walks through the mechanism, the exact cost of the attack, what the bias buys an adversary, and why the protocol has no dedicated penalty for selective withholding. The argument is not that Ethereum’s randomness is broken. It is that the security margin depends on an economic assumption — that burning a proposal is more expensive than the expected gain from biasing the next epoch’s duties — and that assumption deserves to be stated explicitly rather than assumed away.

How the RANDAO accumulates

The beacon chain maintains a RANDAO value in the randao_mixes field of the beacon state. Each block includes a randao_reveal, which is the proposer’s BLS signature over the epoch number, signed with the validator’s normal signing key. When the block is processed, the protocol verifies the signature against the proposer’s public key and then mixes the hash of the signature into the accumulator:

mix = xor(get_randao_mix(state, epoch), hash(body.randao_reveal))
state.randao_mixes[epoch % EPOCHS_PER_HISTORICAL_VECTOR] = mix

This is the process_randao function as described in the Eth2 Book’s treatment of randomness. Two details matter for biasability. First, the proposer has almost no choice about what it contributes: the signature is deterministic given the epoch number and the validator’s secret key, and any other value fails verification. Second, the proposer does have a choice about whether to contribute at all. If it withholds its block, the RANDAO is not updated for that slot. The Eth2 Book states this plainly: “If there is no block in a slot then the RANDAO is not updated.”

The accumulator is therefore a sequence of XOR operations, one per proposed block, with gaps wherever a slot is missed. The current value is stored alongside a history of past epoch-boundary values in randao_mixes, which allows historical committee assignments to be recomputed and historical attestations to be slashed months later.

The proposer’s one-bit choice

Consider a proposer that controls the last slot of an epoch. The RANDAO value at the end of that epoch seeds the duties for epoch N+2, via get_seed() and the MIN_SEED_LOOKAHEAD parameter. The proposer knows the accumulator state before its slot. It can compute two candidate end-of-epoch states: one with its reveal mixed in, one without. It cannot choose an arbitrary value, but it can choose between those two.

That is the grinding primitive. The adversary does not need to invert the hash or forge a signature. It needs only to decide whether to publish a valid block. If the two resulting seeds produce different duty assignments, and one of them is more favorable to the adversary, it withholds. If the included state is more favorable, it proposes.

The Eth2 Book notes a subtle design choice that limits this: using XOR rather than a hash for mixing, and signing over the epoch number rather than the slot number, makes the ordering of two adversarial proposers in the last two slots of an epoch irrelevant. As Justin Drake’s notes are quoted there, the commutativity of XOR means that an attacker with validators V0 and V1 in the last two slots gets the same result whether they appear as V0, V1 or V1, V0. This “fractionally reduces an attacker’s choices.” It does not eliminate the choice; it removes one permutation of it.

What the bias buys

RANDAO seeds proposer selection, committee assignment, and sync committee participation. The Eth2 Book lists these duties explicitly and explains why unpredictability matters: an attacker with advance knowledge of future proposers can mount targeted denial-of-service attacks, bribe specific committees, register advantageous validator indices, or censor transactions. The lookahead is bounded by MIN_SEED_LOOKAHEAD and MAX_SEED_LOOKAHEAD, so under normal conditions duties are not predictable more than about two epochs ahead.

A one-bit bias per epoch does not hand the adversary control of the next committee. It shifts the distribution. The relevant question is whether the shift is large enough to matter for a specific downstream use. For proposer selection, the seed determines which validator is chosen for each slot. A biased seed can increase the probability that a particular validator — or a set of validators controlled by the same entity — is selected. The magnitude depends on the stake fraction and the number of candidate seeds the adversary can generate.

The adversary’s grinding power scales with the number of consecutive slots it controls at the end of an epoch. With one slot, it has two candidate seeds. With two consecutive slots, it has up to four, though the XOR commutativity reduces the distinct outcomes. The Eth2 Book’s discussion of lookahead makes the same point from the defensive side: if an attacker can predict the RANDAO output further ahead than MIN_SEED_LOOKAHEAD normally allows, it can strategically exit or deposit validators to gain control of a committee or a run of proposal slots. The protocol defends against this by delaying activations and exits by MAX_SEED_LOOKAHEAD, set to 4, so that new randomness from honest proposers arrives before the manipulated validators become active.

The Eth2 Book’s own summary is that validators “are able to bias the RANDAO to a small extent, but this is not significant problem in practice.” That is a judgment about magnitude, not a proof of impossibility. It is worth being precise about what “small” means and under what assumptions it holds.

The cost of burning a slot

A proposer that withholds its block loses the proposal reward for that slot. It also misses the opportunity to include attestations and other operations that generate additional rewards. The exact penalty depends on the current reward schedule, which is a function of total effective balance and participation rates. The protocol does not apply a special penalty for RANDAO withholding; the proposer simply misses the slot, and the normal inactivity and missed-slot accounting applies.

This is the crux of the economic argument. The cost of grinding is the foregone proposal reward plus any missed attestation rewards if the validator is also offline for its attestation duties. The benefit is whatever advantage the biased seed confers on future duties. If the expected benefit exceeds the cost, a rational adversary grinds. If it does not, the adversary proposes honestly.

There is no protocol-level mechanism that detects selective RANDAO withholding as distinct from an ordinary missed proposal. A validator that is offline due to a network fault and a validator that is deliberately withholding to bias the seed are indistinguishable to the protocol. Both result in no block and no RANDAO update. The Eth2 Book notes that missed or orphaned block proposals “directly affect the RANDAO’s output” and that network conditions, node faults, and maintenance downtime all contribute entropy. That is true, but it also means the protocol cannot separate accidental misses from adversarial ones.

What the formal literature says

The retrieved literature on this specific question is thinner than the mechanism warrants. The Eth2 Book is the most detailed retrieved source, and it treats biasability as a known property with a bounded practical impact. It does not provide a formal lower bound on the bias or a quantified comparison of grinding cost to grinding benefit.

The arXiv paper retrieved for this article, “Resource Pools and the CAP Theorem” by Lewis-Pye and Roughgarden, is about a different problem: a general framework for comparing permissionless protocols and a CAP-style dichotomy between adaptive protocols and those with finality properties. It does not analyze RANDAO bias. It is relevant only as a reminder that the formal tools for reasoning about these protocols are still being developed, and that claims about “small” bias often rest on informal arguments rather than proved bounds.

EIP-4788, which exposes beacon block roots to the EVM, is relevant for a different reason. It makes the beacon chain’s state — including the RANDAO accumulator as part of the block root — accessible to execution-layer contracts. That expands the set of downstream consumers of consensus randomness. A smart contract that reads a beacon root and derives a random value from it inherits the RANDAO’s bias properties, whether or not the contract author is aware of them. The EIP’s motivation section lists staking pools, restaking constructions, smart contract bridges, and MEV mitigations as use cases. Each of those inherits the trust assumptions of the randomness source.

Where the argument actually lands

The claim that RANDAO is biasable is not controversial. The Eth2 Book says it. The question is whether the bias is bounded tightly enough that downstream users can treat the randomness as unbiased for their purposes.

Three conditions have to hold for the bias to be negligible:

1. The cost of burning a proposal slot must exceed the expected value of the best achievable bias.
2. The adversary must not control enough consecutive end-of-epoch slots to generate a large set of candidate seeds.
3. Downstream consumers must not amplify the bias by using the seed in ways that magnify small probability shifts.

Condition 1 is economic and depends on reward levels, which change with network participation and protocol upgrades. Condition 2 is a function of stake distribution and proposer scheduling. Condition 3 is a design responsibility for application developers, not a protocol guarantee.

None of these conditions is enforced by the protocol. They are assumptions. The protocol provides a verifiable, unpredictable-looking value with a known one-bit-per-slot bias channel. Whether that is sufficient depends on what you are using it for.

Practical implications for protocol reviewers

If you are reviewing a protocol that consumes Ethereum’s RANDAO — directly or through EIP-4788 — the relevant questions are:

• What is the maximum bias a single proposer can introduce into the value you consume? If you use the raw seed, it is the one-bit choice described above. If you hash the seed with other inputs, the bias may be diluted or transformed.
• What is the cost to an adversary of burning the relevant proposal slots? If the value you are securing is large relative to the proposal reward, the economic assumption may not hold.
• Does your protocol have a fallback if the randomness is biased? A commit-reveal scheme, a threshold signature, or a verifiable delay function can change the trust assumptions, but each has its own costs and failure modes.
• Are you relying on the seed being unpredictable more than two epochs ahead? The lookahead parameters bound this under normal conditions, but an adversary with a large stake fraction or the ability to mount sustained DoS against proposers may extend its forecasting horizon.

The RANDAO is not a random oracle. It is an accumulator with a known bias channel and an economic cost model. Treating it as a random oracle is a modeling error. Treating it as unusable is an overcorrection. The useful position is to state the bias bound, state the cost assumption, and check whether your application’s security argument survives when both are made explicit.

FAQ

Can a proposer choose an arbitrary RANDAO contribution?

No. The randao_reveal is a BLS signature over the epoch number, verified against the proposer’s public key. The proposer has exactly one valid contribution per epoch. The choice is whether to include it, not what it is.

Does the protocol penalize RANDAO withholding differently from a missed proposal?

No. A withheld block and an accidentally missed block are indistinguishable to the protocol. Both result in no RANDAO update for that slot. The proposer loses the proposal reward and any associated attestation inclusion rewards, but there is no dedicated slashing condition for selective withholding.

How much can one proposer bias the next epoch’s duties?

One proposer in the last slot of an epoch can choose between two candidate seeds. The effect on duty assignments depends on how the seed maps to selection probabilities. The Eth2 Book describes the bias as “small” and “not significant problem in practice,” but does not provide a formal bound. The magnitude scales with the number of consecutive end-of-epoch slots the adversary controls.

Does EIP-4788 make the bias worse?

EIP-4788 exposes beacon block roots to the EVM, which makes the RANDAO accumulator accessible to smart contracts. It does not change the bias properties of the RANDAO itself, but it expands the set of consumers that inherit those properties. A contract that derives randomness from a beacon root should account for the same bias channel.

Is there a proposed fix?

The retrieved sources do not describe a specific protocol-level fix for RANDAO biasability. The design choices noted in the Eth2 Book — XOR mixing and signing over the epoch number rather than the slot number — reduce the adversary’s options but do not eliminate them. Alternative randomness schemes such as verifiable delay functions or threshold signatures have been discussed in the broader literature, but the retrieved sources do not provide a comparative analysis.