Last week a reader left a comment on one of our posts that was sharper than most product feedback we get. The point, paraphrased: a hash-time-locked contract is Sybil-blind. It cannot distinguish a real counterparty from a fake one, or one identity from ten thousand spun up by the same actor. The implication hanging in the air was: isn't that a problem?
It is worth answering carefully, because the honest answer is no, that blindness is the point - and understanding why draws a clean line between two things that agent-settlement systems keep conflating.
What an HTLC actually guarantees
Start with the mechanism. A cross-chain atomic swap has two control parameters.
The hashlock. One party picks a secret s and publishes H = SHA-256(s). Both legs of the trade - say an asset on Ethereum and an asset on another chain - are locked so they can only be claimed by revealing a preimage of H. Because both legs bind to the same H, revealing s to claim one leg exposes it on-chain, which lets the counterparty claim the other. Either both legs complete or neither does.
The timelock. If nobody reveals s, funds cannot sit locked forever. Each leg has a timeout after which the original owner refunds. The second mover gets the earlier deadline so the first mover cannot reveal at the last second and grief them.
Now read those two rules again and notice what is not in them: identity. The contract never asks who you are. It checks one thing - can you produce a preimage of H before the timeout - and enforces the outcome. That is the whole trust model. It is why the settlement is trustless and non-custodial: safety does not rest on knowing, trusting, or verifying the counterparty. It rests on the math.
So when the reader says the contract is Sybil-blind, they are exactly right, and it is the same statement as "the contract is trustless." You cannot have one without the other. The moment settlement safety starts depending on who the counterparty is, you have reintroduced the thing atomicity was built to delete.
What Sybil-blindness covers, and what it does not
Here is the distinction worth internalizing. There are two different risks in any trade:
Default risk - the counterparty takes your asset and gives nothing back, or disappears mid-trade. Atomic settlement eliminates this completely, for real and fake identities alike. A Sybil army cannot beat an HTLC any better than a single honest party can; the contract simply refunds you if the trade does not complete. Blindness is a full defense here.
Selection risk - do you want to enter this trade with this address at all? Maybe it is a wash-trading cluster inflating volume. Maybe it is an address you are not permitted to transact with. Maybe you want to route only to counterparties with a settlement history. Atomicity says nothing about any of this, because it was never supposed to.
The mistake is expecting one primitive to solve both. It cannot, and it should not try. A settlement layer that starts screening identities to decide whether to settle is no longer a neutral settlement layer - it is a gatekeeper, and gatekeepers are the custodial intermediaries we removed.
The wash-trading data makes this concrete
A July study of on-chain agent-payment activity found that a large share of the reported "volume" was fictitious or moving inside linked internal clusters - value cycling between addresses controlled by the same actor to manufacture the appearance of activity. That is Sybil behavior at the payment-rail layer, and it is instructive for settlement.
Atomic settlement does not create fake volume - there is no incentive to wash-trade through an HTLC, because both legs move real assets atomically and you gain nothing by swapping with yourself. But it also does not flag it. If an agent wants to avoid quoting against a known wash cluster, or wants to prefer counterparties with genuine history, the settlement contract is the wrong place to ask. It is blind on purpose.
The two-layer split
So we keep the two problems apart by design rather than blurring them into one contract:
Layer 1 - settlement. Trustless, identity-blind, atomic. Live on Ethereum mainnet today. Sui contracts are deployed and CLI-tested; Bitcoin is validated on signet. This layer never learns or checks who you are, and it never will, because that is the property that makes it safe.
Layer 2 - selection. An optional Verified Counterparty Directory an agent can consult before it enters an RFQ. It answers a different question - "is this counterparty one I want to engage?" - using attestations, history, and reputation signals. It can consume external identity primitives rather than reinventing them; ERC-8004 (trustless agents, identity and reputation) is a natural source, and a directory is a consumer of those attestations, not a competitor to them.
The critical architectural rule: settlement never depends on the directory. You can trade with an unlisted counterparty and the atomic guarantee is identical - your money still never leaves your wallet until theirs arrives. The directory changes whom you choose to quote, never whether the settlement is safe. If Layer 2 is offline, wrong, or gamed, Layer 1 is unaffected. That one-way dependency is what lets you add counterparty verification without smuggling trust back into the settlement path.
Why the separation matters for agents specifically
An autonomous agent negotiating trades across chains needs both answers, but at different moments. At selection time - deciding whom to send an RFQ to - a reputation signal is useful and worth paying for. At settlement time - locking the funds - the only thing that should matter is the contract, because that is the moment where trust would be most expensive to get wrong. Collapsing the two means an agent's settlement safety becomes only as good as its identity oracle. Keeping them separate means the worst a bad directory can do is send you a quote you did not want - not lose your funds.
Sybil-blindness, in other words, is not a gap to be patched inside the settlement layer. It is the feature that lets everything above it stay optional.
The open question
If settlement must stay identity-blind and selection lives above it, where exactly should the line sit? How much verification belongs in a directory an agent queries by choice, versus signals baked into the RFQ layer itself - and what should an agent be allowed to trade against with zero counterparty information, relying purely on atomicity? Curious how others building agent-commerce infrastructure are drawing that boundary.
Settlement layer, live on Ethereum mainnet: hashlock.markets/docs. The MCP server (hashlock-tech/mcp, scoped) is on npm. Methodology behind the volume and wash-trading framing: hashlock.markets/methodology. Academic foundation on SSRN.
Top comments (0)