- What is a chain reorganisation, and is it normal?
- A reorg ('reorganisation') happens when the network temporarily disagrees on which block belongs at a given height, then converges on a different block. On QRL 2.0 this is normal protocol behaviour — sometimes two validators propose competing blocks for nearby slots and the network has to pick one — but it's also rare on a healthy chain, and the protocol cleans it up automatically. Each row in the table is one such event.
- How does QRL 2.0 prevent deep reorgs?
- QRL 2.0 has Casper-FFG economic finality: once a block has accumulated two epochs of attestations on top (about 4 hours 16 minutes) it is finalized, and reverting it would require an attacker to control more than one-third of total stake AND be willing to be slashed. So reorgs deeper than a handful of slots are essentially impossible during normal operation — any rows here are almost always 1 height deep.
- What is the 'Depth' column showing me?
- Depth is how many blocks were replaced, measured in slots — and on QRL 2.0 it is reported directly by qrysm, the consensus client, through its native chain-reorg event (not a heuristic). qrysm computes it by walking back to the common ancestor of the old and new head. Because Casper-FFG finality caps how deep a reorg can go, near-100% of rows show a depth of 1; anything larger is worth investigating.
- How does Quantascan detect reorgs?
- On QRL 2.0 we listen to qrysm's consensus layer directly: the moment it switches the canonical head, it emits a chain-reorg event carrying the real depth, the old and new head block, and the slot. That's the authoritative source — the consensus client is what decides the canonical chain, so it can't miss a reorg it performed. We log each event into etl_silver.reorg_events and schedule a Gold-layer reconciliation so the aggregations on /blocks and /charts don't double-count.
- What happens to my transaction if its block gets reorged out?
- Within the brief window before the alternate chain wins, your transaction's inclusion is undone — but the transaction itself is broadcast back into the mempool and is almost always picked up by the next proposer. After QRL 2.0 finality (~4h 16min) reorgs cannot undo a confirmed transaction; for everyday transfers the practical risk is negligible.
- What is 'auto-reconcile' on a reorg?
- QRL 2.0's aggregating views (chain stats, daily activity, hourly fee market) are pre-computed in ClickHouse and don't see the difference between an original insert and a re-insert after a reorg — without correction the same block can be double-counted. Quantascan's reconcile_scheduler debounces reorg events (30s by default) and rebuilds the affected Gold tables in a single pass, so the public data stays consistent.
- Will reorged-out blocks ever appear back in this list?
- No. Each reorg event captured here is the moment a previously-canonical block at a given height was replaced. The reorged-out block hash stays in the 'Previous canonical hash' column forever as a historical record; the new winning block is what /blocks shows at that height now.
- Why are there sometimes no reorgs at all on this page?
- On a healthy QRL 2.0 chain, days or weeks can pass without any reorgs being detected — that's a good signal, not a bug. The table only fills when the network temporarily disagrees about a block; long stretches of stability mean every block produced has held its place at the canonical height.