> 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, 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. It works like a centralised derivatives exchange, not like an AMM or an intent-matching protocol.

The order book, matching, margin and liquidation logic are **native parts of the Exchange engine**, not a smart contract deployed on a chain. That design lets the venue target CEX-class acknowledgement latency, and traders and applications reach all of it through one API.

## The components

Four components do the work. Each owns one responsibility and has 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 properties of this design explain behaviour a trader will see.

**The Matching Engine and the Risk Engine talk both ways.** The Risk Engine does not only 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 does more than write a price.** It moves the mark, which fires triggers and drives liquidation scans. A quiet market can therefore see a burst of triggered orders and liquidations without any new order arriving.

## What runs today

|                               |                                                                                                                                 |
| ----------------------------- | ------------------------------------------------------------------------------------------------------------------------------- |
| Matching, margin, liquidation | In the Exchange engine                                                                                                          |
| Collateral                    | Synthetic USDX on testnet, credited by the faucet. Real USDX is planned to enter and leave through a deposit bridge on Ethereum |
| Markets                       | Perpetual futures, quoted and margined in USDX. `GET /markets` is the authority for what is listed                              |

**The venue you trade today is the engine.** The components above are its parts, and [Rate & connection limits](/apis-and-rates/apis-and-rates/rate-limits.md) lists the numbers that bound an integration.

Anything beyond that is roadmap, not a description of the venue. See the [Roadmap](https://docs.nexus.xyz/exchange-layer-1/overview/roadmap). Nothing on this page is 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 by asking a question.

Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:

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

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.

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.