Skip to main content

​
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.
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.

​
The layers

Four layers, in the order a transaction passes through them.
1 · Application — outside the protocol
2 · Network
3 · Execution — IntentionKernel
4 · State
Intention web gateway
Front ends · wallets
Agents · market makers · API clients
Mempooladmission · dissemination
IntentionBFTordering · prices · finality
Matchingorder book · priority
Clearinghousemargin · liquidation · funding
State storevalues by version
Merkle stateproofs · accumulators
signed transactions
committed block
writes · attributed events
reads · proofs
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.
Oraclecertified prices, per round
Bridgedeposits and withdrawals
The four layersnetwork → execution → state
Indexercommitted records → queryable history
Program servicesderived state, computed outside the block
written back on-chain, read during execution
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 commits an ordering and a certified price vector in the same consensus event; the mempool governs what reaches it; topology describes who runs what. Execution layer. IntentionKernel 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 and the Clearinghouse are stages inside it, not separate systems. State layer. State and storage 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 that feeds prices into consensus, the indexer that turns committed state into queryable data, program services that derive account state from committed history and commit it back through protocol transactions, and the bridge that moves assets across chains.

​
One block

Everything that makes the venue’s behavior checkable happens inside a single committed block.
Signed transaction
Mempoolvalidated before it is stored
Consensusordering and a price quorum
Kernelblock execution
State writesattributed events
Commitledger and state stores
What the sequence producesThe 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.
One transaction, end to end
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.

​
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 waits on an external chain’s finality and sits outside the unit.
Five institutions
One block
Matchan exchange
Cleara CCP
Recorda depository
Settlea payment system
Reporta trade repository
Matchmatching stage
ClearClearinghouse
Recordstate layer
Settlethe same block
Reportattribution
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.
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.
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 for chain identity, live endpoints, and what to expect before public access opens on 20 September 2026.

​
Where to go next

IntentionKernel

The execution layer: instruction set, block pipeline, and the boundaries that keep it deterministic.

IntentionBFT

Consensus: ordering commitments, price quorums, and finality.

Clearinghouse

Margin, liquidation, auto-deleveraging, insurance, and funding.

State and storage

How committed results are persisted, authenticated, and pruned.