XDRIPACADEMY
homeSign inEnroll

By the end of this lesson you can

  • →Trace a transaction from signing to finality and name what can change at each stage
  • →Explain why confirmed is a probability rather than a state
  • →Compute the window during which your intent is public and actionable by others
  • →Manage nonce ordering so that one stuck transaction cannot block an exit

Junior · enrolled learners

This lesson opens with The seven block reorganization, 25 May 2022.

What happened
At 08:55 UTC on 25 May 2022, seven blocks on the Ethereum beacon chain, numbered 3,887,075 through 3,887,081, were removed from the canonical chain between 08:55:23 and 08:56:35. Developers said the cause was not a flaw in the fork choice rule. A proposer boost update, which gives the current slot's proposer a weight advantage so that attesters prefer timely proposals, had been released as a change operators could adopt at their own pace. Some validators were running it and some were not. A late arriving block then split the two groups' views. A known fault in some clients, which ran the fork choice at the wrong time, let the split persist, and the disagreement resolved by discarding seven blocks that had already been produced and seen. This was before the Merge, so the beacon chain did not yet carry user transactions, and finality was not delayed.
The decision point
Those seven blocks had been produced, seen and built on. Seventy-two seconds later they were not part of the chain the network agreed on. No user transaction was reversed, because before the Merge the beacon chain carried none; after the Merge every beacon block carries the execution payload, so a reorganization of the same depth today would take transactions with it. Nothing was hacked, and the trigger was that a routine, optional client upgrade had reached some operators and not others, which is a property of every network running more than one version of anything.

What you will be able to answer

  • →What does one confirmation mean?
  • →When is an Ethereum transaction actually final?
  • →What is the mempool exposure window?
  • →Why does a stuck transaction block everything?

Orientation and Year One are open: anyone can read them without an account. From Year Two onward the lessons are for enrolled learners, because progress through the later years only means anything if it is tracked against a record.

It is free. We do not sell the list and there is nothing to buy at the end of it.

Enroll, it is freeSign inStart at the beginning
Terms used here
SlippageBridgeLiquidationDrawdown

Sources and review

Confidence high·Volatility medium·Reviewed 2026-08-06·Owner unassigned

Contested

Slot times, finality rules and mempool behavior differ by chain, and the specific figures here describe Ethereum. The structure of the lifecycle, being signed then public then included then agreed, is general, and the confirmation policies of venues encode each chain's own answer.

Barnabé Monnot's analysis names three causes: the late block, the uneven proposer boost rollout, and a known incorrect client implementation of when the fork choice runs. Developers quoted at the time, including Preston Van Loon, called it a segmentation of updated and out of date client software rather than a flawed fork choice. The slot numbers and times are from Cointelegraph, citing Beacon Scan. The reorganized blocks were pre-Merge beacon blocks and held no user transactions; the lesson uses them to show what a confirmation is worth on the consensus layer, not as a case of reversed payments.

Whether private transaction routing is a net improvement is genuinely contested and is treated in J302-04. It removes public mempool exposure and substitutes trust in the party receiving the transaction, which is a trade rather than a fix.

← Price impact and slippageMEV →