Reorgs

Arbitrum Nitro reorgs are rare but not impossible, and at roughly 100 millisecond blocks a naive consumer will miss one. Most providers handle them by quietly replacing the affected data upstream.

That is the wrong default for anyone keeping records. A silent correction makes your audit log wrong in a way you cannot detect — the data changed, nothing told you, and a figure you reported last week no longer reproduces. For a regulated buyer that is disqualifying.

On detection we emit a REORGED record for every affected item, carrying the same dedup_key as the original and naming the affected block range. Sinks receive compensating writes on that key, so an idempotent consumer converges without special handling.

{  "confirmation_state": "CONFIRMATION_STATE_REORGED",  "delivery": {    "dedup_key": "0x7a1e…:3",    "sequence": "88214417"  },  "reorg": {    "from_block": 4512889,    "to_block": 4512891,    "depth": 3  }}

ClickHouse sinks use ReplacingMergeTree keyed on the tape sequence, so a compensating write replaces its predecessor without you writing deduplication logic. Postgres sinks upsert on the dedup key. Kafka carries both records, and the consumer decides.

Reorg depth and frequency are published continuously on the status page, so you can size your own confirmation policy against observed behaviour rather than a guess.