> 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/architecture/nexuscore.md).

# NexusCore

NexusCore is the specialized, high-performance financial execution engine of the Nexus blockchain — the second core alongside [NexusEVM](/architecture/nexusevm.md). It runs **enshrined co-processors**: native financial modules built directly into the protocol rather than deployed as smart contracts, executing deterministically at 200 ms block intervals.

NexusCore powers the Nexus Exchange. The same co-processor framework is designed to host further financial primitives over time — vaults, oracles, lending, stablecoins, and more.

## The Exchange Kernel

The flagship co-processors form the **Exchange Kernel** — the matching, risk, funding, and liquidation primitives behind the Nexus Exchange:

<figure><img src="/files/1wGTjiahnB7jwVugbTxL" alt="NexusCore hosting the Exchange Kernel — CLOB, margining, risk, and liquidation engines — surrounded by per-market co-processors."><figcaption><p>NexusCore's Exchange Kernel and per-market co-processors.</p></figcaption></figure>

* **Central Limit Order Book (CLOB)** — native order matching with price-time priority.
* **Risk Engine** — margining and real-time position risk.
* **Oracle Engine** — mark and index pricing for every market.
* **Liquidation Engine** — deterministic liquidations and solvency protection.

Because these run in-protocol rather than as contracts, markets execute deterministically and settle with the chain's finality.

## Co-processors and parallelism

Each co-processor is an isolated, purpose-built state machine. They run in parallel — independent modules (matching, oracles, future vaults) execute concurrently, and individual co-processors parallelize internally across markets and accounts. The architecture targets near-linear scaling with validator hardware while preserving deterministic execution.

Co-processors expose **dual interfaces**:

* a **native API** (REST + WebSocket) for direct, low-latency access; and
* an **EVM interface** (precompiles) so NexusEVM contracts can compose with NexusCore — placing orders, reading market state, and managing margin atomically within a single transaction.

## Extensible markets

NexusCore is designed to make markets **permissionless to deploy**: in time, builders will be able to launch a perpetual market for any asset by supplying an oracle — spanning crypto, FX, commodities, equities, indices, and more exotic markets.

<figure><img src="/files/wh5dj2YdhnTpILAofNU8" alt="The Nexus Exchange vision — a CLOB at the center serving perps and spot across many asset classes: equities, FX, stables, indexes, options, commodities, information, and LSTs."><figcaption><p>One liquidity layer across every asset class.</p></figcaption></figure>

## Role in the system

NexusCore and NexusEVM operate as parallel execution domains with different block cadences — 200 ms for financial execution, 1 second for smart contracts. NexusBFT commits blocks for both with single-slot finality, and the [Compute Network](/architecture/compute-network.md) proves execution so anyone can verify it.


---

# 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/architecture/nexuscore.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.
