Most weeks in the agent economy look like a pile of unrelated announcements. This one had a theme hiding in it. Four different teams shipped progress on agent commerce, and if you line them up, they're all solving the same half of the problem — and all leaving the same half open.
This is a builder's map. No leaderboard, no "who wins." Just what each thing is, what it does well, and the question none of them answer yet.
The rails that shipped
Mastercard Agent Pay for Machines. Mastercard's agent-payment program continues to roll, with 30+ partners spanning crypto and TradFi (Aave Labs, Alchemy, Anchorage, BVNK, Coinbase, MoonPay, OKX, Polygon, Ripple, Solana). The mechanically interesting part: agent payment authorizations get recorded to Polygon. A TradFi network is writing agent-spend permissions on-chain. That's a real signal about where this is heading.
x402. Coinbase's HTTP-402 payment protocol keeps expanding its reach — it's now usable behind mainstream web infrastructure (AWS/CloudFront paths), which lowers the integration cost for ordinary web services to charge agents per request. Worth noting alongside the growth: standalone x402 transaction volume is well off its peak (OKX Ventures put the drop around 92% from the November high). The protocol is spreading even as raw volume cools — rails proliferate faster than they fill.
Eco. A cross-chain stablecoin orchestration layer that abstracts routing, solving, and finality across ~15 chains. Where a payment intent can't move natively, Eco figures out the path. This is genuinely useful — it's the "make the stablecoin show up on the right chain" problem — but orchestration is routing, not atomic exchange.
ERC-8004 (Trustless Agents). Not a rail at all — an identity and reputation layer for agents, with a v2 direction that leans into MCP. This is the one that actually points at the gap the others leave. More on that below.
The thing they have in common
Mastercard, x402, and Eco are all answers to "how does an agent move value?" Mastercard authorizes and records it. x402 prices and collects it per request. Eco routes it to the right chain. These are payment problems, and they're being solved well.
A payment is one-directional and to a known party: agent → seller, one asset, one way. The recipient is already chosen — you bought something from a store you picked. The hard parts are authorization and delivery, and that's exactly what these rails nail.
But a trade is different. The moment your agent wants something in return — my asset for yours, possibly across two chains — you have two problems the payment rails don't touch:
- Atomicity. Both legs must clear together or both must refund. A one-way rail can't express "all-or-nothing across two transfers." The usual patch is an escrow that holds both sides — which just relocates the risk into a custodian you now have to trust to be solvent and honest.
- Counterparty. Who is the other side? For a payment, you already know — you chose the merchant. For an open trade between two agents that have never met, somebody has to answer "is this stranger safe to trade with?" before settlement even matters.
Atomicity is a settlement problem, and hash-time-lock contracts (HTLCs) handle it: both parties lock funds against one hash preimage on a timelock; reveal the secret and the whole trade clears, stay silent and the whole trade refunds. No half-settled state, no custodian in the middle. That part exists today and is live on Ethereum mainnet.
The counterparty problem is the one almost nobody is building for agents — and it's the reason ERC-8004 is the most interesting item on this week's list.
The counterparty gap
Think about how fast agent tool discovery has become. With MCP, an agent can find and connect to a new capability in seconds — search a registry, OAuth in, start calling tools. Discovery of what an agent can do is nearly solved.
Discovery of who an agent should trade with is not. Today it's manual: a human vets the counterparty, or you simply don't trade with strangers. That's fine for a payment to a known merchant. It falls apart the moment you want open, agent-to-agent markets where counterparties aren't pre-selected.
ERC-8004 is the ecosystem starting to take this seriously — standardizing agent identity and reputation, with MCP in the v2 picture. It's complementary to settlement, not competitive: identity tells you who, settlement guarantees the trade clears. You need both, and they're being built in different places.
The primitive that closes it: a Verified Counterparty Directory
Here's the piece we think the settlement layer needs, and the design we're working toward: a Verified Counterparty Directory — a registry of attested counterparty identities that plugs directly into atomic settlement.
The shape of it:
- Attestation, not gatekeeping. A counterparty carries verifiable claims (identity, track record, tier) that an agent can read before quoting. Small or anonymous swaps stay permissionless; larger or regulated flows opt into higher assurance. Trust as a dial, not a single KYC gate for everyone.
- Settlement-coupled. The directory isn't a standalone reputation score floating in the void — it's wired into the same HTLC settlement path, so "find a counterparty" and "clear the trade trustlessly" are one flow, not two systems you bolt together.
- No custodian in the loop. Identity raises confidence; the contract still guarantees the outcome. You don't trust the counterparty or an intermediary with your funds — the timelock does the enforcing.
Put plainly: the rails move the money. The directory plus atomic settlement decide whether a stranger's trade is actually safe to make. That's the layer this week's announcements kept circling without landing on.
To be clear about status, because precision matters: atomic HTLC settlement is live on Ethereum mainnet today. Sui contracts are deployed and CLI-tested (gateway wiring in progress); Bitcoin is signet-validated with mainnet pending. The Verified Counterparty Directory is a primitive on our roadmap, described here as a design — not a shipped feature. Rails ready, trains coming.
Why this matters for builders
If you're building agents that only ever pay known merchants, the payment rails above are probably all you need — pick the one that fits your chain and billing model. If you're building toward open markets where agents trade with counterparties they didn't pre-select, you'll hit the counterparty question fast, and you'll want it answered in a way that couples cleanly to trustless settlement rather than reintroducing a custodian.
The honest tradeoffs of the HTLC approach still apply — capital is locked for the timelock window, and you take on timeout/refund handling. We think that's the right price for removing the intermediary entirely. Reasonable people weigh it differently depending on latency tolerance and trade size.
- Try the MCP server:
hashlock-tech/mcp(scoped) on npm, or connecthashlock.markets/mcpas a remote MCP connector. - Protocol and methodology: https://hashlock.markets/methodology?utm_source=devto&utm_medium=article&utm_campaign=2026-06-20-verified-counterparty-directory
- The academic foundation, if you want the formal version: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
Question for the builders reading: if your agent could settle atomically with any stranger, what would you actually need to know about the counterparty first — verified identity, on-chain track record, or nothing at all? Where's the line for you?
