How Exchanges and Indexers Handle Blockchain Reorgs: Confirmation Depth, Rollbacks, and Finality

A blockchain transaction can appear confirmed one moment and become part of a different chain history later. For a normal wallet user, a short blockchain reorganization, or reorg, may go unnoticed. For an exchange or blockchain indexer, however, it can create a much bigger problem.

Imagine a user deposits 2 ETH into an exchange. The transaction is included in a block, the exchange detects it, and its internal system begins counting confirmations. A few blocks later, the network reorganizes. The block containing the deposit is no longer part of the canonical chain.
The exchange now has a question to answer: Should the deposit still be considered valid?

This is where confirmation depth, reorg detection, rollbacks, and finality become important. Exchanges and indexers cannot simply assume that the latest blockchain state is permanent. They need mechanisms to identify chain changes, reverse affected application state, and determine when a transaction is safe to treat as final.

What Is a Blockchain Reorg?

A blockchain reorganization occurs when the network replaces part of its recent chain history with another valid chain branch.

Under normal conditions, blocks form a sequence:

Block 100 → Block 101 → Block 102 → Block 103

But competing blocks can sometimes be produced around the same point:

→ Block 102A → Block 103A
Block 100 → Block 101
→ Block 102B → Block 103B

The network eventually selects one branch as the canonical chain. The blocks belonging to the other branch are no longer part of the accepted chain.

This means transactions included in the discarded blocks need to be reconsidered.

A transaction might:

• Remain included in the new canonical chain
• Become pending again
• Be included in a replacement block
• Disappear from the canonical chain entirely

For applications that store blockchain data in databases, this distinction matters. An indexer may have already processed an event from a block that is later removed. An exchange may have already detected a deposit that is no longer confirmed on the canonical chain.

A reorg therefore turns blockchain data from a simple append-only stream into something applications must sometimes reconcile and rebuild.

Why Reorgs Are a Problem for Exchanges and Indexers

Exchanges and indexers both consume blockchain data, but they use it differently.

An indexer continuously reads blocks, transactions, logs, and contract events and converts them into structured data that applications can query.

An exchange uses blockchain data to manage deposits, withdrawals, balances, confirmations, and settlement.

Both systems face the same fundamental issue:

A transaction being included in a block does not necessarily mean that its position in the blockchain is permanently settled.

For an indexer, a reorg can invalidate:

• Indexed blocks
• Transaction records
• Token transfers
• Smart contract events
• Calculated balances
• Application-specific state

For an exchange, the consequences can be even more sensitive. A deposit could be credited to a user's internal balance before the block containing that deposit becomes sufficiently stable.

This is why production systems usually separate states such as detected, confirmed, credited, and finalized instead of treating every observed transaction as immediately trustworthy.

Confirmation Depth: How Many Blocks Are Enough?

Confirmation depth is one of the simplest ways applications reduce reorg risk.

Suppose a transaction is included in Block 500:

Transaction → Block 500
        ↓
     Block 501
        ↓
     Block 502
        ↓
      Block 503

As additional blocks are added after Block 500, the transaction gains more confirmations.

An exchange might define a policy such as:

0 confirmations → Detected
1 confirmation → Confirmed
6 confirmations → Credit deposit

The exact number depends on the blockchain, asset, risk model, transaction value, and network conditions.

The basic principle is straightforward:
The deeper a transaction sits inside the chain, the less likely a normal short reorg will remove it.

However, confirmation depth does not mean absolute finality.
Waiting for additional blocks introduces a trade-off:

• Fewer confirmations: faster deposits but greater reorg exposure
• More confirmations: greater safety but slower user experience

An exchange therefore needs to choose a confirmation policy that balances security and usability.

What Happens During a Reorg?

Consider a deposit included in Block 502:
Block 500
↓
Block 501
↓
Block 502 → 2 ETH deposit
↓
Block 503
The exchange's indexer has already processed the transaction.
Now the network produces a competing branch:

Block 500
↓
Block 501
↓
Block 502A
↓
Block 503A

If the original Block 502 is removed from the canonical chain, the exchange's internal representation is now potentially outdated.

The application must determine:

1. Which block was replaced?
2. What is the common ancestor?
3. Which blocks were removed?
4. Which replacement blocks were added?
5. Which transactions and events were affected?
6. Does the original deposit still exist in the canonical chain?

The important point is that a reorg is not simply a "missing block" problem. It is a state consistency problem.

The application must bring its internal database back into agreement with the canonical blockchain.

How Blockchain Indexers Detect Reorganizations

A reorg-aware indexer needs more than block numbers.
It should track information such as:

• Block number
• Block hash
• Parent hash
• Timestamp
• Processing status
• Confirmation or finality state

Suppose the indexer stored:

`Block 105
Hash: AAA

Block 106
Hash: BBB
Parent: AAA
The node later reports:
Block 105
Hash: AAA

Block 106
Hash: CCC
Parent: AAA`

The block number is the same, but the hash has changed.
That is a strong indication that the chain has reorganized.

The indexer can then:

1. Detect the block-hash mismatch.
2. Find the latest common ancestor.
3. Identify blocks that are no longer canonical.
4. Roll back data generated from those blocks.
5. Process the replacement branch.
6. Rebuild affected derived state.

Parent-hash validation is particularly important because it allows the indexer to verify whether the block it is processing actually follows the chain it previously stored.

Rollbacks: Reverting Data After a Reorg

A rollback means reversing application state that was derived from blocks that are no longer canonical.

Imagine an indexer records:

Alice balance = 5 ETH

Deposit event:
Alice +2 ETH

Indexed balance = 7 ETH

If the block containing that deposit is removed during a reorg, simply deleting the block record is not enough.

The derived balance may still show 7 ETH.
The indexer must reverse the state:

Remove deposit
        ↓
Reverse affected event
        ↓
Restore Alice's balance
        ↓
Process replacement chain

The same principle applies to token transfers, NFT ownership, contract events, and other derived data.

This is why reorg-aware indexing requires a clear relationship between raw blockchain data and derived application state.

Designing an Indexer That Can Safely Roll Back

A reliable indexer should be designed with reprocessing in mind from the beginning.

Store Block Metadata

A blocks table might contain:

blocks

height
hash
parent_hash
timestamp
status

Transactions and events can then reference the block that produced them:

transactions

tx_hash
block_hash
block_height

events

event_id
tx_hash
block_hash
contract_address
event_type

This makes it easier to identify which records belong to a discarded branch.

Use Checkpoints

Checkpoints allow an indexer to remember where processing safely stopped.

For example:
Last checkpoint: Block 10,000
Current block: Block 10,250

If the indexer crashes or encounters a reorg, it does not necessarily need to rebuild the entire chain.

It can roll back to an appropriate checkpoint or common ancestor and continue processing.

Make Processing Idempotent

An operation is idempotent when running it multiple times does not produce incorrect duplicate state.

This matters because replacement blocks may require transactions or events to be processed again.

A robust indexer should be able to safely:
Read block

→ Process events
→ Roll back
→ Read replacement block
→ Process events again

without creating duplicate balances or duplicate records.

Database transactions can also help ensure that block processing does not leave partially updated state if something fails.

How Exchanges Protect User Funds During Reorgs

Exchanges usually apply stricter rules than a simple blockchain explorer.
A deposit may move through several states:

Detected
   ↓
Pending
   ↓
Confirmed
   ↓
Credited
   ↓
Finalized

These states allow the exchange to separate seeing a transaction from trusting that transaction.

For example, an exchange may detect a deposit immediately but wait for a predefined number of confirmations before making the funds available to the user.

If a reorg occurs while the deposit is still pending, the system can reassess the transaction without necessarily affecting the user's available balance.

For higher-value transactions, exchanges may also use stricter confirmation requirements or additional reconciliation checks.

The key principle is that blockchain monitoring should not directly equal balance crediting.

The application needs a risk-aware state machine between the two.

Confirmation Depth vs Finality

Confirmation depth and finality are related, but they are not the same thing.

Confirmation depth refers to how many blocks have been added after a transaction.

Finality refers to the point at which a transaction is considered settled under the blockchain's consensus rules and is no longer realistically expected to be reversed.

For example:

Confirmation - A transaction is included in a block
Confirmation depth - Additional blocks have been built afterward
Rollback - Application state is reversed after a chain change
Finality - The transaction reaches a sufficiently irreversible state

The distinction becomes particularly important when building systems that operate across different blockchain networks.

An application should understand the finality model of the chain it supports rather than applying the same confirmation policy everywhere.

A network with probabilistic finality may require applications to wait for additional confirmations. A network with explicit consensus finality may provide a different signal that applications can use.

A Practical Reorg-Handling Workflow

A production indexer or exchange can think about reorg handling as a sequence of checks:

New block detected
       ↓
Validate parent hash
       ↓
Compare with stored chain
       ↓
Reorg detected?
     /     \
   No       Yes
   ↓         ↓
Process    Find common ancestor
             ↓
        Roll back affected state
             ↓
      Process replacement blocks
             ↓
       Update confirmations
             ↓
          Finality

The exact implementation will vary, but the architecture should always answer three questions:

1. Is this block part of the canonical chain?
2. What application state depends on this block?
3. When can that state be considered final?

Keeping these questions separate makes the system easier to reason about and test.

How to Test Reorg Handling

Reorg handling should not be tested only when a production incident occurs.

Development teams can simulate scenarios such as:

• Competing blocks
• Removed blocks
• Replacement blocks
• Transactions disappearing from a branch
• Transactions appearing again in a replacement branch
• Duplicate events
• Indexer crashes during rollback
• Rebuilding state from checkpoints
• Deeper-than-expected reorganizations

One useful test is deliberately simple:

If the last several blocks disappeared right now, could the system reconstruct the correct state automatically?

If the answer is no, the system may be relying too heavily on the assumption that blockchain history is permanently append-only.

A reorg-aware architecture should be able to detect the change, identify affected state, roll it back, process the canonical replacement chain, and continue without manual database correction.

Conclusion

Blockchain reorganizations are a normal engineering consideration for applications that depend on recent blockchain state.

For exchanges, reorgs can affect deposits, withdrawals, and internal balances. For indexers, they can invalidate blocks, transactions, events, and derived state.

The solution is not simply to wait for a few confirmations. Robust systems combine confirmation depth, block-hash tracking, parent validation, rollback mechanisms, checkpoints, idempotent processing, and finality-aware state management.

The most important distinction is between data that has been observed and data that can safely be treated as final.

A blockchain application should always be prepared for the possibility that recent state can change.

If the latest few blocks were reorganized today, could your exchange or indexer recover the correct state without manual intervention?