> For the complete documentation index, see [llms.txt](https://whitepaper.after-bell.uk/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://whitepaper.after-bell.uk/technical-architecture/clob-matching-engine.md).

# CLOB Matching Engine

Explains the off-chain engine that receives and matches signed trading intent.

### Role of the matching engine

AFTERBELL’s central limit order book is an off-chain component. It uses Node.js and WebSocket. It receives signed orders, maintains the order-book environment, matches compatible orders, and forwards valid matches toward on-chain settlement.

The CLOB is distinct from the smart-contract settlement layer. It answers the off-chain question, “Which participants have compatible trading intent?” CTFExchange answers the on-chain question, “Can the resulting settlement be executed and enforced?”

### Signed order intent

The core flow is:

```
User → signs EIP-712 order → CLOB receives signed intent
     → matching occurs off-chain → CTFExchange settlement occurs on-chain
```

EIP-712 provides structured signed trading intent. The user’s signed order lets the matching layer receive an order without writing every order directly to the chain.

The source does not specify the typed-data fields, order types, nonce model, replay protection design, expiry, cancellation, partial-fill behavior, or any matching priority. Those mechanics must not be inferred from the existence of a CLOB.

### Matching and settlement boundary

“Matching compatible orders” means the engine identifies trading intents that can be settled together. It does not mean that the CLOB independently transfers USDG or changes the ownership of outcome tokens.

```
Off-chain: signed intent, order discovery, matching
On-chain: USDG settlement, outcome positions, enforceable protocol state
```

The source identifies CTFExchange as the component for CLOB settlement and batch execution. It does not identify it as an order-book database or matching algorithm.

### Alternative position path

The architecture can match an order against another participant **or** mint new shares from USDG. This creates two high-level ways for an outcome position to enter the system.

The first path relies on another participant’s compatible order. The second is the source-stated USDG-backed minting path. The source does not specify when one path is selected, how new shares are priced, or the minting algorithm. This page therefore describes the architectural alternative without assigning unsupported rules.

### Batch execution

CTFExchange supports batch execution. In this architecture, batching is a stated settlement capability after matching. The source does not give batch size limits, atomicity rules, ordering semantics, or performance claims.

### Example flow

User A wants to buy Yes. User B wants to sell Yes. Each signs an order. The CLOB receives both signed intents and identifies their compatibility. The match proceeds toward CTFExchange for on-chain settlement. USDG and the ERC-1155 outcome position move through the settlement layer according to the protocol’s contract logic.

No exact order size, price, or execution rule is implied by this example.

### Operational boundary

The matching engine is an off-chain dependency. WebSocket connectivity is also an operational dependency. Matching does not occur directly on-chain, and the source makes no availability, censorship-resistance, latency, or throughput guarantee.

{% hint style="warning" %}
The CLOB is part of a hybrid system. Its off-chain operation is a trust and availability boundary, even though settlement and outcome positions are on-chain.
{% endhint %}


---

# 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://whitepaper.after-bell.uk/technical-architecture/clob-matching-engine.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.