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

# Architecture Overview

> Intention is an AI-native trading network: matching, clearing, and settlement execute as protocol operations rather than inside an operator's private system.

## Intention is an AI-native trading network

A trading *network*, not a trading application. The parts of an exchange that decide who filled what, at what price, and who owes whom are executed by the network's own validators, ordered by consensus, and reproducible by anyone holding the same blocks. There is no matching engine running somewhere else and reporting back.

AI-native, because that is what an agent trading on someone's behalf actually needs. A person can watch a venue and react to it. An agent cannot — it can only act on what the venue is able to prove. Moving matching, margin, funding, liquidation, and settlement into the protocol is what turns a venue from a counterparty you trust into infrastructure you can verify.

Everything usually presented as a feature list follows from that one decision. Because execution runs over a consensus-committed order, replaying a block reproduces it exactly. Because the price is certified in the block that consumes it, there is no oracle cycle to race. Because liquidation and funding are protocol operations rather than contract calls, they execute in the same step as the fill that triggered them. Because the state machine emits per-transaction output, every effect has an author.

<Note>
  An exchange is more than this. Front ends, account operations, market listing, support, and commercial terms all sit around it. What the network makes public and verifiable is the settlement-critical core — the part where a discrepancy costs someone money.
</Note>

## The layers

Four layers, in the order a transaction passes through them.

<div className="dg" data-dg="architecture-layers">
  <div className="dg-c" style={{aspectRatio:"720 / 502"}}>
    <svg className="dg-w" viewBox="0 0 720 502" aria-hidden="true">
      <path className="dg-wire dg--blue" d="M 406.00 96.00 L 406.00 131.60" />

      <path className="dg-head dg--blue" d="M 406.00 138.00 L 401.60 131.60 L 410.40 131.60 Z" />

      <path className="dg-wire dg--sky" d="M 406.00 228.00 L 406.00 263.60" />

      <path className="dg-head dg--sky" d="M 406.00 270.00 L 401.60 263.60 L 410.40 263.60 Z" />

      <path className="dg-wire dg--green" d="M 406.00 360.00 L 406.00 395.60" />

      <path className="dg-head dg--green" d="M 406.00 402.00 L 401.60 395.60 L 410.40 395.60 Z" />

      <path className="dg-wire dg-dash dg-soft" d="M 46.00 447.00 L 46.00 57.40" />

      <path className="dg-head" d="M 46.00 51.00 L 50.40 57.40 L 41.60 57.40 Z" />
    </svg>

    <div className="dg-band" style={{left:"12.7778%",top:"1.9920%",width:"87.2222%",height:"16.3347%"}}><span className="dg-cap">1 · Application — outside the protocol</span></div>
    <div className="dg-band" style={{left:"12.7778%",top:"28.2869%",width:"87.2222%",height:"16.3347%"}}><span className="dg-cap">2 · Network</span></div>
    <div className="dg-band" style={{left:"12.7778%",top:"54.5817%",width:"87.2222%",height:"16.3347%"}}><span className="dg-cap">3 · Execution — IntentionKernel</span></div>
    <div className="dg-band" style={{left:"12.7778%",top:"80.8765%",width:"87.2222%",height:"16.3347%"}}><span className="dg-cap">4 · State</span></div>
    <div className="dg-b" style={{left:"15.0000%",top:"5.5777%",width:"26.2963%",height:"9.1633%"}}><span className="dg-t">Intention web gateway</span></div>
    <div className="dg-b" style={{left:"43.2407%",top:"5.5777%",width:"26.2963%",height:"9.1633%"}}><span className="dg-t">Front ends · wallets</span></div>
    <div className="dg-b" style={{left:"71.4815%",top:"5.5777%",width:"26.2963%",height:"9.1633%"}}><span className="dg-t">Agents · market makers · API clients</span></div>
    <div className="dg-b dg--blue" style={{left:"15.0000%",top:"31.8725%",width:"40.4167%",height:"9.1633%"}}><span className="dg-t">Mempool</span><span className="dg-s">admission · dissemination</span></div>
    <div className="dg-b dg--blue" style={{left:"57.3611%",top:"31.8725%",width:"40.4167%",height:"9.1633%"}}><span className="dg-t">IntentionBFT</span><span className="dg-s">ordering · prices · finality</span></div>
    <div className="dg-b dg--sky" style={{left:"15.0000%",top:"58.1673%",width:"40.4167%",height:"9.1633%"}}><span className="dg-t">Matching</span><span className="dg-s">order book · priority</span></div>
    <div className="dg-b dg--sky" style={{left:"57.3611%",top:"58.1673%",width:"40.4167%",height:"9.1633%"}}><span className="dg-t">Clearinghouse</span><span className="dg-s">margin · liquidation · funding</span></div>
    <div className="dg-b dg--green" style={{left:"15.0000%",top:"84.4622%",width:"40.4167%",height:"9.1633%"}}><span className="dg-t">State store</span><span className="dg-s">values by version</span></div>
    <div className="dg-b dg--green" style={{left:"57.3611%",top:"84.4622%",width:"40.4167%",height:"9.1633%"}}><span className="dg-t">Merkle state</span><span className="dg-s">proofs · accumulators</span></div>
    <div className="dg-lbl" style={{left:"56.3889%",top:"23.3068%"}}>signed transactions</div>
    <div className="dg-lbl" style={{left:"56.3889%",top:"49.6016%"}}>committed block</div>
    <div className="dg-lbl" style={{left:"56.3889%",top:"75.8964%"}}>writes · attributed events</div>
    <div className="dg-lbl" style={{left:"6.3889%",top:"50.0000%",width:"12.2222%",whiteSpace:"normal"}}>reads · proofs</div>
  </div>
</div>

A fifth group sits beside the stack rather than inside it. **Service layer** processes run alongside validators, and they attach at two points only: prices and assets go *in* at the network layer, committed records come *out* at the state layer.

<div className="dg" data-dg="overview-services">
  <div className="dg-c" style={{aspectRatio:"720 / 288"}}>
    <svg className="dg-w" viewBox="0 0 720 288" aria-hidden="true">
      <path className="dg-wire dg--sky" d="M 185.00 65.00 L 240.47 120.47" />

      <path className="dg-head dg--sky" d="M 245.00 125.00 L 237.36 123.59 L 243.59 117.36 Z" />

      <path className="dg-wire dg--sky" d="M 185.00 175.00 L 240.08 129.10" />

      <path className="dg-head dg--sky" d="M 245.00 125.00 L 242.90 132.48 L 237.27 125.72 Z" />

      <path className="dg-wire dg--green" d="M 455.00 100.00 L 487.00 100.00 L 487.00 65.00 L 508.60 65.00" />

      <path className="dg-head dg--green" d="M 515.00 65.00 L 508.60 69.40 L 508.60 60.60 Z" />

      <path className="dg-wire dg--green" d="M 620.00 104.00 L 620.00 129.60" />

      <path className="dg-head dg--green" d="M 620.00 136.00 L 615.60 129.60 L 624.40 129.60 Z" />

      <path className="dg-wire dg--green dg-dash" d="M 620.00 214.00 L 620.00 250.00 L 350.00 250.00 L 350.00 190.40" />

      <path className="dg-head dg--green" d="M 350.00 184.00 L 354.40 190.40 L 345.60 190.40 Z" />
    </svg>

    <div className="dg-b dg--sky" style={{left:"0.0000%",top:"10.4167%",width:"25.0000%",height:"24.3056%"}}><span className="dg-t">Oracle</span><span className="dg-s">certified prices, per round</span></div>
    <div className="dg-b dg--sky" style={{left:"0.0000%",top:"48.6111%",width:"25.0000%",height:"24.3056%"}}><span className="dg-t">Bridge</span><span className="dg-s">deposits and withdrawals</span></div>
    <div className="dg-b dg--blue" style={{left:"34.7222%",top:"24.3056%",width:"27.7778%",height:"38.1944%"}}><span className="dg-t">The four layers</span><span className="dg-s">network → execution → state</span></div>
    <div className="dg-b dg--green" style={{left:"72.2222%",top:"10.4167%",width:"27.7778%",height:"24.3056%"}}><span className="dg-t">Indexer</span><span className="dg-s">committed records → queryable history</span></div>
    <div className="dg-b dg--green" style={{left:"72.2222%",top:"48.6111%",width:"27.7778%",height:"24.3056%"}}><span className="dg-t">Program services</span><span className="dg-s">derived state, computed outside the block</span></div>
    <div className="dg-lbl" style={{left:"67.3611%",top:"86.8056%",width:"31.9444%",whiteSpace:"normal"}}>written back on-chain, read during execution</div>
  </div>
</div>

**Application layer.** Everything people and machines actually touch: the Intention web gateway, third-party front ends and wallets, and the agents and market makers that trade programmatically. None of it is part of the protocol — it is what the protocol is for, and it is deliberately replaceable. Two front ends disagreeing about what a position is worth is a front-end bug, because both are reading the same committed state.

**Network layer.** Where transactions are admitted, disseminated, and ordered. [IntentionBFT](/protocol/architecture/intention-bft) commits an ordering and a certified price vector in the same consensus event; the [mempool](/protocol/architecture/mempool) governs what reaches it; [topology](/protocol/architecture/intention-bft#network-topology) describes who runs what.

**Execution layer.** [IntentionKernel](/protocol/architecture/kernel) executes the committed block as a fixed sequence of stages. Its instruction set is the enumerated set of financial operations a derivatives venue needs — not a general-purpose virtual machine. [Matching](/protocol/architecture/matching) and the [Clearinghouse](/protocol/architecture/clearinghouse) are stages inside it, not separate systems.

**State layer.** [State and storage](/protocol/architecture/state/model) covers how results are persisted, authenticated, and served: a current-value store for reads, a versioned Merkle structure for proofs, and accumulators over transactions and events.

**Service layer.** Processes that run alongside validators rather than inside the block: the [oracle](/protocol/architecture/oracle) that feeds prices into consensus, the [indexer](/protocol/architecture/indexer) that turns committed state into queryable data, [program services](/protocol/architecture/programs) that derive account state from committed history and commit it back through protocol transactions, and the [bridge](/protocol/architecture/bridge) that moves assets across chains.

## One block

Everything that makes the venue's behavior checkable happens inside a single committed block.

<div className="dg" data-dg="overview-txpath">
  <div className="dg-c" style={{aspectRatio:"720 / 236"}}>
    <svg className="dg-w" viewBox="0 0 720 236" aria-hidden="true">
      <path className="dg-wire" d="M 100.67 78.00 L 114.27 78.00" />

      <path className="dg-head" d="M 120.67 78.00 L 114.27 82.40 L 114.27 73.60 Z" />

      <path className="dg-wire" d="M 225.33 78.00 L 238.93 78.00" />

      <path className="dg-head" d="M 245.33 78.00 L 238.93 82.40 L 238.93 73.60 Z" />

      <path className="dg-wire" d="M 350.00 78.00 L 363.60 78.00" />

      <path className="dg-head" d="M 370.00 78.00 L 363.60 82.40 L 363.60 73.60 Z" />

      <path className="dg-wire" d="M 474.67 78.00 L 488.27 78.00" />

      <path className="dg-head" d="M 494.67 78.00 L 488.27 82.40 L 488.27 73.60 Z" />

      <path className="dg-wire" d="M 599.33 78.00 L 612.93 78.00" />

      <path className="dg-head" d="M 619.33 78.00 L 612.93 82.40 L 612.93 73.60 Z" />
    </svg>

    <div className="dg-b dg--blue" style={{left:"0.0000%",top:"12.7119%",width:"13.4259%",height:"40.6780%"}}><span className="dg-t">Signed transaction</span></div>
    <div className="dg-b dg--sky" style={{left:"17.3148%",top:"12.7119%",width:"13.4259%",height:"40.6780%"}}><span className="dg-t">Mempool</span><span className="dg-s">validated before it is stored</span></div>
    <div className="dg-b dg--sky" style={{left:"34.6296%",top:"12.7119%",width:"13.4259%",height:"40.6780%"}}><span className="dg-t">Consensus</span><span className="dg-s">ordering and a price quorum</span></div>
    <div className="dg-b dg--sky" style={{left:"51.9444%",top:"12.7119%",width:"13.4259%",height:"40.6780%"}}><span className="dg-t">Kernel</span><span className="dg-s">block execution</span></div>
    <div className="dg-b dg--green" style={{left:"69.2593%",top:"12.7119%",width:"13.4259%",height:"40.6780%"}}><span className="dg-t">State writes</span><span className="dg-s">attributed events</span></div>
    <div className="dg-b dg--green" style={{left:"86.5741%",top:"12.7119%",width:"13.4259%",height:"40.6780%"}}><span className="dg-t">Commit</span><span className="dg-s">ledger and state stores</span></div>
    <div className="dg-b dg-dashed dg-left" style={{left:"0.0000%",top:"67.7966%",width:"100.0000%",height:"27.9661%"}}><span className="dg-t">What the sequence produces</span><span className="dg-s">The ordering and the prices are committed before execution begins, and every state change is bound to the transaction that caused it — which is what lets anyone replay the block and get the same result.</span></div>
    <div className="dg-free" style={{left:"0.0000%",top:"0.0000%",width:"100.0000%"}}><div className="dg-n">One transaction, end to end</div></div>
  </div>
</div>

The ordering is fixed before execution begins, and execution is a function of that ordering and the pre-state. Two honest nodes given the same block reach the same result byte for byte — not as a policy, but because nothing in the execution path can read anything else. That property is what everything downstream rests on: proofs, attribution, replay, and an agent's ability to reason about what a submitted order will do.

## Where the venue's guarantees come from

Rather than a separate list of promises, each property traces to the layer that produces it.

| Property                                                           | Produced by                                                                                                                                                                    |
| ------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| The same block replays to the same result on every honest node     | Consensus fixes the ordering; the [kernel](/protocol/architecture/kernel) executes it with no clock, no entropy, and no floating point                                         |
| A transaction settles at a price the network certified             | The price quorum is part of the block, committed by the same signatures — see [IntentionBFT](/protocol/architecture/intention-bft) and [Oracle](/protocol/architecture/oracle) |
| Liquidation and funding cannot lag the fill that caused them       | They are [Clearinghouse](/protocol/architecture/clearinghouse) stages in the same block execution, not keeper transactions                                                     |
| Every state change can be traced to the transaction that caused it | The kernel emits per-transaction output, which the [state layer](/protocol/architecture/state/model) commits and the [indexer](/protocol/architecture/indexer) serves          |

## The market infrastructure this replaces

A traditional venue is one institution in a chain of them. A trade is matched at an exchange, novated and margined at a central counterparty, recorded at the institution that keeps the book of who holds what, settled across a payment system, and reported to a trade repository. Five functions, five sets of records, and a reconciliation process whose job is to find out when they disagree.

Here those five are stages of one block, which is what makes the sequence **atomic clearing and settlement**: it commits as a unit or it does not commit at all. The term is worth being precise about. That atomicity covers the protocol's own ledger — moving collateral in or out through the [bridge](/protocol/architecture/bridge) waits on an external chain's finality and sits outside the unit.

<div className="dg" data-dg="fmi-collapse">
  <div className="dg-c" style={{aspectRatio:"720 / 372"}}>
    <svg className="dg-w" viewBox="0 0 720 372" aria-hidden="true" />

    <div className="dg-band" style={{left:"0.0000%",top:"4.8387%",width:"100.0000%",height:"33.8710%"}}><span className="dg-cap">Five institutions</span></div>
    <div className="dg-band" style={{left:"0.0000%",top:"52.6882%",width:"100.0000%",height:"33.8710%"}}><span className="dg-cap">One block</span></div>
    <div className="dg-b" style={{left:"2.2222%",top:"12.3656%",width:"16.4444%",height:"18.8172%"}}><span className="dg-t">Match</span><span className="dg-s">an exchange</span></div>
    <div className="dg-b" style={{left:"22.0000%",top:"12.3656%",width:"16.4444%",height:"18.8172%"}}><span className="dg-t">Clear</span><span className="dg-s">a CCP</span></div>
    <div className="dg-b" style={{left:"41.7778%",top:"12.3656%",width:"16.4444%",height:"18.8172%"}}><span className="dg-t">Record</span><span className="dg-s">a depository</span></div>
    <div className="dg-b" style={{left:"61.5556%",top:"12.3656%",width:"16.4444%",height:"18.8172%"}}><span className="dg-t">Settle</span><span className="dg-s">a payment system</span></div>
    <div className="dg-b" style={{left:"81.3333%",top:"12.3656%",width:"16.4444%",height:"18.8172%"}}><span className="dg-t">Report</span><span className="dg-s">a trade repository</span></div>
    <div className="dg-b dg--blue" style={{left:"2.2222%",top:"60.2151%",width:"18.6667%",height:"18.8172%"}}><span className="dg-t">Match</span><span className="dg-s">matching stage</span></div>
    <div className="dg-b dg--blue" style={{left:"21.4444%",top:"60.2151%",width:"18.6667%",height:"18.8172%"}}><span className="dg-t">Clear</span><span className="dg-s">Clearinghouse</span></div>
    <div className="dg-b dg--green" style={{left:"40.6667%",top:"60.2151%",width:"18.6667%",height:"18.8172%"}}><span className="dg-t">Record</span><span className="dg-s">state layer</span></div>
    <div className="dg-b dg--green" style={{left:"59.8889%",top:"60.2151%",width:"18.6667%",height:"18.8172%"}}><span className="dg-t">Settle</span><span className="dg-s">the same block</span></div>
    <div className="dg-b dg--green" style={{left:"79.1111%",top:"60.2151%",width:"18.6667%",height:"18.8172%"}}><span className="dg-t">Report</span><span className="dg-s">attribution</span></div>
    <div className="dg-free dg-mid" style={{left:"0.0000%",top:"40.8602%",width:"100.0000%"}}><div className="dg-n">Four gaps. In each one a promise exists that nobody has yet made good — and a reconciliation process exists to find out when they disagree.</div></div>
    <div className="dg-free dg-mid" style={{left:"0.0000%",top:"88.7097%",width:"100.0000%"}}><div className="dg-n">The same five functions, as one unit of commitment. Either all of it happened or none of it did, and there is no second record to reconcile against.</div></div>
  </div>
</div>

| Traditional function | Who performs it                                       | Here                                                                                                                       |
| -------------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------- |
| **Match**            | The exchange's matching engine                        | [Matching](/protocol/architecture/matching), a stage of block execution                                                    |
| **Clear**            | A central counterparty — LCH, CME Clearing, ICE Clear | The [Clearinghouse](/protocol/architecture/clearinghouse)                                                                  |
| **Record**           | A central securities depository — DTCC, Euroclear     | The same Clearinghouse, writing to the [state layer](/protocol/architecture/state/model)                                   |
| **Settle**           | A payment system — Fedwire, TARGET2, CLS              | The block itself: both legs commit, or neither does                                                                        |
| **Report**           | A separate regulatory reporting pipeline              | Per-transaction [attribution](/protocol/architecture/state/model), served by the [indexer](/protocol/architecture/indexer) |
| **Price**            | A benchmark administrator                             | The [oracle](/protocol/architecture/oracle), certified inside the block that consumes it                                   |

The claim is not that this is cheaper. It is that the intervals between those institutions are where a promise exists that nobody has yet made good — between a fill and a margin call, between a call and the collateral arriving, between a trade and its settlement, between an event and its report. Collapsing the functions into stages of one block does not make the promises stronger. It removes the intervals in which they can be broken. Matching, clearing and settlement are not three stops on a pipeline here; they are the same event in the same block. Execution is settlement.

## The network today

The architecture above is running now, on a private testnet carrying the full stack. See [The network today](/protocol/architecture/network-status) for chain identity, live endpoints, and what to expect before public access opens on 20 September 2026.

## Where to go next

<CardGroup cols={2}>
  <Card title="IntentionKernel" href="/protocol/architecture/kernel">
    The execution layer: instruction set, block pipeline, and the boundaries that keep it deterministic.
  </Card>

  <Card title="IntentionBFT" href="/protocol/architecture/intention-bft">
    Consensus: ordering commitments, price quorums, and finality.
  </Card>

  <Card title="Clearinghouse" href="/protocol/architecture/clearinghouse">
    Margin, liquidation, auto-deleveraging, insurance, and funding.
  </Card>

  <Card title="State and storage" href="/protocol/architecture/state/model">
    How committed results are persisted, authenticated, and pruned.
  </Card>
</CardGroup>