Live prices are currently unavailable — the exchange feed could not be reached and no recent cached reading is held.

Bitcoin Data GuideBitcoin Reference

Research · Ethereum

Validators and attestations

An attestation is a validator's vote on what the chain looks like. It carries a source checkpoint, a target checkpoint and a head block, and it is aggregated across a committee so that a whole committee's opinion arrives as one signature.

Last reviewed 2026-09-21Source: Ethereum Consensus Specs (Phase 0) and the beacon-chain API specificationStructure and duties as specified; no participation rates or performance figures are claimed.

What an attestation contains

An attestation is a signed statement about three things at once. It names a source checkpoint and a target checkpoint, which is a claim about which chain the validator considers justified; it names a head block, which is a claim about the current tip; and it carries the validator's index and a signature over the whole statement. The three-part structure is what lets the same message serve both finality and fork choice.

The source and target pair is the part that drives finality. A validator is asserting that it has seen a chain in which the source checkpoint is justified and the target checkpoint is its descendant. When two-thirds of the total staked weight makes the same assertion about a target, that target becomes justified, and a later attestation with the justified checkpoint as its source finalises it. The finality page in this cluster works through that progression in detail.

The head vote is the part that drives fork choice. It tells the network which block the validator believes is the current tip, and the fork-choice rule weights those votes by the stake behind them. Because the head vote is separate from the checkpoint votes, a validator can express a view about the tip while still voting for the checkpoints it considers justified, which keeps the two mechanisms from interfering with each other.

Committees and aggregation

The roles a validator can be assigned in a slot and what each one contributes.
RoleHow oftenWhat it contributes
Block proposerOne validator per slot, selected by the protocolBuilds and signs the block, including the attestations it has received
AttesterEvery validator, once per epochSigns a source, target and head vote for its assigned slot
AggregatorA subset of each committeeCollects the committee's attestations and produces one aggregate signature
Sync committee memberA rotating subset, for a fixed periodSigns the head of the chain so light clients can follow it cheaply

Last reviewed 2026-09-21Source: Ethereum Consensus Specs, Phase 0 — Honest ValidatorDuty assignment as specified; the selection is derived from the chain's randomness.

Aggregation is what makes the design scale. Each committee member signs its own attestation, and a designated aggregator collects the signatures from its committee and combines them into a single aggregate. Because the signatures are BLS signatures over the same message, they can be combined into one signature that verifies against the combined public keys of the signers. The block proposer then includes one aggregate per committee rather than one attestation per validator, and the block's size stays bounded as the validator set grows.

The aggregation step introduces a dependency that is worth naming. If the aggregator for a committee is offline, the individual attestations still exist but they do not reach the chain as an aggregate, so the validators in that committee lose the reward for being included even though they did their job. The protocol mitigates this by selecting several aggregators per committee, so a single failure does not silence a committee, but it does not eliminate the dependency. This is one of the reasons validator clients are run with redundant infrastructure.

The committee assignment itself is derived from the chain's randomness, which is generated by the validators themselves through a commit-and-reveal scheme. Each epoch a set of validators reveals a value derived from a secret they committed to earlier, and the revealed values are mixed into a seed. Because the commitments are made before the secrets are known, a validator cannot choose its reveal to influence the resulting assignment without risking a penalty, and the seed is unpredictable until the reveals are in.

What an attestation earns

Attesting correctly earns a reward, and the reward is not a flat payment. It is weighted by how quickly the attestation reaches the chain and by how closely the validator's vote matches the rest of the network. An attestation included in the next block earns more than one included several blocks later, and a vote for a checkpoint that the rest of the network also votes for earns more than a vote for a minority view. The effect is to reward both timeliness and agreement rather than mere participation.

The penalty side mirrors the reward side. A validator that fails to attest loses the reward it would have earned, and during a period when the chain is not finalising, the penalty for being offline increases. That escalation is deliberate: it makes an inactivity event expensive for the validators who are absent while the network is degraded, and it gives the remaining validators a strong incentive to restore finality rather than wait. The staking rewards and penalties page in this cluster sets out the components in full.

The reward structure has a consequence for how validators are operated. Because timeliness is rewarded, a validator that is reachable and well-connected earns more than one that is technically online but slow to propagate its attestations. That is why the operational advice for validators concentrates on network quality and clock accuracy rather than on hardware specification: the consensus layer's work is small, and the latency of getting a signature to the right peer is what varies.

Sources and references

The attestation structure, duty assignment and aggregation described above are taken from Ethereum's consensus specification.

  • Attestation structure and validator duties. Ethereum Consensus Specs, Phase 0 — Honest Validator: the source, target and head votes, and the duties a validator is assigned.
  • Committees, aggregation and the beacon chain's load. Ethereum Consensus Specs, Phase 0 — The Beacon Chain: attestations are the primary source of load, and committees are how the load is bounded.
  • The beacon-chain API a validator client uses. Ethereum Beacon APIs, Beacon Node API Specification: the endpoints through which a validator obtains its duties and submits its attestations.
  • Rewards and penalties for attestations. ethereum.org, Rewards and penalties: how attestation rewards are weighted and when penalties escalate.

Related reading