If you run validators, wallets or payment flows on Ethereum, the useful question is not whether an attacker can "hack the chain" but which outcomes are actually reachable. According to Ethereum's own documentation on proof-of-stake attack and defense, there are three classes of outcome an attacker might realistically target: reorgs, double finality or finality delay.
That framing matters because it replaces a vague fear with a short list you can plan around. It also rules out two common misconceptions, which this guide covers first.
What an attacker cannot do
A common misconception is that a successful attacker can generate new ether or drain ether from arbitrary accounts. Neither is possible, because all transactions are executed by all the execution clients on the network.
For a transaction to take effect it must satisfy basic validity conditions—being signed by the sender's private key, having sufficient balance and similar checks—or it simply reverts. So even a consensus-layer attacker does not get a master key to balances or a mint. The consensus layer decides ordering and finality; the execution layer still enforces validity everywhere.
The three realistic outcomes
The source document is explicit that the realistic targets fall into three classes. They differ sharply in cost, severity and how the community would respond.
| Outcome | What happens | What the source says about cost or risk |
|---|---|---|
| Reorg | Blocks are reshuffled into a new order, possibly adding or removing blocks in the canonical chain | The most extreme form, finality reversion, is only possible if more than ⅓ of total staked ether is destroyed |
| Double finality | Two forks finalize at the same time, creating a permanent schism | Theoretically possible for an attacker willing to risk 34% of total staked ether |
| Finality delay | The network cannot reach the conditions needed to finalize sections of the chain | No threshold stated in the source |
Reorgs: ordering, censorship and MEV
A reorg is a reshuffling of blocks into a new order, perhaps with some addition or subtraction of blocks in the canonical chain. A malicious reorg might ensure specific blocks are included or excluded, which allows double-spending or value extraction by front-running and back-running transactions, commonly called MEV.
Reorgs can also be used to keep certain transactions out of the canonical chain altogether—a form of censorship. For operators, this is the practical distinction: a reorg is an ordering and inclusion problem, not a validity problem. Execution clients would still reject invalid transactions regardless of where an attacker tries to place them.
The most extreme form is finality reversion, which removes or replaces blocks that have already been finalized. The source states this is only possible if more than ⅓ of the total staked ether is destroyed by the attacker. That guarantee is known as economic finality.
Double finality: unlikely but severe
Double finality is the unlikely but severe condition where two forks finalize simultaneously, creating a permanent schism in the chain. The source describes this as theoretically possible for an attacker willing to risk 34% of the total staked ether.
The resolution is not automatic. The community would be forced to coordinate offchain and agree which chain to follow, which would require strength in the social layer. In other words, the technical outcome hands the decision to human coordination—a slow and contested process with no on-chain switch to settle it.
Finality delay: stopping the clock
A finality delay attack prevents the network from reaching the necessary conditions to finalize sections of the chain. Blocks may still be produced, but the finalized checkpoint stops advancing, which affects how quickly downstream systems should treat recent history as settled.
For wallet and payment teams, this is the outcome most likely to show up as an operational signal rather than a dramatic event: finality stops progressing, and confirmation assumptions need revisiting. The source does not state a stake threshold for this class of attack.
A practical checklist for operators
- Separate validity from finality in your runbooks: execution-level validity checks are not what an attacker targets, ordering and finality are.
- Track finalized checkpoints, not just block production, so a delay shows up as a distinct alert.
- For high-value settlement, define what your system does when finality stalls, since delay is one of the three realistic outcomes.
- Treat deep history as economically final—finality reversion carries a stated cost of more than ⅓ of total staked ether destroyed.
- Plan for social coordination as a real response path for double finality, not as an anomaly.
What the source does not say
The source does not give a stake threshold for finality delay attacks, nor does it quantify how long a delay would last or how it would be resolved. It does not provide dollar figures, ether prices or time estimates for any attack, and it does not state how often any of these outcomes has occurred in practice.
It also does not describe the tooling an operator would use to detect each outcome, or how execution clients and consensus clients should be configured during one. Those gaps are worth naming rather than filling by assumption.
Why the source frames it this way
This page outlines the known attack vectors on Ethereum's consensus layer and how those attacks can be defended, and it is adapted from a longer-form version. It assumes basic knowledge of proof-of-stake, plus familiarity with Ethereum's incentive layer and the LMD-GHOST fork-choice algorithm.
That prerequisite matters: the cost figures quoted here only make sense alongside the incentive design that punishes coordinated misbehavior. Readers who want the full treatment should start with the longer version; this guide stays with the three realistic outcomes and what they mean for people operating on top of the chain.
The practical takeaway is narrow but useful. An attacker is realistically aiming at ordering, finality or both—not at minting ether or emptying accounts—and each of those outcomes has a different signal, a different cost and a different response.