Listed on DefiLlama: what the volume adapter tracks, and what it deliberately doesn't

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:

1. Watches the receiving leg of each HTLC for a Withdraw event — the cryptographic moment the trade clears, when the receiver reveals the preimage and atomically takes the locked assets on the destination chain.
2. Reads the asset address and the locked amount from contract storage.
3. Resolves the asset to a CoinGecko-style price feed for the day.
4. Reports per-asset, per-chain volume back to the DefiLlama ingestor.

It does this for Ethereum and Sui — the two chains where Hashlock HTLC contracts are live in production. Bitcoin atomic-swap volume isn't reported here yet: BTC settles via P2TR, not via an EVM/Move event log, so the adapter for it needs a different cursor strategy. That's on the roadmap; it isn't in this listing.

The doublecounted: true story

During code review, the DefiLlama reviewer flagged 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?

Our first instinct was to set doublecounted: true, which would tell DefiLlama's aggregator: treat my reported volume as one side of a paired total, divide by two on the dashboard.

Then we re-read the semantic. That flag exists for protocols where the same trade is observed twice in the same data feed — e.g., a constant-product AMM emitting one Swap event that DefiLlama could naively read as two transfers. In Hashlock's case, each leg of an atomic swap is its own settlement on its own chain, denominated in its own asset. Selling 1 BTC for 17 ETH produces two on-chain settlement events: the BTC leg moves, the ETH leg moves. Both are real volume in the asset where they cleared. Adding them is not double counting; it's the actual cleared notional.

We removed doublecounted: true and pushed commit c389564 to confirm the semantic. The reviewer accepted that read; it became the merged version.

The practical consequence: when you sell 1 BTC for ETH on Hashlock, the listing will eventually show BTC volume on the BTC chain (once BTC reporting goes live) and ETH volume on Ethereum. Not a 2x inflation of the same dollar — a measurement of the two distinct on-chain settlements the atomic swap actually performs.

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 — typically minutes, never days. 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, no Withdraw fires. No volume booked. That's the honest read: refunds aren't trades, and they shouldn't appear in trade volume.
• Chains that aren't live yet. Base, Arbitrum, Solana, and TON are on the deployment roadmap. None are live with HTLC contracts in production. The adapter has no scaffolding to report from them yet because there's nothing to report. When a chain goes live, the adapter will gain a chain key.
• The V2 contracts. Our V1 HTLCs are immutable and currently in audit hardening. The V2 contracts in feat/htlc-v2 will, after audit sign-off, get their own adapter entries; the V1 entries stay in place for as long as V1 is in production.

Why cross-chain matching is the harder half

For Ethereum, reading Withdraw events is straightforward — Etherscan indices, JSON-RPC logs, well-trodden ground.

For Sui, the adapter walks the explorer index for create and withdraw events on the Hashlock Move package. Then — and this is the part that takes more code than you'd expect — it pairs each Sui-side leg to its Ethereum counterpart by matching the HTLC hashlock. The pairing 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 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 7 bps headline, with up to 50% rebate via execution timeliness — so the realized fee is 3.5-7 bps depending on settlement speed. The headline doesn't communicate the rebate; 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 twice, asked the doublecounting question, and accepted our answer. Per-leg Hashlock volume on Ethereum and Sui 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 (V2 audit sign-off, the missing metrics above, adversarial trading volume beyond reference deployments) 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