Reorg Handling

This page outlines how Citrea handles blockchain reorganizations (reorgs). To ensure data consistency, Citrea implements specific checks at both layers:

1. L1 (Bitcoin) Reorgs: How the system detects and recovers from Bitcoin reorgs that could affect validity proofs or data availability.

2. L2 (Citrea) Reorgs: How the protocol defends against malicious sequencers attempting to rewrite Citrea's history.

These defenses guarantee that the rollup state tracks Bitcoin's finality without compromising user funds.

L1 - Bitcoin Reorg Handling

Citrea currently has 4 types of nodes, sequencer, batch prover, full node, and light client prover. All of these nodes scan every Bitcoin block starting from a pre-configured block number up to a block with at least n number of confirmations, which is called the finality depth.

Finality Depth

In Bitcoin, finality is probabilistic rather than deterministic - the more confirmations a block has, the exponentially harder it becomes to reverse. Finality depth (also called confirmation depth) is the number of blocks that must be built on top of a transaction's block before it's considered secure enough to be irreversible.

How Bitcoin Confirmations Work

When a transaction is included in a block, that block counts as confirmation 1. Each subsequent block adds another confirmation. The deeper a block is buried, the more computational work required to reorganize the chain.

Bitcoin Finality

For example, a transaction in block 896 has 5 confirmations if the chain tip is at block 900 (896, 897, 898, 899, 900).

Why Finality Depth Matters for Citrea

A blockchain reorganization (reorg) occurs when a competing chain becomes longer than the current chain, causing nodes to switch to the new chain:

Bitcoin Fork

If Citrea had processed block 896 immediately, it would have seen TX A. But after the reorg, TX A might not exist in the canonical chain at that position, causing state inconsistencies.

Citrea only processes finalized blocks that have sufficient confirmations, making it robust against L1 reorgs:

This means that no Bitcoin block will be recorded in Bitcoin Light Client Contract unless it is finalized.

Safe Processing with Finality Depth = 6

Standard Confirmation Depths in Bitcoin

• 1 confirmation: Sufficient for small, low-value transactions.

• 3 confirmations: Medium security; widely used by exchanges and merchants for standard deposits.

• 6 confirmations: The industry standard for high security and settlement finality (Citrea Mainnet default).

• 100 confirmations: Coinbase Maturity. This is a Bitcoin protocol rule preventing miners from spending newly mined coins for 100 blocks.

Probability of 6-block reorg: ~0.000001%

Citrea Finality Depth Configuration

Citrea's finality depth is configurable and varies based on the underlying Bitcoin network:

• Mainnet: 6 confirmations

• Testnet4: 100 confirmations

Note on Testnet4 Configuration: Bitcoin's testnet4 exhibits significantly higher volatility in terms of blockchain reorganizations compared to mainnet. During early Citrea Testnet operation, the finality depth was initially set to 8 blocks. However, a 12-block reorganization occurred, prompting an increase to 30 blocks. Subsequently, a 30-block reorganization was observed, leading to the current configuration of 100 confirmations for testnet4. This behavior is related to Testnet4's 20-minute Exception Rule, which allows for reduced difficulty under specific conditions.

Handling Deep Reorganizations

While deep reorganizations beyond the finality depth are extremely rare (probability of 6-block reorg: ~0.000001%), they can still occur and have occurred in the past on Testnet4.

Manual Process: Handling deep reorganizations is not automated. When a deep reorg is detected, the Citrea team coordinates the recovery process and provides specific instructions to node operators.

When a deep reorganization occurs, the recovery process works as follows:

1. Detection: The Citrea team detects that a reorganization has exceeded the configured finality depth

2. Communication: The team announces the incident and provides rollback instructions to all node operators via official channels

3. Manual Rollback: Node operators execute the provided rollback commands to restore their node's state to the last consistent checkpoint before the affected blocks

4. Reprocessing: After rollback, nodes reprocess blocks from the canonical Bitcoin chain

For example, if a 7-block reorganization occurred on Bitcoin mainnet (where Citrea uses 6-block finality depth), the Citrea team would detect the issue, publish rollback commands, and coordinate with independent full node operators to execute the recovery. This manual coordination ensures network-wide consistency and maintains the integrity of the rollup state relative to Bitcoin's canonical chain.

L2 - Native Reorg Handling

Centralized Sequencer Architecture

Citrea currently utilizes a centralized sequencer as the sole authority for transaction ordering and block production. Under normal operation, this design makes L2 reorganizations impossible.

However, Citrea does not rely solely on the sequencer's honesty; the system includes multiple security mechanisms to protect users in the event of a compromised sequencer.

Security Against Malicious Sequencer

Citrea's architecture ensures that even a compromised sequencer cannot force full nodes to accept invalid state transitions through two complementary verification mechanisms.

1. Invalid L2 State Transitions

Full nodes independently execute every transaction in every L2 block. Any block containing an invalid state transition is immediately rejected by the network, preventing the sequencer from enforcing an incorrect state.

2. Sequencer Commitment Verification

Full nodes rely on sequencer commitments published to Bitcoin to verify the canonical L2 chain. Verification involves:

• Merkle root Validation: Calculating the Merkle root of received blocks and comparing it to the published commitment to detect malicious modifications, tampering, inconsistencies.

• Sequential index: Ensuring commitment indices are strictly sequential; preventing any gaps in the history.

• L2 end block number: Verifying that each commitment's start block strictly follows the previous commitment's end block.

This prevents the sequencer from building a different chain than what it broadcasts to full nodes, rewriting history, or publishing different block histories to different parties.

Batch Proof Validation

Batch proofs are Groth16 zero-knowledge proofs that cryptographically verify state transition correctness. The batch proof circuit validates:

• Block signatures using the sequencer's public key

• Chain continuity via prev_hash verification between consecutive blocks

• State transitions by applying all L2 blocks through the State Transition Function (STF) and verifying state roots match

• Storage integrity using Jellyfish Merkle Tree (JMT) proofs for all storage accesses

• Commitment consistency by recalculating Merkle roots and verifying they match published commitments

• L1 anchoring by committing to the last Bitcoin hash in the Bitcoin Light Client contract, preventing the L2 from claiming validity on a forked Bitcoin chain

Key constraint: The circuit's mathematical constraints make it impossible to generate a valid proof for invalid state transitions (e.g., unauthorized token mints or invalid transfers). If a malicious sequencer publishes invalid blocks, batch proof generation will fail.

Full nodes extract batch proofs from Bitcoin, verify their cryptographic validity, and confirm the outputs match their local state. Any mismatch results in proof rejection.

Security Against Malicious Batch Prover

The batch prover is an untrusted entity, strictly bound by the ZK circuit's logic. Even if an attacker controls the prover, they cannot compromise the network's safety due to:

• Mathematical Soundness: It is computationally infeasible to generate a valid ZK proof for an invalid state transition. The circuit constraints simply will not be satisfied.

• Input Integrity: The prover cannot modify block data. Any change to the transaction data would alter the Merkle root, causing the proof verification to fail against the published commitment.

• Strict Ordering: The protocol enforces sequential processing. The prover cannot skip batches or rearrange history; it must prove the exact sequence defined by the sequencer.

Bitcoin as the Canonical Trust Anchor

Citrea's security model is strictly anchored to Bitcoin finality. The system treats L2 state as canonical only after the corresponding proofs and commitments are finalized on Bitcoin (e.g., 6 confirmations on Mainnet). This applies to all network participants:

• Full Nodes: Reject any alternative chain proposed by the sequencer if it conflicts with the history already finalized on Bitcoin. This prevents "private chain" attacks or deep L2 reorgs.

• Light Client Prover: Transitions state solely based on finalized batch proofs. Each proof verifies against the previous finalized output, ensuring a verifiable state history back to genesis.

• Clementine Bridge: Enforces finality in the challenge-response mechanism. A proof anchored to a Bitcoin block with insufficient confirmations (e.g., 1 confirmation) is invalid, preventing theft via shallow forks or reorg attacks.

In short, while L2 actors (sequencers, provers) operate in real-time, they cannot alter history once it is finalized on Bitcoin.