Revised October 2026. First published May 2026. Product facts updated to match the live protocol; the argument is unchanged. Reference: https://docs.hashlock.markets
Yesterday afternoon (2026-05-11, ~13:51 UTC), an external maintainer merged our DEX volume adapter into the DefiLlama dimension-adapters repo. PR #6778 is closed, merged. The adapter will start surfacing in api.llama.fi/protocols and at defillama.com/protocol/hashlock-markets after the next ingest cron: typically 1-6 hours, sometimes longer.
This is the first time Hashlock Markets has shown up on a mainstream crypto dashboard via a third-party maintainer's accept: not a self-listing, not a press release. So the question I want to answer here, before any "listed on DefiLlama 🚀" cheering, is the boring one: what does this listing actually measure, and what does it leave out?
What the adapter tracks
The adapter is a DEX volume adapter, not a TVL adapter. The distinction matters.
For every Hashlock atomic-swap settlement, the adapter:
- Watches each indexed escrow for a claim: the cryptographic moment the trade clears, when the secret holder reveals the preimage and takes the locked assets on the leg that pays them.
- Counts the trade once, at the first claim of its hashlock. The amount is the claimed leg's escrowed amount. Every later claim with the same secret (the other leg) is not counted again.
- Resolves the asset to a price feed for the day.
- Reports per-asset, per-chain volume back to the DefiLlama ingestor.
It reads a 3-day lookback across the chains it indexes: the EVM HTLCFactory clones (Ethereum, Base, Robinhood Chain), the TRON SharedHTLC pool and the Solana program. Bitcoin legs aren't read directly: BTC settles via a P2WSH script address, not via a contract or program event log. A trade with a Bitcoin leg is still counted, through its other leg, which is the short-timelock leg and therefore the one claimed first.
Counting a two-leg trade once
The question every cross-chain adapter eventually has to answer: are you reporting the same trade twice (once from the seller leg, once from the buyer leg) and silently inflating the protocol's headline number?
An atomic swap produces two on-chain settlements, one per leg, each denominated in its own asset. Selling 1 BTC for 17 ETH moves the BTC leg and the ETH leg. The adapter does not add them. It counts the trade once, at the first claim of its hashlock: the secret holder claims the leg that pays them first, that claim reveals the secret, and every later claim with the same secret is recognised as the same trade and 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.
The practical consequence: when you sell 1 BTC for ETH on Hashlock, the listing shows that trade once, as the ETH leg's escrowed amount on Ethereum. Not a 2x inflation of the same dollar, and not a half-trade either.
What the adapter explicitly does not track
- TVL. Hashlock holds no protocol-owned liquidity. An HTLC locks the trader's own assets in escrow for the duration of the swap: at most the leg's timelock, 4 hours on the EVM chains, TRON and Solana and 24 hours on Bitcoin. The protocol's TVL contribution to a "DeFi TVL" number, in the way Aave or Lido contribute TVL, is zero. We don't report it because there isn't a meaningful number to report.
- Order count or RFQ activity. The listing reads settlement events. The RFQ phase (sealed-bid quote requests, maker responses, the chosen counterparty) happens off-chain on the trade service before any HTLC is created. Those are application-layer telemetry, not chain telemetry, and DefiLlama doesn't ingest them.
- Failed or refunded swaps. When a swap times out and the originator reclaims their assets via the refund path, that leg is never claimed, so it is never counted. A leg nobody ever claims adds nothing either. That's the honest read: refunds aren't trades, and they shouldn't appear in trade volume.
Why cross-chain matching is the harder half
For the EVM chains, reading claim events from the factory's clones is straightforward: JSON-RPC logs, well-trodden ground. TRON is one shared pool contract, read the same way.
For Solana, the adapter walks the program's transaction history and decodes its own Funded and Claimed events, where each escrow is a PDA of the program. Then (and this is the part that takes more code than you'd expect) it orders every claim by block time across all the indexed chains and keeps only the first claim per hashlock. The ordering exists so the reported number is the actual cleared trade, not a half-trade that looks like inflation when read in isolation.
If you've worked on cross-chain analytics before, this is the moment where the "easy" listing turns into a multi-week PR cycle. There is no third-party indexer that hands you (chainA_leg, chainB_leg, hashlock) tuples for an arbitrary HTLC protocol. You build the pairing yourself, or you live with a misleading single-side number.
What we'd like to expose alongside, eventually
The volume number is a start, not an endpoint. The adapter is public at https://github.com/DefiLlama/dimension-adapters/blob/master/dexs/hashlock-markets/index.ts. The metrics I'd actually like a reader of defillama.com/protocol/hashlock-markets to see, once we can plumb them:
- Effective fee paid (basis points). The protocol fee is a small percentage paid by the taker on top, shown before commit. A rate alone doesn't communicate much; the realized average per swap would.
- Median time-to-finality per swap. The single number that distinguishes a settlement layer that works from one that mostly times out.
- Refund rate. The honest counterpart to "successful volume." A protocol with 5% refund rate is structurally different from one at 0.2%.
- Asset coverage and chain mix. Where the volume actually clears, useful for any agent or human counterparty doing route selection.
None of these are in the merged adapter. They could be in a v2 of the adapter if DefiLlama's schema accommodates them, or in a Hashlock-side public dashboard that links back. Either way: the listing is the beginning of a public-credibility surface, not a finished one.
What the listing actually means
Concretely: an external maintainer at one of the most cited dashboards in crypto reviewed our chain integration, asked how a two-leg trade is counted, and accepted our answer. Hashlock volume, each trade counted once on the chain where it was first claimed, will show up in the same place readers go to compare DEX volumes across protocols.
That's the meaningful piece. The "🚀 we made it" framing isn't quite right: the adapter is the easy half of public credibility, and the hard half (the missing metrics above, adversarial trading volume at size) is still in progress. But for an evening's worth of one PR comment thread, the merge is a clean step toward a settlement layer that lives in the open instead of a footnote.
If you build agents that trade (and the cross-chain settlement question keeps coming up) the listing makes the underlying numbers visible without having to take our word for any of them. That was the point.
So: once a settlement layer earns a public volume number, what's the honest minimum it should expose alongside?
Read the protocol: https://hashlock.markets?utm_source=devto&utm_medium=social&utm_campaign=2026-05-12-defillama-listing
Open-source: https://github.com/Hashlock-Tech/hashlock-mcp
Full protocol spec: https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6712722
Top comments (0)