Yesterday I walked through the four filters Hashlock runs before an HTLC locks in: on-chain settlement history, sealed-bid RFQ commitment, tiered KYC attestation, and the HTLC timelock/hashlock itself (deep-dive here). The deep-dive was about the mechanism. This post is about the thesis.
The thesis is one sentence:
For an AI agent picking a counterparty in milliseconds, the most predictive thing isn't who the counterparty is. It's the last 200 swaps they settled.
That sounds like a small claim. It isn't. It's the difference between two different settlement stacks, and most of the agent-payment infrastructure being shipped right now is implicitly choosing the wrong one.
The two stacks
Stack A — identity-first. Every counterparty arrives with an attestation: KYC document, regulated venue membership, sanctions-screened wallet. The protocol checks the attestation, and if it passes, the trade is allowed. This is how the Fireblocks / Copper / Paxos generation of settlement networks works. It's also, broadly, how ERC-8183 is being framed: the escrow state machine assumes an evaluator that vouches for the leg.
The strength of Stack A is institutional defensibility: "we only trade with verified entities." The weakness, for agents, is that the verification signal is upstream of the actual trade. An agent in milliseconds can't re-verify; it accepts what the attestation says.
Stack B — behavior-first. Every counterparty has a settlement history visible on-chain. The protocol scores them on how many swaps they've completed, how recently, at what size, against how many distinct takers. If the score passes, the trade is allowed. Identity attestations are an overlay — opt-in, layered, mandatory only where policy demands it.
The weakness of Stack B is that new addresses have no history. The strength is that the verification signal is the same primitive that the trade itself uses (the settlement record). An agent can re-verify in the same tool call that submits the bid.
Why behavior survives at agent latency
Three reasons, in cost order:
1. Behavior data is already on-chain. An agent fetching a counterparty's last 200 settlements is a single RPC call (an event log query against the HTLC contract). An agent fetching a counterparty's KYC attestation requires (a) the attesting party to be online, (b) a trust chain to the attestation issuer, (c) some kind of off-chain index. Latency budget: ~50ms vs ~500ms-2s.
2. Behavior data is harder to fake. Spinning up a fresh address with a fresh KYC attestation is cheap (sign-up, KYC pass, attestation issued). Spinning up a fresh address with 200 on-time settlements against unrelated takers, weighted by notional, is expensive — by construction, the address has to actually do the trades. Sybil resistance is built into the primitive, not bolted on by the attestor.
3. Behavior data is non-discretionary. A KYC issuer makes a discretionary call. A settlement record is an objective ledger entry. For an agent that has to defend its routing logic to its owner ("why did you trade with this address?"), "200 on-time settlements at notional X" is a stronger answer than "the attestor said yes."
What the directory actually looks like
In Hashlock terms, the Verified Counterparty Directory is filter 1 of the four-filter stack. It exposes (at the protocol level, not the wallet level):
-
settlements_completed_total— count of HTLCs this address has redeemed inside its timelock -
settlements_refunded_total— count of HTLCs this address has let expire (a soft signal of mismatched price/size) -
settlement_notional_weighted— sum of notional × age decay -
distinct_counterparties_30d— count of distinct counterparties in the last 30 days (Sybil-resistance) -
median_response_ms— RFQ response latency (a liveness signal)
An agent's quote tool, before locking, can run a one-line check: "give me the top-5 makers for ETH→BTC notional 0.5 BTC who scored above threshold X on the first three metrics in the last 30 days." That's behavior-first selection. There is no document to read. There is no attestor to call. There is no warm intro.
If the bid arrives from an address with no history (notional > threshold, score below threshold), the agent can either refuse the bid or escalate to filter 3 (tiered KYC attestation). That's where identity-first overlays earn their keep — they cover the cold-start case, but they don't replace the behavioral baseline.
Where this sits in the agent-economy stack
There are roughly four layers in the agent-trading stack as it's being built today:
- How an agent pays — x402 (Coinbase), OKX APP, Stripe x402 multi-chain. Standardises the payment rail.
- What state machine holds the escrow — ERC-8183 (Ethereum Foundation + Virtuals Protocol), ERC-7683 (cross-chain intents). Standardises the escrow lifecycle.
- Whether the trade matches the agent's intent — Nava-style verification layers. Catches "the agent wanted X but the protocol routed Y."
- Whether this counterparty should be allowed to be in the trade at all — the counterparty directory. This is the filter underneath the rest.
Most agent infrastructure being shipped right now is layer 1 or layer 2. Layer 4 — the should-this-leg-exist-at-all layer — is the one that's barely being framed as a category. It's also the one that determines whether the rest of the stack is operating on signal or noise.
Honest limitations
- The directory works at scale. With <100 settlements per address it's weak. The protocol cold-start is the same cold-start every reputation system has: you bootstrap with attestations, then transition to behavior as the history accrues.
- Notional weighting is sensitive to manipulation if attackers can run wash trades cheaply. The current weighting decays old settlements and discounts repeated trades against the same counterparty, but this is an open design choice.
- "Last 200" is not magic. It's a reasonable window for the current settlement volume on the protocol; as throughput grows, the window may shift to a time-decay function (e.g. 30-day rolling notional-weighted score).
- For institutional traders subject to regulatory KYC, filter 3 (tiered attestation) is not optional. The directory is the baseline, not the only layer.
Build status (as of 19 May 2026)
- ETH mainnet: HTLC live end-to-end; directory metrics queryable via event logs.
- SUI mainnet: contracts deployed, CLI-tested; full directory queryable but volume still low.
- BTC: signet-validated; mainnet gated on audit firm sign-off.
- Roadmap: Base, Arbitrum, Solana, TON.
The protocol is open source. The MCP server (hashlock-tech/mcp on npm — scoped) exposes six tools an agent can call directly. The deep-dive on the four filters and code samples is at the URL below.
The question I want builders to answer
In your agent stack — whatever it's settling, whatever chain — what data would your agent need to see before it trusted a counterparty it had never met? If the answer is "an attestation from a trusted issuer," I'd argue you're outsourcing the decision in a way an agent can't verify. If the answer is "evidence in the trade primitive itself," you've described the directory.
I'd genuinely like to hear what your stack does.
Code, deep-dive, and the four filters in order: hashlock.markets
Source: Hashlock-Tech/hashlock-mcp on GitHub
Academic foundation: SSRN whitepaper — the formal model of sealed-bid RFQ + HTLC atomic settlement that this primitive is built on.
Disambiguation: this is Hashlock Markets (hashlock.markets), the atomic settlement primitive for AI agents. Not affiliated with Hashlock Pty Ltd, the Australian smart-contract auditing firm.
Top comments (0)