The agent economy this week: four ways to pay, zero ways to know who you're paying

Four teams shipped progress on agent commerce this week: Mastercard's agent-payment program records authorizations on Polygon, Coinbase's x402 protocol expands to mainstream web infrastructure, Eco provides cross-chain stablecoin orchestration, and ERC-8004 offers an identity and reputation layer for agents. While payment rails for agents are advancing, the problem of agent-to-agent trade—requiring atomic settlement and counterparty discovery—remains largely unsolved, with ERC-8004 being the most notable effort to address the counterparty gap.

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. 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. 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 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. 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. 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: 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. 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. hashlock-tech/mcp scoped on npm, or connect hashlock.markets/mcp as a remote MCP connector.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?