Status and Verification
How to see what the exchange is doing, and check it yourself.
Nothing about the exchange's operation is private. Its health, its blocks, and the proof behind every balance are all readable over the same API the app uses.
Live status
| Endpoint | What it tells you |
|---|---|
/v1/status | The next block number and how many transactions are pending — a heartbeat for the sequencer. |
/v1/blocks?limit=N | The most recent committed blocks: when each was committed and whether it has been proven. |
/v1/batches | The settlement ranges and their proof state — how far the proven frontier is behind the committed tip. |
A committed-but-unproven block is normal: commits happen every few seconds and proofs follow within minutes. What you are looking for is that the proven frontier keeps advancing behind the committed tip.
Committed versus proven
Every read that returns account or market state offers two views:
- Speculative — what the sequencer has applied. This is what you trade against; it is instant.
- Settled — what the last proven block established. This is final.
The two agree except in the short window between a block being committed and its proof landing. If you are building something that must never act on an unproven balance — a downstream settlement, an accounting reconciliation — read the settled view.
Verifying it yourself
The stronger check is to not take the API's word for it. Every block's data is committed to the settlement chain, so anyone can:
- Read the blocks from the chain.
- Replay them to rebuild the exchange's state — the same replay a prover does.
- Confirm the state root matches what the settlement contract holds after each proven block.
This is what "verifiable" means here: the exchange's entire history is reconstructible from public data, and the proof the contract verified is the guarantee that the history it settled followed the rules. You do not have to trust the operator, and you do not have to run a prover to benefit — but you can, and check the whole chain end to end.