If you spend enough time reading about blockchains, you eventually run into the word reorg, short for reorganization. It sounds alarming, like the chain changed its mind about what happened. In a narrow sense, that is exactly what it means. Understanding when reorgs can occur, and why Base is built to make them rare, helps explain why some apps ask you to wait a little longer before treating a transaction as truly done.
What a reorg actually is
A blockchain is a chain of blocks, each one pointing back to the block before it. Under normal conditions, everyone building on the chain agrees on which block comes next, and the chain grows in a single, shared line.
Occasionally, two valid blocks get produced back to back by different parts of the network before everyone has heard about each other's version. For a brief moment there are two competing versions of "what happened next." The network's rules eventually pick one version to keep, and the other gets discarded, along with any transactions that were only included in the discarded block. That discard and switch is a reorg. Any transaction that lived only in the abandoned block effectively never happened, at least as far as the chain is concerned.
On a base layer chain like Ethereum, this used to happen occasionally due to network propagation delays between validators. Since Ethereum's move to proof of stake, reorgs of finalized blocks are considered practically impossible without an attacker controlling a large share of staked ETH, which would be extraordinarily expensive.
Why Base is a different kind of chain
Base is a layer 2 built on the OP Stack, which changes the picture. Instead of thousands of independent validators competing to propose the next block, Base currently runs a single sequencer, operated by Coinbase, that orders transactions and produces blocks. That centralization is a tradeoff: it is what gives Base its fast, cheap, predictable transactions, but it also means the sequencer briefly holds more control over ordering than a decentralized validator set would.
Base's own documentation describes transaction confirmation as passing through several progressive stages, each with a different level of reorg risk. Roughly:
Flashblock inclusion, under a second. The sequencer includes your transaction in a fast preconfirmation block. This is the earliest signal you get that something happened, and it carries the highest, though still very small, reorg probability.
L2 block inclusion, a couple of seconds. The transaction lands in a full L2 block and is distributed to other nodes on the network. Reorg risk drops sharply here. According to Base's documentation, this level of reorg has happened only once in the chain's history, which gives a sense of how rare it is in practice rather than a purely theoretical guarantee.
L1 batch inclusion, around two minutes. The sequencer bundles a batch of L2 transactions and posts it to Ethereum as L1 data. Once that batch is written into an Ethereum block, Base nodes mark the corresponding L2 blocks as safe. From this point on, the sequencer can no longer reorder or drop those transactions on its own, because the record now lives on Ethereum itself.
L1 batch finality, around twenty minutes. Once the Ethereum block holding that batch has been finalized by Ethereum's validator set, roughly two epochs later, Base marks the corresponding blocks as finalized. At this stage, undoing the transaction would require reorganizing finalized Ethereum blocks, which is considered effectively impossible under Ethereum's current design.
Interestingly, an Ethereum reorg does not automatically drag a Base reorg along with it, because Base nodes are built to maintain a small, deliberate lag behind Ethereum's very latest tip rather than following it instantly.
What this means for something like a swap
Most of the time, none of this needs to cross your mind. Small, everyday transactions, a swap, a transfer, a token approval, confirm in seconds and are for practical purposes done. The multi-stage model exists for the cases where the stakes are higher: a large transfer, a payment you cannot easily redo, or a transaction another automated system will act on immediately.
If you are moving a small amount for your own use, waiting for the transaction to show as confirmed in your wallet is normally enough. If you are settling something significant, especially with a party who is not going to double check with you later, it is reasonable to wait for the safe stage a couple of minutes out, or to let an exchange or app apply its own confirmation threshold before treating the funds as received.
It is worth separating this from withdrawals that move assets back to Ethereum itself, which follow an entirely different, much longer challenge process measured in days rather than minutes. That is a distinct mechanism from the reorg risk described here, built to let anyone dispute a fraudulent withdrawal before it settles on Ethereum.
The short version
A reorg is a blockchain briefly disagreeing with itself about recent history and then settling on one version. On a decentralized base layer like Ethereum, that disagreement is resolved by validators and is essentially unheard of once a block is finalized. On Base, the sequencer's central role means the earliest moments of a transaction carry a small amount of reorg risk, but that risk shrinks fast as the transaction moves from an initial preconfirmation, to an L2 block, to data posted on Ethereum, to full finality. For everyday use, Base already feels final within a couple of seconds. The extra stages exist for the transactions where a couple of minutes of patience is a reasonable price for certainty.