The Fork You Can't See Coming
You're running an Ethereum node at 2 a.m. Two blocks arrive at roughly the same slot, each claiming to be the legitimate child of the previous one. Your client picks one, the network picks one, and within a few slots the losing branch is forgotten like a bad draft. Fine. That's fork choice. But a deeper question sits underneath all of that: when does a block stop being probably correct and become mathematically impossible to reverse without destroying a third of all staked ETH?
That moment is finalization. The machinery that produces it is called Gasper, and it is not a single algorithm.
It's a marriage of two distinct systems: LMD-GHOST, which picks the current chain head slot by slot, and Casper FFG, which periodically locks in checkpoints that can never be rolled back. Understanding finalization means understanding how those two layers talk to each other, and specifically what conditions Casper FFG demands before it will stamp a checkpoint as justified and then finalized.
Two Algorithms, One Chain
LMD-GHOST (Latest Message Driven Greediest Heaviest Observed SubTree) is the fork-choice rule. At every slot, each validator casts a vote called an attestation for whatever block it sees as the chain head. LMD-GHOST tallies those votes by validator weight, always following the branch with the heavier accumulated stake behind it. Fast, slot-by-slot, and deliberately designed to produce a single canonical tip even when the network is slightly asynchronous.
Casper FFG operates on a coarser timescale. It works with epochs, each containing 32 slots. At the boundary of every epoch sits a checkpoint, which is simply the first block in that epoch (or the most recent block if that slot was empty). Casper FFG asks validators to cast a second kind of vote, a supermajority link, connecting one checkpoint to the next. When more than two-thirds of total staked ETH votes for a link between checkpoint A and checkpoint B, checkpoint B becomes justified. When checkpoint B then becomes the source of a supermajority link to checkpoint C, checkpoint B graduates to finalized.
That's the skeleton. The flesh is in the numbers.
The Exact Threshold and Why Two-Thirds
The two-thirds supermajority isn't arbitrary. It comes directly from the Byzantine Fault Tolerance literature, the body of computer science research concerned with systems that must reach agreement even when some participants are lying, crashed, or actively malicious. If two conflicting checkpoints were both finalized, then by the pigeonhole principle, more than one-third of validators must have voted for both, which would slash their entire stake. The protocol makes equivocation economically ruinous rather than just technically impossible.
So: at least 2/3 of total active validator weight, measured in staked ETH, must attest to a supermajority link before justification can happen. Not 2/3 of online validators. Not 2/3 of the validators in a given committee. Two-thirds of the entire active set.
With roughly 900,000 validators on mainnet, you'd need attestations from validators controlling more than 600,000 validator slots worth of stake to clear the threshold in a single epoch. Think of it like passing a constitutional amendment where every abstention counts as a no vote. The network manages it because each epoch's 32 slots are each assigned a committee, and those committees' attestations are aggregated and included in subsequent blocks.
A Worked Scenario: From Proposal to Finalized
Call the epochs N, N+1, and N+2.
At the start of epoch N, the checkpoint is block B_N. Validators begin attesting to a supermajority link from the most recently justified checkpoint to B_N. By the time epoch N ends, assume those attestations have been aggregated and included in blocks, and more than two-thirds of staked ETH has voted for that link. B_N is now justified.
Epoch N+1 begins. Its checkpoint is B_N+1. Validators now attest to a supermajority link from B_N to B_N+1. If, again, more than two-thirds of stake votes for this link before the epoch closes, B_N+1 becomes justified, and crucially, B_N, having served as the source of a successful supermajority link, is now finalized.
Finalization always lags two epochs behind the present. A block proposed in epoch N can't be finalized until epoch N+1's checkpoint is justified. Under normal conditions with a healthy, online validator set, that means finality arrives in roughly 12 to 15 minutes. Two epochs of 32 slots each, at 12 seconds per slot, gets you to 12.8 minutes as a baseline, with a few minutes of slack for attestation inclusion.
If the validator participation rate drops below two-thirds, justification stalls entirely. The chain keeps producing blocks via LMD-GHOST, but nothing is irreversible. This is the inactivity leak scenario, and Ethereum handles it by gradually draining the stake of non-participating validators until the active set shrinks to a size where the online validators again represent two-thirds of the remaining stake. Brutal, but self-correcting. I'd argue it's one of the more elegant economic designs in the protocol.
What People Get Wrong About "Finality"
The common misconception is treating LMD-GHOST's chain head as a proxy for finality. It isn't. A block sitting at the tip of the canonical chain is the most likely correct block, not an irreversible one.
This matters practically. An exchange crediting a large ETH deposit after six confirmations is accepting probabilistic security, not Casper-grade finality. That's fine for small amounts. For a transaction worth eight figures, waiting for the finalized checkpoint that covers that block is the only honest answer. Six confirmations for a $50 transfer is reasonable; six confirmations for a $50 million settlement is a risk management failure dressed up as standard procedure.
A second confusion: people conflate the justified and finalized states. Justified means two-thirds of stake endorsed a link to this checkpoint. Finalized means two-thirds of stake then endorsed a link from this checkpoint. You need both steps. A checkpoint can sit justified for a full epoch and not yet be finalized.
Third, and this one trips up developers: finalization is a property of checkpoints, not of individual blocks. Every block between the previous finalized checkpoint and the newly finalized one is implicitly finalized too, because any chain that doesn't include them can't have produced the finalized checkpoint. But the Casper FFG mechanism itself only directly tracks the epoch-boundary blocks.
The Chain Head's Role: LMD-GHOST as the Setup Act
Casper FFG can't operate on its own. It needs a canonical chain to define what the checkpoints even are. LMD-GHOST provides that. Every time a validator decides which block to attest to, it runs LMD-GHOST, finds the heaviest subtree, and that determines both its attestation target (for Casper FFG) and its attestation head (for LMD-GHOST). The two votes travel together in a single attestation message.
The coupling is the elegant part. LMD-GHOST prevents long-range attacks by making the chain tip responsive to recent stake weight. Casper FFG prevents short-range reorganizations of already-justified history. Neither algorithm alone is sufficient: LMD-GHOST without finality is just an expensive probabilistic chain, and Casper FFG without a fork-choice rule has no way to define which branch it's finalizing.
Gasper's contribution is defining precisely how these two interact. LMD-GHOST always respects finalized history (it will never build on a chain that contradicts a finalized checkpoint), and Casper FFG always operates on the chain LMD-GHOST has selected. They're not rivals. They're a clean division of labor, and the protocol breaks badly if you try to substitute either half.
What Slashing Protects
The finalization guarantee is only as strong as the punishment for violating it. Casper FFG defines two slashing conditions for validators. The first is double voting: casting two different Casper FFG votes for the same target epoch. The second is surround voting: casting a vote whose source-target range completely contains or is contained by a previous vote's range.
A validator caught in either condition loses a large portion of its 32 ETH stake and gets forcibly exited. If many validators are slashed simultaneously, an additional correlation penalty can reach the full 32 ETH. The correlation penalty is what makes coordinated attacks uniquely expensive: the more validators participate in the attack, the larger each individual penalty becomes.
So here's the question worth sitting with: if you're running infrastructure and you need to know whether a block is safe to treat as settled, what's the actual answer? Check whether the epoch containing that block has a finalized checkpoint above it. Everything before that line is, by Casper FFG's guarantees, as permanent as the protocol can make it.
The real insight Gasper offers isn't speed. Ethereum deliberately traded speed for something more valuable: a quantifiable, stake-backed definition of irreversibility. In a system where trust is supposed to be optional, finalization isn't a feature bolted on for institutional comfort. It's the load-bearing wall.