The Vote That Arrives Late Is Still a Vote, Just a Cheaper One

Your attestation went out on time. Signed correctly, pointing at the right head, broadcast without error. Then the network had a bad moment. The attestation hit the chain one slot late, and now you're watching a smaller reward land in your balance while the validator in the next row collected the full amount for an identical vote. Same correctness. Different pay. That gap is not a bug.

Ethereum's Gasper consensus protocol, the system governing the proof-of-stake chain since the Merge, weights attestations according to when they land relative to the slot they were cast in. Understanding why requires looking at what an attestation actually does inside the protocol, not just what it is.

What an Attestation Is Actually Doing

An attestation is a validator's signed vote on two things simultaneously: the current head of the chain (the LMD-GHOST vote, which is the fork-choice mechanism that follows whichever chain tip has the most recent validator support) and a pair of checkpoints it believes should be linked (the Casper FFG vote, the finality layer that permanently locks in past history). These are the two pillars of Gasper, and every attestation carries both.

The LMD-GHOST component feeds the fork-choice rule. When the protocol needs to decide which of two competing chain tips is canonical, it counts the latest messages from validators and follows the heavier fork. A late attestation may arrive after a fork-choice decision has already propagated. It still counts toward future decisions, but it missed the moment it was most useful.

The Casper FFG component feeds finality. Validators vote to justify and finalize epoch checkpoints, where an epoch is a fixed window of 32 slots. These votes are aggregated across the entire epoch, so a single-slot delay is less catastrophic for finality than for head-tracking. It still affects how efficiently the network aggregates signatures, though.

The Slot Window and the Three Deadlines

Gasper gives validators a specific participation window. Each validator is assigned to attest during a particular slot and is expected to have that attestation included in the chain within a defined number of slots afterward. Inclusion distance is the gap between the slot the attestation references and the slot it actually lands in.

The reward formula penalizes inclusion distance directly. A simplified version looks like this:

``` attestationReward = baseReward * (1 / inclusionDistance) ```

Inclusion in the very next slot (distance = 1) yields the full base reward. Distance = 2 yields half. Distance = 3 yields a third. The denominator grows linearly, so the reward curve is a hyperbola: steep at the front, flattening toward the tail. By the time an attestation squeaks in at the maximum allowed distance, the reward has shrunk to a fraction of what it would have been.

Three practical deadlines are baked into this.

  1. The target deadline. The attestation must reference the correct epoch boundary block. Miss this and the target reward component is zeroed out entirely, regardless of inclusion distance.
  2. The head deadline. For the head-vote component to pay out, the attestation's stated chain head must actually be the canonical head at the time of inclusion. Stale heads, caused by slow propagation, forfeit this component.
  3. The inclusion distance deadline. The attestation must land within the epoch. An attestation for slot N that doesn't appear on-chain before the epoch ends earns nothing.

Those three components (target, head, source) are scored independently. A validator can get two out of three. It can get one. Each miss is a separate deduction.

A Worked Scenario: Two Validators, One Rough Slot

Say validators Alice and Bob are both assigned to attest in slot 400 of an epoch. The correct head block was produced at slot 399, and both sign attestations pointing at it.

Alice's node propagates cleanly. Her attestation lands in the block at slot 401, giving her an inclusion distance of 1. She collects the full reward: target correct, head correct, source correct, distance minimal.

Bob's node had a brief peer connectivity hiccup. His attestation didn't reach enough aggregators in time, so no block proposer at slot 401 picked it up. It finally lands in the block at slot 403, a distance of 3. His source and target votes are still correct (the checkpoints haven't changed). But by slot 403, the canonical head has moved on. The block Bob cited as head is now two slots behind, so his head-vote component pays nothing. His inclusion distance penalty cuts the base reward to one-third. He ends up collecting roughly one component out of three at a fraction of the base rate.

Same epoch, same correctness on the fundamentals. Radically different payout. Bob didn't do anything wrong in a Byzantine sense; the network just had a bad moment.

Why the Protocol Deliberately Builds In This Pressure

This might seem cruel. Why punish validators for propagation hiccups they didn't cause?

The answer is incentive alignment, and honestly the design is correct. Gasper is a Byzantine fault-tolerant system that assumes the network is partially synchronous, meaning messages eventually arrive but with uncertain delay. The protocol cannot tell whether Bob's late attestation was caused by a bad peer connection, a slow machine, or a validator quietly trying to observe both forks before committing. The reward decay is the protocol's blunt instrument for making equivocation expensive and promptness cheap.

If late attestations paid the same as timely ones, a rational validator could delay, watch which fork was winning, and then vote for it. That would gut the very property LMD-GHOST is designed to enforce. The reward decay is a tax on observation time, and it should be.

There is a secondary effect worth naming: aggregation efficiency. Attestations from the same committee for the same slot can be aggregated into a single BLS signature (a cryptographic technique that compresses hundreds of individual votes into a few bytes on-chain). Aggregation only works when attestations arrive together, in time for a block proposer to bundle them. Stragglers that miss the aggregation window force proposers to include them individually, bloating block size and increasing state computation. The reward structure nudges validators toward tight timing, which in turn keeps aggregate signature sizes manageable.

One Honest Caveat About What This Misses

The simplified inclusion-distance formula above captures the intuition well, but Ethereum's actual reward accounting is more layered. Since the Altair upgrade, the spec moved to a participation flags model, where each of the three components (timely source, timely target, timely head) is tracked as a binary flag per validator per epoch, and the weights assigned to each flag differ. Timely target carries more weight than timely head, which carries more than timely source.

The practical implication: a validator that consistently nails source and target but misses head timing is losing a smaller share of rewards than the simple hyperbolic formula suggests. Head timing is worth the least of the three in absolute terms. Validators running monitoring dashboards (Rated Network is a useful public tool for this) often see "missed head" as the dominant inefficiency, and it matters less per miss than people assume.

Also worth noting: the proposer boost, introduced in the Bellatrix fork to resist certain short-range reorg attacks, gives the current slot's block an artificial weight advantage in the fork-choice calculation. This interacts with attestation timing because very late attestations for a slot are competing against a fork-choice that has already been nudged by the boost. The sensitivity isn't purely about rewards, it shapes which chain actually wins.

What a Validator Operator Actually Watches

Are you running a validator and your attestation effectiveness is sitting above 95%? You're fine. The median well-run home validator lands around 98 to 99% on well-connected hardware. Anything below 90% consistently signals a real problem: bad peers, disk I/O bottlenecks, or a client that's falling behind on sync.

The levers are limited but concrete. Geographic proximity to a majority of other validators (most of whom cluster on major cloud providers) shortens propagation paths. Keeping the beacon client on an NVMe drive rather than a spinning disk eliminates the single most common source of processing lag. Running a minority client, Teku or Nimbus rather than the dominant Prysm, doesn't directly improve timing but reduces correlated failure risk across the network.

Gasper's reward decay works the way compound interest works in reverse: the losses are individually small, almost invisible per epoch, and then one day you compare your total rewards to a well-tuned operator's and the gap is uncomfortable. The validators that understand the rhythm collect the difference quietly, epoch by epoch, while everyone else is busy blaming the network.