> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arcus.xyz/llms.txt
> Use this file to discover all available pages before exploring further.

# Architecture

> How the Arcus perpetuals exchange combines a high-performance off-chain matching engine with a permissioned appchain and an EVM rootchain to settle trades non-custodially

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.

<Note>
  This page describes the **perpetuals** exchange. Spot trading uses a different model — see the [Spot](/concepts/spot-rfq) concepts. The page is conceptual; for wire formats and endpoints, see the [API reference](/api-reference/introduction).
</Note>

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

```mermaid theme={null}
flowchart LR
  subgraph servers["Arcus Servers"]
    core["Core Exchange"]
  end
  subgraph appchain["Arcus Appchain"]
    validator["Validator set"]
  end
  subgraph rootchain["EVM Rootchain"]
    checkpoint["Checkpoint Manager"]
    vault["Bridge Vault 💲"]
  end
  subgraph storage["Decentralized Storage"]
    da["Data Availability"]
  end

  core -->|executed trades| validator
  validator -->|committed state roots| checkpoint
  validator -->|publish block data| da
  checkpoint -->|settle / custody| vault
```

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

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.

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

```mermaid theme={null}
flowchart LR
  api["API servers"] --> seq["Sequencer"]
  feeds["Upstream services"] --> seq
  seq --> match["Matching engine"]
  match --> ws["WebSocket feeds"]
  match --> db["Persistence"]
```