The Slot Closes, But the Votes Keep Coming
Your attestation is signed, broadcast, and gone. You watch the next block land and your vote isn't in it. Packet loss, a slow peer, a router in São Paulo having a bad afternoon. The slot boundary passed. Most people assume the vote is dead.
It isn't. What Ethereum actually does with that straggler is more interesting than most explainers bother to explain.
LMD-GHOST Doesn't Care About Punctuality the Way You Think
Ethereum's fork choice rule is LMD-GHOST: Latest Message Driven Greediest Heaviest Observed SubTree. Ungainly name, precise mechanism. When a validator's client picks which chain tip to build on, it doesn't replay every vote ever cast. It takes only the latest message from each validator, that single most-recent signal, and uses it to weigh the branches of the block tree.
The "voting deadline" people talk about is really a slot boundary. Attestations are ideally included in the very next block, one slot later, and the protocol rewards timely inclusion. Miss that window and the attestation's reward shrinks, a declining inclusion-delay penalty baked into the reward formula.
The fork choice weight, though, runs on a different ledger entirely.
An attestation that arrives one, two, or several slots late still gets included in a block eventually. Once it's on-chain, LMD-GHOST counts it. The rule is indifferent to the timestamp; it cares only about which block the vote pointed to and whether that's still the validator's latest known message. Think of it like water pressure in a pipe: the system doesn't care when a molecule entered, only where it's pushing.
Here's the concrete mechanics. The network is choosing between two competing chain tips, Block A and Block B, both children of a common parent. Block A holds 320 validators' latest messages. Block B holds 290. LMD-GHOST picks A. Now 40 attestations that pointed to B were delayed and arrive late, included in a subsequent block. Those 40 validators now have an on-chain latest message. The tally shifts: A at 320, B at 330. The fork choice flips. That's not a bug. That's the mechanism absorbing new information as the chain grows, exactly as designed.
What keeps this from becoming chaos is finality. Ethereum's Casper FFG layer runs alongside LMD-GHOST and checkpoints the chain every 32 slots, one epoch. Once a checkpoint is finalized by a two-thirds supermajority of total staked ETH, no reorg can touch it. Late attestations can only shuffle the fork choice above the most recent finalized checkpoint, which in practice means the last minute or two of blocks. Below that line, the chain is concrete.
So the real answer to "what happens to competing attestations after the deadline" is this: they get counted, they can move the fork choice tip, and finality bounds them from doing anything catastrophic.
One subtlety worth flagging. LMD-GHOST's "latest message" constraint means a validator's vote only moves forward, never backward. Say a validator attested to slot 4,201,336, but her client is slow and the attestation for slot 4,201,340 also arrives late. Only the later slot's message counts in the fork choice. The earlier one is superseded. This shuts down a straightforward attack: flooding the network with old votes to manipulate the tally does nothing, because stale messages are automatically discarded in favor of the freshest known signal from each validator. It's a clean design. I'd argue it's underappreciated.
The place people genuinely misread this: they assume the inclusion-delay penalty means late attestations are "rejected." They are not. The penalty is economic, not epistemic. The network still wants the information; it just pays less for it the later it arrives, as an incentive to keep validators running tight, well-connected infrastructure. Penalizing latency while still accepting the data is the right call, and any system that discards late-but-honest votes outright would be throwing away real security signal to enforce a bureaucratic deadline.
So, have you checked your validator's inclusion rate lately? Consistently above 95% on-time, your node is doing its job. Regularly below 80%, something is wrong with your setup, your peering, or your hardware, and the reward hit compounds quietly over months.
Ethereum's consensus is probabilistic at the tip and deterministic at finality. The tip wiggles over short time horizons because late attestations are part of the signal, not noise to be filtered out. That's the system absorbing real-world network conditions while the finality layer holds the floor.
The delayed vote from São Paulo eventually counts. The chain just makes sure it can't unsettle anything already settled.