If you read agent-infrastructure announcements this month, you saw the same four words attached to very different machines: "the settlement layer for the agent economy." AEON used it. Circle's product copy leans on it. Fireblocks is in the same lane. We use it too. That's a problem for anyone trying to actually build, because "settlement" has quietly come to mean at least four different things, and they have different trust assumptions, different failure modes, and different right answers depending on what your agent is doing. This is a short, opinionated map. No leaderboard, no "who wins" - just what each layer actually is, so you can pick the one your use case needs.
The biggest funding signal this month was AEON, which raised an $8M pre-seed led by YZi Labs (IDG Capital, HashKey, Stanford Blockchain Builders Fund, and others participating). AEON describes itself as "the settlement layer for the agentic economy," and in partnership with BNB Chain it launched an x402 Facilitator handling agent-to-merchant payments - reportedly serving 2M+ users, ~30M monthly transactions, and connecting agents to 50M+ real-world merchants. It leans on x402, ERC-8004, Google AP2, and MCP.
What it is: a payment rail. An agent needs to pay a merchant; AEON routes a stablecoin from agent to seller, encodes the instruction in an HTTP 402, and produces an on-chain receipt. For agent-to-merchant commerce - the "my agent bought something from your store" flow - this is exactly the right shape.
What it isn't: a mechanism for two parties who don't trust each other to exchange different native assets and have both sides clear together. The money moves one direction, to a known seller. That's a different problem from a trade.
Circle's Agent Stack, with its Nanopayments layer (launched May 3), is the cleanest example of a second meaning. Nanopayments moves gas-free USDC in amounts as small as $0.000001 - a millionth of a dollar - by batching enormous numbers of transfers off-chain over Circle Gateway and x402, then settling on-chain. Gateway already gives you chain-abstracted USDC across supported networks.
What it is: a micropayment rail, tuned for the high-frequency, sub-cent flows that machine-to-machine commerce generates (pay-per-API-call, pay-per-token, metered services). When your agent needs to pay for ten thousand tiny things without ten thousand gas fees, this is a genuinely impressive primitive.
What it isn't: a two-sided trade settlement either. It's still single-asset value transfer - USDC from A to B - just at remarkable granularity and throughput. The asset doesn't change hands for a different asset, and there's no "clear together or not at all" requirement, because there's only one leg.
Fireblocks rolled out an Agentic Payments Suite for stablecoin transactions, extending its custody platform to agent flows. The model here is the most familiar one in institutional crypto: a custodian holds funds in a vault, and releases them when policy conditions are met.
What it is: custodial settlement. It's battle-tested, it has rich policy controls, and for institutions that already trust Fireblocks with custody, extending that to agents is a small, sensible step.
What it isn't: trust-minimized. By design, someone you trust is holding the money between intent and execution. For many enterprises that's a feature - the custodian is also the compliance and recovery surface. But it means the trust assumption is "the custodian behaves," which is a different budget from "no one holds my money at any point."
Worth flagging, not litigating: the BNBAgent SDK went live on BNB Chain testnet as the first implementation of ERC-8183, which pairs ERC-8004 agent identity with on-chain escrow and an evaluator that verifies a job before funds release or refund. Mainnet is "coming soon." This is escrow-with-a-judge - powerful where the dispute is "was the work done well," subjective and off-chain. (We dug into the judge-vs-math tradeoff separately; the short version is that an evaluator earns its keep on subjective delivery and is overhead you can delete on a clean asset-for-asset swap.)
This is the layer we build, and the one the other three don't cover: two parties exchanging different native assets, possibly across chains, who don't trust each other, with no custodian and no bridge.
The primitive is a sealed-bid RFQ paired with hash-time-locked contracts. Both legs of the trade are locked under one hashlock. Reveal the preimage once and the whole path opens; never reveal it and every leg refunds. There is no vault holding your assets, no evaluator to attest, no wrapped IOU standing in for the real thing. The trade clears as a single unit or it doesn't happen.
The honest limits, because a map without limits is marketing: cryptographic atomicity can only adjudicate whether assets moved, not whether subjective work was done well - that's the evaluator's domain. And our chain status is specific: Ethereum mainnet is live end-to-end; the BTC HTLC path is signet-validated with mainnet pending; Sui contracts are deployed and CLI-tested with gateway wiring in progress. Rails ready, more trains coming.
A question this map raises: if no one holds the money, how do you settle a trade that's agreed now but executes later? That's the forward-settlement case - an agent locks in terms today for delivery at a future point. The custodial answer is "a vault holds the margin in between." The atomic answer is to keep the same clear-or-refund guarantee across a time dimension: terms commit now, the hash-time-lock structure carries the settlement window, and neither side has to trust the other to hold anything during the wait. It's the same primitive, extended along time instead of just across chains - and it's why "no custodian" doesn't have to mean "spot only."
Ask one question: what does your agent's transaction need to be true at the moment of settlement?
Most real agent stacks will use more than one of these. They compose; they're not rivals. The mistake is assuming "settlement layer" means the same thing in two announcements - it almost never does this month.
Which meaning is your agent actually relying on? I'd genuinely like to hear which layer you're picking and why - especially if your use case sits between two of them.
Map and tools: https://hashlock.markets/?utm_source=devto&utm_medium=article&utm_campaign=2026-06-06-three-settlements
Methodology and the academic basis for the atomic-settlement claims: https://hashlock.markets/methodology and the SSRN whitepaper (abstract_id=6712722).