Anyone can claim volume. Here's how to recompute ours from public chain data.

Revised October 2026. First published June 2026. Product facts updated to match the live protocol; the argument is unchanged. Reference: https://docs.hashlock.markets

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 where you can check our math. (The protocol is documented at docs.hashlock.markets.)

The unit of volume: a settled claim, 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 initiator reveals the preimage on one leg, the counterparty 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 claim: the moment the claim event is emitted on the leg that was claimed first, meaning the preimage was revealed and funds actually moved to the receiver. The amount is that leg's escrowed amount, booked on the chain where the claim landed.

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 claim 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 counts each trade once, at the first claim of its hashlock. The secret holder claims the leg that pays them first (the short-timelock leg), and that claim reveals the secret; every later claim with the same secret is the other half of the same trade and is skipped. The hashlock of a claim is sha256 of the secret it reveals, so claims are matched across every indexed chain without trusting any funding event.

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.

Where to check our math

1. The contracts, verified on Etherscan. The first HTLC contracts went to Ethereum mainnet on 2026-04-09; today an HTLCFactory on Ethereum, Base and Robinhood Chain deploys one escrow clone per leg at a deterministic address, so the exact escrow is checkable before funding. The TRON leg is a shared HTLC pool contract and the Solana leg is a program with one escrow account per leg; all three are public and the adapter indexes all of them.
2. 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: not every chain's claim event carries amount or coin type, so the adapter reads the notional from the escrow the claim lands on, and it reads claims and fundings over a 3-day lookback, which covers the protocol's 24h and 4h timelocks. Event-schema quirks like this are exactly where silent volume inflation usually hides; documenting them in the adapter itself is part of the point.

And the chain-status fine print, because precision is the whole brand here: Bitcoin, Ethereum, TRON, Solana, Base and Robinhood Chain are live on mainnet end-to-end. Bitcoin HTLCs (native P2WSH scripts, no contract to deploy) are the hardest leg to index: Bitcoin has no event log, so the adapter does not read Bitcoin legs directly. A trade with a Bitcoin leg is still counted, through its other leg: the Bitcoin leg carries the long 24h timelock, so the other leg is the one claimed first.

Why a tiny protocol publishes an audit trail

Honest answer: our volume is small. Our first smoke settlement was 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. Docs: docs.hashlock.markets · MCP server: @hashlock-tech/mcp on npm · Whitepaper: SSRN