The agent economy solved 'how to pay.' It still hasn't solved 'who to trust.'

PayPal's real innovation in 1999 wasn't moving money. Banks already moved money. What PayPal did was make it safe to transact with a stranger — someone you'd never met, on the other end of an auction, who had your payment before you had your goods. Buyer protection, dispute resolution, a reputation trail. The money rail was the easy half. The trust rail was the product.

A quarter century later, the agent economy is rebuilding the easy half at high speed and mostly skipping the hard one. This week was a clean illustration, so as the weekly wrap-up, I want to pull on the one thread that ties it together rather than re-list the news.

The week, in one sentence

More ways to pay shipped; no new way to know who you're paying. Mastercard's agent-payment program kept rolling and is now recording agent authorizations to Polygon — a TradFi network writing agent-spend permissions on-chain. Coinbase's x402 kept spreading behind mainstream web infrastructure, even as its standalone transaction volume cooled hard from the November peak. Eco extended cross-chain stablecoin orchestration across roughly fifteen chains. And ERC-8004, the "Trustless Agents" identity-and-reputation standard, kept maturing with a v2 direction that leans into MCP.

Line them up and three are answers to the same question — how does an agent move value? — and exactly one points at the question the others leave open.

Why "who" is a different problem than "how"

A payment is one-directional and to a known party. Your agent buys compute from a provider it already chose; value goes one way, one asset, one hop. The hard parts are authorization and delivery, and the rails above genuinely nail them.

A trade is not that. My asset for yours, possibly across two ledgers that don't share a clock, where the other side is not pre-selected. That introduces two problems no payment rail touches:

1. Atomicity — both legs clear together or both 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 doesn't remove the risk so much as relocate it into a custodian you now have to trust to be solvent and honest.
2. Counterparty — who is the other side, and why should my agent trust them enough to lock funds at all?

Atomicity is a settlement problem, and it has a known answer. Hash-time-lock contracts (HTLCs) let both parties lock funds against a single 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 intermediary holding the bag. That part exists and is live on Ethereum mainnet today.

The counterparty problem is the one almost nobody is building for agents, and it's why ERC-8004 is the most interesting item on the week's list.

Discovery solved tools. It didn't solve counterparties.

Think about how fast tool discovery became. With MCP an agent finds a capability, OAuths in, and starts calling it in seconds. Discovery of what an agent can do is nearly a solved problem.

Discovery of who an agent should trade with is not. Today it's manual — a human vets the counterparty, or the agent simply doesn't trade with strangers. That's fine when the payee is a merchant you picked. It falls apart the instant you want open, agent-to-agent markets where the other side isn't chosen in advance. The stranger is the whole point, and the stranger is exactly what we have no automated way to assess.

ERC-8004 is the ecosystem finally treating that as first-class: identity and reputation as on-chain primitives instead of an off-chain allowlist, 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.

The part most people miss: identity has to be coupled to settlement

Here's the design trap. It's tempting to picture agent reputation as a score that lives somewhere — a registry an agent can look up before trading. But a reputation number floating beside the settlement path is weak in both directions. Read it as advisory and it gets skipped under time pressure. Read it as authoritative and it becomes a sybil target the moment it gates value, because now faking identity is worth exactly as much as whatever it unlocks.

The interesting designs bind the attestation to the action being authorized, and make identity expensive to fake in proportion to what it unlocks. Trust stops being one KYC gate everyone passes through and becomes a dial: anonymous, small swaps stay permissionless; larger or regulated flows opt into higher assurance. The check isn't a lookup you can route around — it's wired into the clearing mechanism itself.

That coupling is the piece we're building toward, and the design we'd call a Verified Counterparty Directory:

• Attestation, not gatekeeping. A counterparty carries verifiable claims — identity, track record, tier — that an agent reads before quoting, not after settling.
• Settlement-coupled. The directory isn't a standalone score in the void; it plugs into the same HTLC settlement path, so "find a counterparty" and "clear the trade trustlessly" are one flow rather than two systems bolted together.
• No custodian in the loop. Identity raises confidence; the contract still guarantees the outcome. You trust neither the counterparty nor an intermediary with your funds — the timelock does the enforcing.

Put plainly: the rails move the money, identity tells you who the stranger is, and atomic settlement makes sure the trade can't half-complete. The Verified Counterparty Directory is the seam that joins the second and third so an agent can act on them at the same instant. That's the layer this week's announcements kept circling without landing on.

Status, stated precisely

Because precision is the brand: atomic HTLC settlement is live on Ethereum mainnet today. Sui contracts are deployed and CLI-tested with gateway wiring in progress; Bitcoin is signet-validated with mainnet pending. The Verified Counterparty Directory is a primitive on the roadmap — described here as a design, not a shipped feature. Rails ready, trains coming. (For the curious: the MCP server is hashlock-tech/mcp (scoped) on npm, now also listed on the awesome-mcp-servers directory, and the protocol is listed on DefiLlama.)

The honest tradeoffs of the HTLC approach still hold — capital is locked for the timelock window, and you take on timeout/refund handling. That's the price of removing the intermediary entirely, and reasonable builders weigh it differently by trade size and latency tolerance. Reputation has its own hard parts — sybil resistance and cold-start chief among them — which is exactly why coupling attestation to settlement, rather than trusting a free-floating score, matters.

The preview

Next week the thing worth watching is whether ERC-8004's v2 makes agent identity readable at quote time rather than after the fact — because that's the difference between a reputation score and a usable counterparty signal. If the identity layer becomes settlement-adjacent, the directory pattern gets a lot more concrete.

• Protocol and methodology: https://hashlock.markets/methodology?utm_source=devto&utm_medium=article&utm_campaign=2026-06-21-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?