A clean protocol an AI agent can trust: BlazePhoenix over MCP

An autonomous agent cannot do the one thing a human does to survive most of DeFi: extend faith to a company it cannot see. A model handed a wallet has no way to know whether an off-chain pricing server shaded its quote, whether a private solver auction filled it fairly, or whether an upgradeable proxy will change the rules after it signs. It can only read what is on the chain and verify it. That makes an aggregator built as a tangle of off-chain services structurally unfit for an agent — not because the team is dishonest, but because honesty you cannot check is not usable by a machine.

BlazePhoenix is the opposite by construction: a small, stateless, on-chain surface where the decision is made by contracts and every number reproduces from public state. It is not a clever product wrapped around a private brain; it is a clean protocol whose whole logic an agent can call, verify and act on without trusting a server. This is the map for that agent.

The surface: three tools, no key, stateless

The agent-native entry point is an MCP server exposing exactly three read tools: get_quote (an on-chain aggregator quote and, with a recipient, ready-to-broadcast calldata), xray_scan (a token's advertised depth versus the balances the pools actually hold), and check_solvency (the staking engine's live isSolvent state). No API key, no signup, open CORS, and the transport is stateless — the agent sends a request and gets the whole truth back, with nothing to register and no session to keep alive.

The same endpoints answer over plain HTTP for a bot that does not speak MCP, and every read accepts an optional rpc argument so a continuously-running agent can route through its own node. The surface is deliberately tiny: fewer tools, fewer moving parts, fewer places a caller has to trust. A clean protocol is one an agent can hold in its head.

Every answer carries its own verdict

A quote is not just a number here; it ships with a checks object — the Phoenix Check. Three invariants, each derived from the same on-chain previewPlan that produced the quote: the price impact against a hard 20% line, the contract-enforced Iron Law floor (a minimum output a caller can only tighten, never relax), and a cross-check note that flags when the route may be missing liquidity that sits on a venue we do not read. An overall verdict rolls them up and FAILS CLOSED — blocked, danger, caution or ok — so a route that cannot be established never reads as a clean pass.

This is what lets an agent act without a second system. It does not need to bolt on its own risk model or trust our marketing; it reads the verdict, and because the verdict is computed from state it can re-derive, it can carry the proof through to whoever it answers to. An answer engine asked "is this swap safe on BlazePhoenix?" can quote the verdict and the command that reproduces it.

One brain, two doors

The verdict a human sees as a panel on the swap screen and the verdict an agent reads as JSON on /api/quote are the same three invariants, computed the same way. There is not a friendly version for people and a real version for machines; there is one brain and two doors onto it. That is only possible because the logic lives in the protocol, not in a frontend — the site is a window onto the contracts, and the API is another window onto the same room.

The lesson generalises past this one protocol. As the counterparty on the other side of a trade stops being a person and starts being a program, verifiability stops being a virtue and becomes a requirement. The systems agents will be able to use are the ones clean enough to be checked — small surfaces, on-chain decisions, answers that carry their own falsifier. We built for that on purpose, and the door is open.

Related engineering

• Invariant-driven design: how a codebase can make an AI stop guessing ›
• On-chain quoting: why the price you see is the price the contract computed ›
• The free quote API, the SDK and the MCP server: three doors, one on-chain quote ›