Atomic settlement solves theft. It does not solve time-wasting. Those are different attack surfaces, and conflating them is the most common mistake in how people reason about trust in agent-to-agent markets.
This post is a mechanics-level look at the two primitives Hashlock is designing to close the second gap: execution rewards (a stake-and-slash mechanism for quote reliability) and tiered KYC (a per-trade trust filter an agent sets itself, not a policy a custodian enforces on everyone). Both sit above the settlement core, not inside it - which matters, because it means neither one changes who can touch your funds.
The gap atomic settlement leaves open
Hash-time-locked contracts give you a clean guarantee: both legs of a trade unlock against the same secret, or neither does. Party A funds an HTLC against H = SHA256(s). The only way to claim it is to reveal s. The instant s becomes public to claim one leg, it's available to claim the other. There is no reachable state where one side's funds move and the other's don't.
That guarantee eliminates theft as an outcome. It does not eliminate griefing: an agent posts an attractive quote, watches a counterparty fund their leg, and then simply never reveals s. Nothing was stolen - the counterparty's asset is recoverable via the timelock refund path - but capital sat locked for the full timelock window for nothing. In a human market this costs the griefer their reputation. An agent spun up from a fresh wallet has no reputation to lose, so the settlement guarantee alone doesn't make griefing unprofitable.
Execution rewards: making completion the dominant strategy
The design goal is to make "reveal and settle" the cheapest strategy for a rational agent, enforced by the protocol rather than by a hosted rating system.
The mechanism, at the level we can describe it today: when an agent responds to a sealed-bid RFQ, it can post a bond sized relative to the trade - collateral it stakes on actually completing. If the trade settles (secret revealed, both legs claimed), the bond returns along with a small increment to an on-chain completion record tied to that agent's address. If the counterparty funds their leg and the quoting agent lets the timelock expire without revealing, the bond is forfeit - paid out to the counterparty that had capital locked for nothing.
A simplified sketch of the state machine:
RFQ posted (min_tier: X, size: N)
-> Agent B quotes, optionally stakes bond B(N)
-> Requester accepts, funds HTLC leg 1 against H
-> Agent B funds HTLC leg 2 against same H
-> Requester reveals s to claim leg 2
-> Agent B claims leg 1 with same s
-> settlement complete: bond returned + completion_count++
-> OR timelock_2 expires before s is revealed
-> Agent B triggers refund on leg 2
-> bond forfeit -> paid to requester as compensation
The important property: completion_count and forfeiture history live at the settlement layer itself, not in a database a company operates. You can't reset it by spinning up a new frontend, and you can't have it edited by a platform operator - because there is no platform operator sitting between the two legs. That's the difference between "the protocol enforces the incentive" and "someone we have to trust enforces the incentive."
None of this is a claim that a slashing contract is deployed and live today. It's the design layer we're building on top of an atomic-settlement core that already is - the distinction matters and is spelled out below.
Tiered KYC: a filter the agent sets, not a gate a custodian owns
Execution rewards answer "will this counterparty actually finish." Tiered KYC answers a separate question: "how much do I need to know about this counterparty before I'm willing to trade with them at this size?"
A single global answer breaks in both directions. Force full identity verification on every trade and you've killed the permissionless, anonymous-by-default property that makes an agent-native market useful in the first place. Verify nobody and you've made every regulated or large-size flow impossible. The tiered design treats verification as a property of the counterparty pool an RFQ is allowed to reach, set per request:
- Anonymous tier - wallet-only. Anyone can quote. For small size, the settlement guarantee alone is the protection; worst case is a wasted timelock window, not a stolen asset.
- Attested tier - counterparty holds a credential commitment (a hash of an attestation, not raw identity data) that can be checked on-chain without revealing the underlying document to the protocol or the counterparty.
- Regulated tier - counterparty has cleared identity verification at the level a specific regulated flow requires, checked before the RFQ is even visible to them.
The agent sets min_tier as a parameter on the RFQ. Nobody upstream picks a custodian to vouch for the trade; the agent picks how much verification it needs for that specific trade, and dials it up or down independently of settlement. A verified counterparty market is a filter you apply per request. A custodian is a party that takes possession. Those are structurally different things even when the marketing copy for either one uses the word "trust."
Where ERC-8004 fits and doesn't overlap
Ethereum's ERC-8004 gives agents an on-chain identity and reputation registry - a shared place to establish who an agent is and reference its track record. That's complementary infrastructure, not a competing approach: a reputation registry tells you what an agent has done; it doesn't make a specific trade atomic, and it doesn't have an economic mechanism that forfeits a griefing agent's capital at the moment it griefs. Execution rewards are narrower and more specific - they're tied to one settlement event, not a general-purpose reputation graph. The two are stackable: an agent could reference an ERC-8004 identity to satisfy a tiered-KYC attestation requirement, then still be subject to stake-and-slash at the settlement layer for that specific trade.
Honest status, stated the way we always state it
The settlement core these two primitives sit on top of: atomic settlement is live end-to-end on Ethereum mainnet. Sui contracts are deployed and CLI-tested - gateway wiring is still in progress, and we don't call that "live" until it is. Bitcoin settlement is validated on signet via P2WSH HTLC scripts; mainnet is pending. Execution rewards and tiered KYC are the counterparty-market design layered above that core - describe the mechanism, don't overclaim the deployment. This is a place where a settlement project cannot afford to drift, and a post about trust and verification is exactly the wrong place to start.
The MCP server that exposes the settlement core today - sealed-bid RFQ and HTLC creation fused into six tools - is hashlock-tech/mcp (scoped) on npm, currently at 0.5.1. Source is on GitHub.
The open design question
Where should the bond size sit relative to trade size for execution rewards to actually deter griefing without locking honest new agents out of the market? Too small and forfeiture is a rounding error; too large and you've reintroduced a capital barrier that looks a lot like the custodial minimum-balance requirements this whole design is trying to avoid.
Methodology write-up: hashlock.markets/methodology. Source: github.com/Hashlock-Tech/hashlock-mcp. Academic background on the settlement primitive: SSRN. If you've built or thought through a bonding curve for agent reliability, I'd like to hear where you'd set it.
Top comments (0)