Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.optimism.io/llms.txt

Use this file to discover all available pages before exploring further.

OP Stack interop is in active development. Some features may be experimental.
A chain reorganization, or “reorg”, happens when validators disagree on the most accurate version of the blockchain. If not handled correctly, reorgs in a cross-chain context could result in a double-spend problem. The most frequent solution to mitigate the double-spend problem is to wait for Ethereum finality; however, that solution results in high latency cross-chain communication and a poor user experience. Most solutions to mitigate the double-spend problem rely on L1 finality. However, that solution results in high latency and poor user experience. To mitigate the double-spend problem while delivering a low-latency cross-chain experience, OP Stack interop uses block safety levels. This means users can transfer assets across OP Stack chains with 1-block latency, and should a reorg happen, either both the source and destination transactions remain or both of them revert. In every case, there is no window of opportunity to double spend.

​
Block safety levels

In the diagram above, solid arrows show derivation of a block from the previous block in the chain. Dotted arrows go from a block with an initiating message (source) to a block with the matching executing message (destination). Throughout this page, blocks are colored by safety level: finalized (grey), safe (green), or unsafe (red). Blockchain A has only published block A100 to L1. Block A101 is still unsafe, and so is every block that depends on it — directly (A102 and B302) or indirectly (A103 and B303). Even if blocks B302 and B303 have themselves been written to L1, they cannot become safe until A101 does, because a block is only treated as safe once every initiating message it references is also at least safe. When A101 eventually lands on L1, the chain of dependent blocks can promote in turn. The message between A101 and B302 can be an asset moving across the bridge. In that case, the initiating message (A101) burns n tokens on the source chain (A), and the executing message (B302) mints n tokens on the destination chain (B).

​
How the dependency check is enforced

The dependency rule above — a block is only safe once every initiating message it references is also safe — is enforced by op-supernode, the component that hosts the consensus layer of every chain in a dependency set together. For each L2 timestamp, op-supernode’s interop activity decides between wait, advance, invalidate, and rewind. The decision is persisted to a write-ahead log before being applied, so the supernode picks up after a restart in the same state it was in before. Each chain’s CL stays the single source of truth for safety on its own chain. The supernode influences advancement through interfaces the chain itself controls, never by reaching into the CL or the execution layer. The rest of this page describes the situations that drive each decision.

​
L1 reorg

L1 reorgs typically happen at the unsafe head — only the most recent L1 blocks, before they have enough confirmations to be considered safe. Each chain’s CL already filters L1 derivation through L1 safe and finalized labels, so almost all L1 reorgs never reach the L2 derivation pipeline at all. When an L1 reorg does affect L2, one of two things happens:
  • The replacement L1 block carries the same batch data as the original. Derivation is deterministic, so the L2 chain it produces is identical, and the reorg is a no-op from the L2 perspective.
  • The replacement L1 block does not carry that batch data. The sequencer notices and reposts the affected batch in a later L1 block. As long as the batch lands again before the sequencer window elapses (3600 L1 blocks ≈ 12 hours on standard chains like OP Mainnet and Unichain), derivation reproduces the same L2 chain. If the window does elapse without the batch reappearing, the affected L2 blocks are replaced with deposit-only blocks (see Invalid block below).
If a leaked L1 reorg leaves op-supernode with inconsistent per-chain views of L1, the interop activity issues a rewind: verified state is rolled back and re-derived once L1 settles. L1 reorgs do not by themselves break interop guarantees. Either the data comes back and L2 stays identical, or the chain falls back to deposit-only blocks for that span — the same behavior as if the sequencer had simply gone offline.

​
Equivocation

Sequencers inform the rest of the OP Stack chains about a new block in two ways:
  • The gossip protocol, which is typically used as soon as the block is created. The problem is that the gossip protocol does not create a commitment.
  • Posting to L1, which typically happens a few minutes after the block is created. The reason is cost; it is much cheaper if compression and L1 posting are done in large batches rather than for each individual block.
Equivocation happens when a sequencer publishes a block over the gossip protocol that differs from the one that eventually gets written to L1. The L1 version wins, and op-supernode issues an invalidate for every unsafe dependent block (local or cross-chain) that built on the gossiped version. A block in another chain can only depend on a specific block here if it referenced one of that block’s logs in an executing message — and a block only earns the safe label once every initiating message it depends on has also reached at least safe. So the equivocation between A101 and A’101 only invalidates unsafe blocks: A102 and A103 on chain A (extending the bad history), B301 and B302 on chain B (which referenced A101 directly) along with B303 (which follows them on chain B), and C203 on chain C (which referenced B302). All those unsafe blocks are reorged out and replaced by the corresponding '-marked blocks, which derive from A’101. Anything previously labeled safe or finalized is untouched.

​
Invalid block

A block can also be canonically invalidated outright. If verifiers determine that an L2 block cannot be reproduced from L1 — for example because the batch claims an initiating message that does not exist on the source chain — the canonical chain replaces it with a deposit-only block: a block that contains only the deposit transactions forced through L1, with all sequencer transactions stripped out. For interop-specific failures like that example, op-supernode is the verifier that makes the call. Functionally this is equivalent to equivocation, and the dependency rules above handle it the same way: only unsafe blocks (and any chain of blocks depending on them transitively) are reshaped, and any block that had already reached the safe label is untouched.

​
Next steps