Skip to main content
The Arcus perpetuals exchange is a hybrid DEX built around a high-performance off-chain CLOB matching engine. Trades are validated, batched, and settled non-custodially: the core exchange matches orders off-chain, the Arcus appchain anchors consensus and re-verifies that exchange rules were respected, and fund custody plus final settlement live on an EVM-based public blockchain.
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

​
Key properties of the hybrid design

  • The core exchange operates in a centralized manner, so its performance is not limited by blockchain settlement — it sustains 100k+ orders per second with ~20ms trade confirmations.
  • 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.
In these general respects the design is comparable to other hybrid DEXes such as StarkEx and Lighter.

​
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.

​
Security audits

The rootchain contracts have been independently reviewed:

​
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.
Both streams converge on the sequencer, which assigns every transaction a single deterministic order — the property that makes execution reproducible and fair. From there the matching engine maintains the order book and matches trades, and together they advance the exchange state machine: account balances, oracle prices, and market configs. Matched results are published to two places — real-time WebSocket feeds for market data, and persistence for history and downstream consumers.