# The agent economy this week: four ways to pay, zero ways to know who you're paying > Source: > Published: 2026-06-20 06:08:24+00:00 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?