There are two trust questions hiding inside every trade, and we keep collapsing them into one.
The first: will this trade settle safely? The second: should I be trading with this counterparty at all? Atomic settlement answers the first one completely and the second one not at all - and as long as a human sits in the loop, that's been fine. The human handles question two. The protocol handles question one. The moment you remove the human, the gap shows.
What atomic settlement actually guarantees
A hash-time-locked atomic swap makes one promise: the whole trade clears, or none of it does. One secret governs the deal. Reveal it and every leg opens; let the timeout pass and every leg refunds. There is no intermediate state where you've paid and received nothing, and no custodian sitting in the middle holding the asset while you hope. Your funds never leave your wallet until the counterparty's arrive.
That is a strong guarantee, and it is narrow on purpose. It is a statement about execution. It says nothing about who is on the other side. A counterparty can be a scammer, a defaulter, a bot that quotes garbage prices, or a perfectly honest desk - and the settlement layer treats all of them identically, because its only job is to make sure that whoever they are, they can't take your money and run. Settlement removes the theft risk. It does not remove the selection risk.
For a person doing one large bilateral trade, selection risk is handled offline. You know the desk. Someone did onboarding. There's a relationship, a phone number, a reputation built over years. None of that lives on-chain, and none of it needs to, because a human is standing between the agent and the decision.
The selection problem doesn't survive autonomy
Now take the human out. An AI agent rebalancing a portfolio, paying a vendor, or sourcing liquidity across chains is going to face counterparties it has never seen, at hours when no one is watching, at a cadence no human could supervise. Tools like Anthropic's MCP make this the default mode rather than the exception: the agent gets a settlement primitive and starts trading.
Ask the obvious question and the gap is immediate. When your agent picks a counterparty at 3am, what does it actually know about them? Today, honestly: almost nothing it can verify itself. It can't call a desk. It can't read a credit file. It can't lean on a years-long relationship it doesn't have. The human apparatus for answering "should I trade with this party" simply does not port into an autonomous loop.
You can paper over this with a custodian - route every agent trade through an intermediary that vets counterparties for you. But now you've reintroduced exactly the trusted middleman that atomic settlement was designed to remove, and you're trusting it with both the selection and the funds. That's a step backward dressed up as convenience.
What a counterparty layer has to look like
If the answer can't be a custodian, it has to be something an agent can check on its own, cryptographically, without asking permission. Concretely, a counterparty layer for autonomous agents needs three properties:
- Cryptographic identity. A counterparty is a key, not a claim. The agent verifies who it's facing the same way it verifies a signature - no central registrar attesting on someone's behalf.
- A verifiable track record. Settlement history, completion rates, refund behavior - on-chain, queryable, and impossible to silently rewrite. Reputation as recorded fact, not as a star rating somebody controls.
- No central rater holding the keys. The moment one party gets to decide who's "verified," you've rebuilt the custodian's gatekeeping power in a new costume. The directory has to be something agents read from and write to by behaving, not something a company curates.
This is the primitive we've been calling a Verified Counterparty Directory: identity plus on-chain history that any agent can check before it commits, paired with atomic settlement that guarantees the commit itself is safe. Settlement says you won't be robbed. The directory says here's who's worth trading with. Autonomous agents need both, and right now most of the conversation is only about the first.
It's worth saying plainly where this sits today: the settlement layer is real and running, and the directory is a primitive we're designing toward, not a finished product we're claiming agents already use. Rails ready, trains coming. The honest framing matters more than the hype.
We're not the only ones pointing here
The ERC-8004 "Trustless Agents" work - agent identity and reputation as a standard, with a v2 that leans into MCP - is aiming at the same target from the identity side. We read that as validation, not competition. When an emerging standard and an independent settlement project converge on "agents need verifiable counterparty identity and history," the category is probably real rather than a single team's hunch. The settlement layer and the identity layer are complementary; the interesting work is in how they compose.
The honest tradeoffs
A directory is only as honest as its inputs. On-chain history is tamper-evident, but Sybil identities, wash trading to inflate a record, and cold-start problems for brand-new counterparties are all real and unsolved-by-default. Cryptographic identity tells you that a key is consistent, not that the human or agent behind it is trustworthy. None of this is magic, and anyone selling it as magic should worry you. The point isn't that a directory eliminates selection risk - it's that it moves selection risk from "impossible for an agent to assess" to "assessable from data the agent can verify itself."
The architecture today: sealed-bid RFQ plus HTLC atomic settlement, fused, with no bridge and no custodian. Ethereum mainnet is live end-to-end. BTC is signet-validated with mainnet pending. Sui contracts are deployed and CLI-tested. The MCP server exposes the settlement tools agents use today; the counterparty directory is where the design is heading next.
Background on the settlement model and volume methodology is in the docs: https://hashlock.markets/docs/?utm_source=devto&utm_medium=post&utm_campaign=2026-06-03-counterparty-directory and the academic treatment is on SSRN: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
So here's the question I keep coming back to: if an AI agent picked its next counterparty without you in the loop, what's the minimum it should be able to verify before it commits funds - and who gets to decide what counts as verified?
Top comments (0)