On June 23, Circle published the official USDC specification for the Machine Payments Protocol. The mechanics are elegant: an agent calls an MPP-enabled endpoint, the server answers with HTTP 402 Payment Required, the agent signs an EIP-3009 USDC authorization and retries, and Circle Gateway verifies and settles - batched, with a crosschain profile, no API keys, every request attributable to a wallet address. It's part of the Agent Stack Circle has been assembling since May, and it already has its first USDC-backed derivative (USDCx on Stacks) building against the spec.
A few months before that, ERC-8183 - "Agentic Commerce," proposed by Virtuals Protocol and the Ethereum Foundation's dAI team - specified a different verb. Not paying: hiring. A Client agent posts a job and locks the budget in on-chain escrow; a Provider agent does the work and submits proof; an Evaluator confirms the deliverable before funds release or refund. BNB Chain shipped the first live implementation, the BNBAgent SDK, bundling ERC-8004 identity, escrow, and decentralized arbitration into one framework - on testnet now, mainnet planned.
So in the space of a few months, machine commerce got two of its three verbs standardized.
Machines can pay - and that lane is getting crowded. MPP joins x402, which Chainalysis has reportedly tracked past 100 million agentic payments on Base, with a foundation member list that reads like a who's-who of TradFi and cloud. Google's AP2 handles the intent-and-mandate layer above. Stripe has been reported working with Cross River Bank on bank-grade single-use cards so agents can spend autonomously, and Mastercard spent June pitching "Agent Pay for Machines." Card networks don't build for markets they think are hypothetical.
Machines can hire: ERC-8183, with an implementation you can run today.
The third verb - trade - has no spec. And it's the verb where the money is at risk in a way the other two never are.
Look at the structure of each interaction, not the branding.
A payment is one leg. Value moves in a single direction against a service that has already been rendered or is about to be. The failure mode is small and bounded: you paid for an API call that didn't return. MPP is well-designed precisely because it embraces this - sub-penny amounts, batched settlement, optimistic trust. For pay-per-call, that's the right trade-off.
A hire is subjective. Did the research report actually answer the question? Is the generated code any good? Someone has to judge, which is why ERC-8183's Evaluator role exists and why it's the most interesting part of the standard. The escrow-plus-judge pattern is essentially arbitration rebuilt on-chain - and for subjective deliverables, a judge genuinely earns its place. There is no cryptographic test for "the essay was good."
A trade is two-sided and objective. Two parties exchange asset for asset - ETH for USDC, BTC for ETH - and the entire risk is simultaneity. Whoever moves first hands the other side a free option. There is nothing subjective to evaluate: either the counterparty's asset verifiably arrived or it didn't, a fact a contract can check without any judge at all.
Run a trade through the pay-spec and you've recreated settlement risk: one side authorizes a transfer, then waits and hopes. (A solver or card issuer front-paying and reconciling later looks atomic from the user's seat - but underneath, someone's balance sheet is holding the risk.) Run it through the hire-spec and you've placed an Evaluator - trusted, bribable, censorable - in the middle of something a hash comparison could have verified. Custodial rails solve it by becoming the intermediary. Bridges solve it by pooling everyone's assets into what history keeps demonstrating is a honeypot.
Every one of those imports a trust assumption that the trade itself doesn't require.
If someone sat down to write the missing standard, the requirements list falls out of the structure: Price discovery without information leakage. An agent that broadcasts "I need to sell 50 ETH" has already moved the price. Sealed-bid RFQ - quotes committed before any are revealed - is the machine-native answer, and it's also where agents quietly beat humans: a machine can genuinely not leak its order flow.
Atomic execution. Both legs lock to the same cryptographic condition. The secret that claims one leg is, by construction, the proof that unlocks the other. Both legs clear or neither does. This is the hash-time-locked contract, a primitive that has existed since roughly 2013 - the spec race is new, the answer is not.
Automatic refund. If the trade doesn't complete inside its window, both sides get their funds back without anyone's permission. No stuck states, no support tickets, no judge.
Asymmetric timeouts. The subtle one: the two legs cannot expire at the same moment, or the party who reveals the secret can be front-run at the boundary. Any serious spec has to encode the timeout ordering, not leave it to implementers.
Verification as a layer, not a custodian. Knowing who you're trading with (ERC-8004-style identity, counterparty directories) belongs above settlement - informing the decision to trade, never holding the assets.
Agents are already trading. ClawBank's "Manfred" was reported by CoinDesk in May as the first autonomous company filing with its own EIN, bank account, and crypto wallet. Olas's Polystrat agent reportedly cleared 4,200+ prediction-market trades in its first month. Whatever the exact numbers, the direction is unambiguous - and every one of those agents is settling through custodial accounts or standing credentials, meaning each one carries the "compromised agent forfeits everything it holds" blast radius we wrote about yesterday.
The rails for paying and hiring are being standardized in public, at speed, by well-funded teams. The rails for trading are the gap.
We've been building in that gap. Hashlock Markets fuses the two halves a trade spec needs - sealed-bid RFQ for price discovery, HTLC settlement for execution - behind six MCP tools: RFQ creation and response, HTLC lock, withdraw, refund, and status. Any MCP-capable model can drive the full trade lifecycle from the agent's own wallet, published as the scoped npm package @hashlock-tech/mcp
.
Chain status, stated plainly: Ethereum mainnet is live end to end. Sui contracts are deployed and CLI-tested with gateway wiring in progress. Bitcoin is validated on signet with mainnet pending. So today, "live" means Ethereum. The V1 contracts are immutable and went through a five-layer verification pipeline - Slither, Halmos symbolic execution, Echidna fuzzing, Stryker mutation testing, and a runtime invariant monitor. The formal treatment is in our SSRN paper.
To be clear about the map: none of the specs above are competitors. An agent in 2027 will plausibly pay for its API calls over MPP, hire a specialist over ERC-8183, prove its identity over ERC-8004 - and settle its asset trades atomically underneath all of it. Different verbs, different layers. The stack is being assembled in public, one spec at a time, and the trading layer is the one still written in working code rather than standards prose.
Honesty section. Atomic settlement bounds what a compromised or confused agent can lose to the single trade in front of it - it does not make the agent smart. A valid-but-dumb trade (wrong price, wrong size) still executes; sealed bids and per-trade caps shrink that risk without zeroing it. Funds locked in a pending trade are unavailable until completion or refund - capital efficiency is a real cost. And key custody is its own layer: no settlement design rescues a stolen signing key.
If the trade spec does get written, where should it live - as an ERC, as a de-facto MCP tool-shape convention, or as a Circle-style method registry with multiple implementations? And what would it take for you to hand an agent real value against it? Docs and the live protocol: hashlock.markets/docs - MCP server source: GitHub