> For the complete documentation index, see [llms.txt](https://docs.nexus.xyz/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.nexus.xyz/overview/architecture.md).

# Architecture

The components the Exchange is built from, the execution environment it targets, and what runs today.

The Nexus Exchange is a **central-limit order book with a native matching engine, risk system and oracle**. Orders rest in a book, match on price-time priority, and settle against margin held by the venue — the same shape as a centralised derivatives exchange, rather than an AMM or an intent-matching protocol.

What makes it different from a CEX is where that logic is designed to run. The order book, matching, margin and liquidation logic are **protocol components written for the Nexus blockchain** — not a smart contract deployed on a general-purpose chain, and not an off-chain engine bolted to one. That is what lets the venue target CEX-class acknowledgement latency while still being built for a chain.

## The components

Four components do the work. Each owns a distinct responsibility, and each is documented on its own page in this section.

```mermaid
flowchart LR
  C[Clients — traders, market makers] --> API[API<br/>REST + WebSocket]
  API --> ME[Matching Engine<br/>order books, matching, fills]
  API --> RE[Risk Engine<br/>margin, liquidations, funding]
  ME <--> RE
  OR[Oracle<br/>mark and index prices] --> RE
  OR --> ME
```

| Component           | What it owns                                                                                                                               | Where it is documented                                                                                                                                                            |
| ------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **API**             | Every way in and out — order entry, cancels, amends, account and market reads, the WebSocket stream. It holds no trading state of its own. | [APIs & Rates](/apis-and-rates/apis-and-rates.md), [API Reference](https://docs.nexus.xyz/api-reference)                                                                          |
| **Matching Engine** | The order books, price-time matching, and the fills that come out of them.                                                                 | [Order Types](/trading/trading/perpetuals/order-types.md), [Discovery Bounds](/trading/trading/perpetuals/discovery-bounds.md)                                                    |
| **Risk Engine**     | Margin, liquidations, auto-deleveraging, funding, and the insurance fund.                                                                  | [Margining](/trading/trading/perpetuals/margining.md), [Liquidations](/trading/trading/perpetuals/liquidations.md), [Funding Rates](/trading/trading/perpetuals/funding-rates.md) |
| **Oracle**          | The index and mark prices that margin, funding and liquidation are all computed against.                                                   | [Price Oracles](/trading/trading/perpetuals/price-oracles.md)                                                                                                                     |

Two things about this shape are worth drawing out, because they explain behaviour a trader actually sees.

**The Matching Engine and the Risk Engine talk both ways.** Risk does not merely observe the book; it acts on it. When an account breaches maintenance margin, or an oracle move fires a trigger, the Risk Engine submits closing orders and cancels resting ones. So a fill can appear on your account that you did not submit — see [Liquidations](/trading/trading/perpetuals/liquidations.md).

**An oracle update is not just a price write.** It moves the mark, which fires triggers and drives liquidation scans. A market can therefore go from quiet to a cascade of activity without a single new order arriving.

## The chain the Exchange is built for

The Exchange is written to execute inside **NexusCore**, the Nexus blockchain's environment for specialised financial operations — order matching, risk, oracles, liquidations — with deterministic execution at **200 ms** block intervals. A second environment, **NexusEVM**, provides Ethereum-compatible programmability at 1 s intervals for anything that needs to compose with the venue rather than run inside it.

> **200 ms is the chain's block cadence for financial execution.** It is not the current execution path of the venue described above, and it is **not** the same quantity as order-acknowledgement latency, which has its own target. See [Rate & Connection Limits](/apis-and-rates/apis-and-rates/rate-limits.md) for the limits that actually bound an integration.

The chain's own architecture — consensus, validators, proving, and the rest — is documented in the [Network section](https://docs.nexus.xyz/exchange-layer-1), not here. What matters on this page is the execution environment the venue targets and the cadence it runs at.

## Where it runs today

**The engine runs as a self-contained process**, which is what lets it be exercised end to end for correctness, performance and feature completeness — and is why the Exchange reached real users on testnet as a development preview.

Concretely, today:

|                               |                                                                                                                     |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------- |
| Matching, margin, liquidation | In the exchange engine, as a self-contained process                                                                 |
| Collateral                    | Synthetic USDX on testnet, credited by the faucet. Real USDX enters and leaves through a deposit bridge on Ethereum |
| Markets                       | Perpetual futures, quoted and margined in USDX. `GET /markets` is the authority for what is listed                  |

**So the venue you trade today is the engine.** The components above are what it is built from, and [Rate & Connection Limits](/apis-and-rates/apis-and-rates/rate-limits.md) is where the numbers that bound an integration actually live.

Anything beyond that is roadmap rather than description — see the [Roadmap](https://docs.nexus.xyz/exchange-layer-1/overview/roadmap). Nothing on this page should be read as a commitment to a date.


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.nexus.xyz/overview/architecture.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.