# Reorgs The question this note answers: what happens when history changes? A reorg is the canonical chain switching branches. Before: ```text A -> B -> C ``` After: ```text A -> B -> D -> E ``` Block `C` was real. Nodes saw it, apps reacted to it, maybe a user got a notification about it. And now it's simply not part of history anymore. Any transaction that was in `C` either shows up again in a later block or quietly vanishes. Here's the part that surprises people coming from traditional systems: this is not a failure mode. In Nakamoto-style consensus it's routine — two miners find blocks at the same moment, the network briefly disagrees, and the fork-choice rule sorts it out. Reorgs are the price of open participation, and [[Finality]] is the promise that, eventually, they stop. ## Why engineers care Anything that reads chain state and acts on it has to decide how much recent history it trusts. The classic mistake in an indexer looks innocent: ```text insert event forever ``` The workable shape acknowledges that recent history is provisional: ```text insert event with block_hash mark canonical after confirmations/finality handle rollback if reorg ``` If you've built CDC or event-sourcing pipelines, you already have most of the right instincts — chain data is eventually consistent, and your ingestion needs to be idempotent and reversible until finality arrives. The one new wrinkle: the upstream log can fork. ## What breaks when this is ignored - Deposits credited, then reorged away - Withdrawals paid twice - Notifications for transactions that never happened - Accounting that can't reconcile - User balances that flicker ## Where this matters - [[04 Consensus]] — why reorgs happen and what bounds them - [[08 Nodes, RPCs, and Indexers]] — building reorg-safe pipelines - [[Finality]] — the point past which you may relax