DEX volume is one of the easiest numbers in crypto to inflate and one of the hardest to audit. Wash trades, both-legs counting, "volume" recognized at quote time instead of settlement time - the tricks are old, and the dashboards rarely tell you which ones a venue is playing.
This matters more in the agent economy than it ever did for humans. An AI agent choosing where to route a trade doesn't get vibes from Discord. It gets a number from an aggregator API. If that number can't be independently recomputed, it isn't a metric - it's marketing, and for an autonomous allocator it's an attack surface.
So today's product post is a transparency post: exactly how we count Hashlock Markets volume, what we refuse to count, and the three public surfaces where you can check our math. (Full version lives at our methodology page.)
The unit of volume: a settled withdraw, nothing else
On Hashlock, settlement is the trade. Both sides of an RFQ lock funds in Hash Time-Locked Contracts on their respective chains under a shared sha256 hashlock. When the taker reveals the preimage on one leg, the maker claims the other leg with the now-public preimage. Both legs settle, or both refund after the timelock.
A unit of reported volume is the USD notional of a settled HTLC withdraw on a given chain - the moment the Withdraw event (EVM) or HTLCClaimed event (Sui package) is emitted, meaning the preimage was revealed and funds actually moved to the receiver.
What is deliberately not counted:
- Refunded HTLCs. Timelock expired, no preimage, money went home. That's a failed trade, not volume.
- Locked-but-unclaimed HTLCs. Volume is recognized at claim time, not lock time. A lock is a promise; a claim is a trade.
- Off-chain RFQ activity. Quotes and sealed bids are not trades. A venue counting quote flow as "volume" is counting conversations.
- Protocol fee transfers. Fees are fees. They get their own line.
The double-counting problem, handled the boring way
Every cross-chain trade emits one withdraw per leg - one on each chain. Summed naively, protocol-level volume is roughly 2x the unique-trade value. Some venues quietly enjoy that 2x. Our DefiLlama adapter instead sets doublecounted: true, so DefiLlama can deduplicate at the protocol level while per-chain views stay accurate as "value transferred via Hashlock HTLCs on this chain."
We'd rather under-claim than inflate. In a market that's about to be navigated by software, the venues that survive audits will be the ones that were boring about this from day one.
Three places to check our math
-
The contracts, verified on Etherscan. Three HTLC contracts on Ethereum mainnet (Ether, Ether+fee, ERC-20+fee), deployed 2026-04-09. Volume reads straight from
HTLCETH_Withdraw/HTLCERC20_Withdrawevents - amount and token are on the event itself, no back-join needed. - Open Dune queries. ETH events, Sui events, and a unified cross-chain trades query, mirrored on GitHub. The public dashboard shows the settled-trade counter and daily volume from the same SQL.
- The DefiLlama adapter source. The dexs/hashlock-markets adapter in DefiLlama's dimension-adapters repo is the literal code that produces the number on the listing. If we changed how we count, the diff would be public.
One detail worth calling out for builders: Sui's HTLCClaimed event doesn't carry amount or coin type, so the adapter joins each claim to its HTLCLocked event by htlc_id and reads notional from the lock side - counting only locks whose IDs also appear in a claim within the day window. Event-schema quirks like this are exactly where silent volume inflation usually hides; documenting the join is part of the methodology.
And the chain-status fine print, because precision is the whole brand here: Ethereum mainnet is live end-to-end. Bitcoin HTLCs (native P2WSH scripts, no contract to deploy) are signet-validated, and a v2 adapter for BTC is planned for when mainnet BTC trades are observable - classification there requires parsing the spending transaction's witness stack, since Bitcoin has no event log. Sui contracts are deployed and CLI-tested - the inaugural $1.00 smoke settlement is visible in the public Sui events query - with full production wiring still in progress.
Why a tiny protocol publishes an audit trail
Honest answer: our volume is small. The smoke trade that opened the Sui events query is literally one dollar. Publishing a reproducible methodology when your numbers are modest feels backwards - transparency is supposed to be what big venues owe the market, not what small ones lead with.
We think it's the opposite. The agent economy is going to industrialize metric-gaming: synthetic flow is cheap to generate and agents are tireless at generating it. The only volume numbers that will mean anything are the ones a third party - or a third party's agent - can recompute from chain data without asking permission. We'd rather establish that standard at $1 than retrofit it at $1B.
If you're building a venue, an aggregator, or an agent that consumes venue metrics: what would it take for you to treat a reported volume number as load-bearing? Event-level reproducibility? Independent indexing? Something stronger? Tell me what we're still missing.
Hashlock Markets - the atomic settlement layer for the agent economy. Methodology: hashlock.markets/methodology · MCP server: hashlock-tech/mcp on npm · Whitepaper: SSRN
Top comments (0)