Finality

Short reorgs are a normal part of the design rather than a failure of it. When two validators propose blocks for the same slot, or when attestations propagate unevenly, the network can briefly disagree about the head, and the fork-choice rule resolves the disagreement by weighting attestations. The losing block is discarded and its transactions are typically included in the winning chain shortly afterwards. A user who observes a reorg of one or two blocks has seen the mechanism working, not a security event.

The fork-choice rule itself is a weight-based rule rather than a longest-chain rule. It follows the chain with the greatest attestation weight, subject to the constraint that it will not contradict a justified checkpoint. That constraint is what gives finality its force: once a checkpoint is justified, the fork-choice rule will not select a chain that conflicts with it, so a competing chain cannot win by accumulating weight alone. It would have to produce a conflicting justification, which is the slashable offence.

The comparison with Bitcoin is worth stating carefully. Bitcoin's settlement is probabilistic: a transaction's assurance grows with the number of confirmations, and there is no depth at which a reorg becomes impossible in principle, only increasingly implausible. On Ethereum the depth of a possible reorg is bounded instead by the most recent finalised checkpoint. Blocks above that checkpoint can still be reorganised, and the further a block sits above it the more attestation weight a competing chain would need to overturn it, but the bound is a structural one rather than a matter of diminishing probability. Past the finalised checkpoint there is no depth at which a reorg becomes merely unlikely, because the fork-choice rule will not select a conflicting chain at all.