# Finality & reorgs

> Finality levels on Robinhood Chain (latest, safe, finalized), how the Crius API marks them, and how chain reorganizations are handled in REST and WebSocket.

Source: https://crius.sh/docs/concepts/finality/

Every event Crius returns (trades, transfers, liquidity changes) carries a `finality`:

| Level | When | Typical delay |
|---|---|---|
| `latest` | Included by the Robinhood Chain sequencer | under a second |
| `safe` | The batch containing it has been posted to Ethereum | minutes |
| `finalized` | Ethereum has finalized that batch | about 15–20 minutes more |

Every response's `meta` reports the current `safe_block` and `finalized_block`, so you can tell the level of anything by its block.

## Reorgs

Sequencer-ordered blocks are very rarely replaced, but it can happen. When it does:

- **REST** responses simply reflect the new chain: replaced events disappear and new ones appear.
- **WebSocket** clients receive a `reorg` message (`common_ancestor`, `removed_blocks`, `depth`), then every affected event again with `"removed": true` and the same `id`, then the replacement events. Undo what you did for removed events by `id`.

If your application can't handle reversals (accounting, payouts), only act on `safe` data: filter by `finality=safe` where an endpoint supports it, or subscribe to the stream with `"finality": "safe"`, which holds each event until its block is safe.