Two numbers came out of the agent economy this week, and together they draw a line that most settlement discussions blur.
First: AI agents initiated roughly 14 million transfers through x402 in the past 30 days, led by Base (7.3M) and Polygon (5.6M), almost entirely in USDC. Across all participants, the protocol moved about 75 million transactions worth roughly $24 million. Average payment: around $0.32.
Second: the first live implementation of ERC-8183 - the standard for escrowed agent jobs - is running on BNB Chain mainnet, with Google and AWS listed among launch partners.
Read those together. The payment leg of the agent economy is scaling by count, not by value: tens of millions of transfers, cents each. And the infrastructure now arriving for the bigger trades is not a payment rail at all. It is a judging stack. That deserves a careful look, because the judging stack is the right answer for one category of agent commerce and the wrong one for another - and the boundary between them is sharper than the marketing on either side suggests.
The judge stack, described accurately
ERC-8183 (also called APEX) standardizes the lifecycle of an agent job: creation, funding, submission, evaluation, settlement, refund. BNB Chain's Agent SDK, live on mainnet since May, packages it as one of four modules - ERC-8004 for identity and reputation, ERC-8183 for commerce and escrow, MPP + x402 for payments, and BNB Greenfield for agent memory.
The escrow flow works like this: a client agent locks a budget in the contract. A worker agent submits a result. An evaluator scores the submission, and funds release or refund accordingly. For contested outcomes, the SDK extends ERC-8183 with UMA's Optimistic Oracle: if nobody challenges the result, the job settles quickly; if someone does, the dispute escalates to UMA's Data Verification Mechanism, where token holders vote on the resolution.
It is worth saying plainly: for subjective deliverables, this is the correct architecture. "Did the agent write good code?" "Was this research summary accurate?" "Did the design match the brief?" No hash function can answer these questions. Someone - or some incentive-weighted crowd - has to judge. ERC-8183 turns that judgment into a standardized, on-chain process with economic accountability at every step. If your agents are hiring each other for work whose quality is a matter of opinion, an escrow-plus-evaluator design is not a compromise. It is the requirement.
The recursion problem
But notice what the dispute path actually is: evaluator, then optimistic oracle, then token-holder vote. Each layer exists because the layer below it might be wrong or corrupt. The evaluator judges the work. The oracle's challenge window judges the evaluator. The token vote judges the challenge. Every escalation adds a trusted party, a time window, and a cost.
This is not a design flaw. It is the honest price of settling subjective outcomes, and ERC-8183 pays it more transparently than most Web2 arbitration ever did. But it means the stack's final answer to "who arbitrates the arbiter?" is: a vote by holders of a third-party token, on a timeline measured in challenge windows.
For a disputed $200 code-review job, that is a reasonable place to end up.
For a 40 ETH asset swap between two agents that met 200 milliseconds ago, it is a strange place to end up - because that trade never needed a judge in the first place.
The category where completion is math
An asset exchange has a property that a service deliverable does not: completion is objectively verifiable at the protocol level. If the question is "did I receive asset Y in exchange for asset X?", the answer does not require an evaluator's opinion. It is a state transition that either happened or did not.
Hash Time-Locked Contracts settle exactly this category. Both sides lock funds against the same hash. Revealing the preimage claims one leg and simultaneously makes the other leg claimable - the claim transaction itself is the proof of completion. If the preimage is never revealed, both sides refund after timeout. There is no submission to score, no result to challenge, no dispute to escalate. The settlement's verification is the settlement.
The trade-offs are real and worth stating unprompted: capital is locked for the duration of the window, timeout parameters need care, and the model applies to exchange - it cannot judge quality, because there is no quality to judge. That last limitation is precisely the point. A mechanism that cannot arbitrate is only acceptable where nothing needs arbitration, and asset exchange is that place.
A decision rule instead of a turf war
So the line for builders is not "escrow versus atomic" as competing products. It is one question about the trade itself:
Is completion a verdict or a fact?
If completion is a verdict - a judgment about quality, accuracy, or fit - use an escrowed job standard with an evaluator and a dispute path. ERC-8183 is becoming the schelling point for that, and the fact that it now runs on mainnet with serious partners validates the whole thesis that agents will transact with each other at scale.
If completion is a fact - asset X moved against asset Y - use atomic settlement, where the cryptography carries the burden of proof and no third party ever holds the funds or the verdict. This is the layer we build at Hashlock: sealed-bid RFQ for price discovery, HTLC settlement for execution, exposed to agents as an MCP server with six tools (create_htlc, get_htlc, withdraw_htlc, refund_htlc, swap_quote, swap_execute), currently v0.6.0 on npm as @hashlock-tech/mcp. Ethereum mainnet is live end-to-end today; Sui contracts are deployed and CLI-tested with gateway wiring in progress; Bitcoin is signet-validated with mainnet pending.
The x402 numbers suggest how the market may split. Thirty-two-cent average payments are metering: agents paying for API calls and content, high count, low consequence, no judge needed because the worst case is losing cents. Escrowed jobs are the middle: real value, subjective completion, judge required. Asset exchange is the third category: value can be arbitrarily high, completion is objective, and inserting a judge adds cost, latency, and a trusted party where none is structurally necessary.
Three categories, three mechanisms. The teams building each one are not actually competing yet - most of the apparent conflict comes from all three using the word "settlement."
Where this gets tested
The honest open question, and the one worth debating: how much of agent-to-agent value (not count) will sit in each category? If agent commerce turns out to be mostly services, the evaluator stack handles the majority of value and atomic settlement stays a specialized instrument. If agents end up rebalancing portfolios, paying each other across chains, and treasurying in different assets - the pattern every trading desk already exhibits - then the highest-value flows are exactly the ones where the judge is unnecessary overhead.
We have an obvious position in that debate, and we hold it with a falsifiable claim rather than a slogan: for objectively verifiable exchange, a mechanism with no arbiter strictly dominates one with an arbiter, because every arbiter is an added trust assumption and every added trust assumption is an attack surface. The whitepaper formalizing the sealed-bid RFQ + HTLC design is on SSRN (https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722) for anyone who wants the mechanism-level argument. Docs: https://hashlock.markets/docs?utm_source=devto&utm_medium=article&utm_campaign=2026-08-20-evaluator-vs-atomic
Where do your agents' trades fall? Have you shipped a workflow where completion was objective enough to skip the evaluator - or one where you learned the hard way that it wasn't?
Top comments (0)