This page describes the perpetuals exchange. Spot trading uses a different model — see the Spot concepts. The page is conceptual; for wire formats and endpoints, see the API reference.
High-level view
At the top level, the core exchange feeds the appchain validators, which drive both settlement on the EVM rootchain and publication to decentralized storage.The layers
| Layer | Component | Role |
|---|---|---|
| Off-chain | Core exchange | The CLOB matching engine. Ingests requests through API servers, orders them with a sequencer, and runs a deterministic state machine that matches and batches trades. Not bottlenecked by blockchain settlement. |
| Appchain | Validator set | A permissioned set that independently replicates the exchange state machine — re-verifying signatures, checking margin, and confirming fills are valid against orders — then batches transactions, computes a state commitment (e.g. a Merkle root), and votes it on-chain. This is what keeps the exchange non-custodial. |
| Rootchain (EVM) | Checkpoint Manager | Records the validator set’s state commitment and the resulting on-chain side effects (withdrawals) onto the public EVM rootchain. |
| Rootchain (EVM) | Bridge Vault | Custodies user funds and stores withdrawable balances, performs final settlement, and honors withdrawals published by the validator set. Includes the escape hatch (emergency settlement) so withdrawals can’t be censored. |
| Storage | Data availability | Decentralized storage that keeps block data retrievable — the escape hatch depends on it. |
Key properties of the hybrid design
- The core exchange operates in a centralized manner, so its performance is not limited by blockchain settlement.
- Executed trades emitted by the core exchange can be considered final.
- The only exception is escape-hatch activation (a full exchange shutdown), which occurs only if Arcus or the appchain validators go offline. In that case, trades since the last committed and executed state root would be “busted.”
- The appchain is operated by a permissioned validator set. It validates that exchange rules are respected so the core exchange cannot exert substantial control over user funds — i.e. the exchange is non-custodial. Verification includes checking that all state transitions are acceptable and re-verifying signatures on orders, withdrawals, and oracle prices.
- Custody of funds and final trade settlement are on the EVM rootchain. The rootchain contracts include an escape hatch (“emergency settlement”) that prevents the core exchange from censoring withdrawals. This escape hatch depends on data availability, which the appchain validators ensure.
Rootchain contract requirements
Subject to the system’s trust assumptions, the rootchain smart contracts must:- ensure user funds can’t be stolen;
- ensure users always have a means to exit and withdraw their funds;
- prevent denial of service.
Inside the core exchange
Zooming into the off-chain core exchange, the request pipeline is a straight line. Two kinds of input feed it:- API servers accept client requests, verify their signatures, and detect and verify on-chain events — deposits, forced trades, and forced withdrawals — before passing them in.
- Upstream services supply the other transaction types the exchange needs: oracle price ticks, funding ticks, liquidations, and market config changes.