1 · Application
2 · Network
3 · Execution
4 · State
The runtime sits outside the protocoland carries no privilege — no lower latency, no earlier data, no interface a third party cannot reach
Admission, when the senders are agentsa late cancel is worse than a late order, and fairness is tracked over recent history rather than per message
Authorization is a transactionwith a block height, inside the closed instruction set — and revoking it cancels the agent’s resting orders in the same block
A replayable, block-versioned environmentpoint-in-time by construction rather than by discipline
The same four layers as the architecture overview. Only the question is different: what does each one have to do when the participant is not a person?
1 · Application — the runtime sits outside, and has to
The agent runtime is a research and execution framework: it forms a view, turns it into something executable, and puts it in front of the venue. It runs on the application layer, in the same tier as front ends and API clients, and it is not part of the protocol. That placement is a physical constraint before it is a design preference. A model reasons in seconds; a market moves in milliseconds. Nothing that has to call a model can sit on the path an order actually takes, which means the protocol contains no model at all — not as an omission, but because a model on the settlement path would destroy the one property everything else here rests on. The execution path has to produce the same bytes on every node, and inference does not. So the runtime lives outside, and the honest question becomes what the protocol owes it. Five things, all of them committed rather than shipped:
See What’s next for status.
The runtime holds no privileged path. No lower latency, no earlier data, and no interface that a third-party runtime cannot reach. That is worth stating rather than assuming, because the architecture’s claim elsewhere is that nothing stands between a trader and the Clearinghouse — and a first-party tool with a private lane would be exactly that.
2 · Network — admission, when the senders are agents
The mempool decides what is worth holding, whose transaction is next, who hears about it, and what gets dropped when demand exceeds capacity. Agent flow stresses all four, and two of the properties that absorb it are already in place for reasons that predate agents. A late cancel is worse than a late order. The mempool treats order and cancel traffic as asymmetric by design. Agents make that asymmetry more extreme, because their cancel-to-fill ratio is higher than a human’s, but the shape of the problem is one the layer was built around. Fairness is tracked over recent history, not per message. The mempool keeps a rolling record of which senders and which kinds of traffic have recently consumed capacity, and shapes what it serves next accordingly. This is the part that matters for correlated bursts: forty agents cancelling on the same signal is not forty times the average load spread evenly, it is one spike. A per-message limit misses that. A memory of who has recently been loud does not. Consensus does not grow with throughput. Transactions reach validators as batches proven available before a proposal may reference them, so a block proposal carries digests rather than bodies. An agent population that raises message rates by an order of magnitude does not raise consensus message size at all. Two questions at this layer are open, and both become material at agent volumes rather than at human ones. What a cancel should cost. Execution already puts cancels first — they run in the phase before anything that can take liquidity. The network layer’s version of that question is unsettled: a cancel that is cheap and prioritised is what makes quoting defensible, and it is also the cheapest way to flood a mempool. Whether cancels should carry their own capacity accounting, separate from placements, is not decided. Where idempotency belongs. An agent that does not get an answer resubmits. Idempotent submission is committed at the execution layer and settles the consequence that matters — no duplicate exposure. It does not settle the network-layer version: whether the mempool should recognise a resubmission as the same intent, or carry both and let execution deduplicate. Those produce different behaviour under a retry storm.One thing deliberately not on the list: a separate admission lane for agents. Priority access is what every centralized venue eventually sells, and it would contradict the claim that nothing stands between a trader and the Clearinghouse. Agent flow gets the same door.
3 · Execution — authorization is a transaction
This is the layer where the account model changes, and the whole change follows from one fact. Handing an account to an agent is a transaction on-chain. Not a form submission, not an API key issued from a settings page, not a row in an operator’s database. A transaction, in a block, at a height, signed by the account that granted it — and therefore something any third party can find, read, and check without asking anyone. Three consequences follow, and each one is a thing an API key cannot do. It is in the closed instruction set. Agent authorization is one of the kernel’s enumerated operations. A general-purpose chain cannot express it — the meaning of the call would be opaque bytecode. A centralized venue enforces it in software you cannot inspect. Here the authority and its limits are the instruction, which is why the boundary is checkable rather than promised. It carries what the agent may do — and cannot carry what it may not. An authorization can say what the agent may hold, how much it may lose, which markets it may touch, and whether it may change margin mode. It cannot say “withdraw”. That is not a default left switched off; there is no such term to write. An agent operating an account has no expressible path to moving funds out of it. Revoking it cancels the agent’s resting orders. Revocation is a transaction too, and it lands in a block whose sequencing already runs cancels before anything that can take liquidity. So the orders the agent left on the book go in the same block the authority does. On a venue where revocation is a database write, the key stops working and the resting orders are in an undefined state. Here the stop is provable and anyone can find the height it happened at.GrantA transaction at block NCarries the scope: what the agent may hold, may lose, may trade. It cannot carry a withdrawal — that term does not exist
ActEvery action names the authorityAttributed to the account that granted it, not only to the agent that submitted it
RevokeA transaction at block MThe agent’s resting orders are cancelled in the same block, before anything that could take liquidity runs
None of the three is a database write you have to be told about. Each is a transaction anyone can find at a height.
What the venue already carries for the runtime
A trading runtime that has to protect a user on an ordinary venue ends up building its own privileged core: a position ledger it maintains and reconciles, a pre-trade risk check it runs itself and hopes the venue agrees with, and an audit log it writes and cannot prove was not edited. All three are redundancy against a venue that will not show its books. Three of those are protocol properties here. The Clearinghouse is the only writer of the ledger. The risk stage runs before matching, in the same block. The audit log is the chain, and every state change carries the transaction that caused it. What remains for the runtime is the fourth — an idempotent order gateway — and that is an interface problem rather than a trust problem.Matching: the block is already the batch
Agent flow raises the frequency and lowers the size of what reaches the book, which is the microstructure most often used to argue for a batch auction: discrete intervals, cleared together, no advantage for arriving a microsecond earlier. That property already holds here, and not because a batch auction was added. Time inside a block is the position consensus committed, not a local clock, so no sub-millisecond advantage exists within a block — and cancels run before anything aggressive, so a stale quote can be pulled and cannot be picked off by an order that arrived alongside the cancel. The block is a discrete interval that clears together. It arrived as a consequence of executing a committed ordering rather than as a market-design bolt-on. Whether anything beyond that is warranted — and continuous price-time priority and frequent batch auctions are alternatives rather than additions, since a batch deliberately removes time priority within itself — is being explored, not built.4 · State — the chain is the environment
An agent is only as good as what it was evaluated against, and evaluation is where most of the failure happens. A strategy that looked profitable in a simulator and fails in production usually did not encounter a new market; it encountered a simulator that was not the venue. The state layer removes that gap by construction rather than by discipline. State is versioned by block, and every change is attributed to the transaction that caused it, so replaying a block replays the environment rather than a model of it — the same state machine that will execute the agent, on the inputs the network committed. That is the fifth check on Verify it yourself, and it is what makes a backtest here a different kind of object than a backtest against an exchange’s historical API. The subtler property is that this is point-in-time by construction. A dataset assembled from an exchange API is point-in-time only if whoever assembled it was careful, and look-ahead leaks in through gaps nobody notices — a field backfilled after the fact, a correction applied to history, a reference price revised. Here the question does not arise: a block’s state is what was true at that block, because that is the only form the state has ever had.What gets harder
Building for agents is not only a list of things that improve. Determinism cuts both ways. An agent can predict what its own order will do before submitting it, because the same input produces the same result on every node. So can everyone else’s agent, about your order. Reproducibility raises your planning ability and your predictability at the same time, and the second is not free. Agent liquidity is correlated liquidity. Human market makers withdraw at different moments because they notice at different moments. Agents reading the same public state reach the same conclusion together. A book supported by agents is deeper on an ordinary day and can thin faster on the day that matters — which is a market-structure risk the protocol’s absorbers are designed for, not one they remove. The oracle reads venues that agents also trade. Certification binds a price to the block that consumed it; it does not make the underlying market unmanipulable, and a population of agents acting on correlated signals is one more way the underlying can move together. See what the oracle does and does not guarantee. An agent’s self-assessment is not evidence. Trading feedback is noisy and non-stationary in a way that code feedback is not — a compiler tells you that you were wrong, a profitable week does not tell you that you were right. Anything a venue builds for agents has to treat an agent’s own account of its performance as an adversarial input rather than a measurement. That is one reason the checks on Verify it yourself are framed around what can be recomputed rather than what can be reported.Where to go next
AI trading: now and next
The four phases, and why the account is the thing that has to change.
Verify it yourself
The checks that make an agent’s evaluation something other than a claim.
Trust assumptions
What is left to trust, once the checkable has been checked.
What's next
Status for the agent runtime and the authorization terms.