Baris Sozen

Posted on Apr 20 Edited on Nov 1

How HTLC Atomic Settlement Works Across Bitcoin, Ethereum, TRON, and Solana

#mcp #ai #cryptocurrency #blockchain

Published by Hashlock Markets, Monday, April 20, 2026

Update, October 2026. This post was first published in April 2026. It has been revised to match the product as it is live today: six mainnet chains (Bitcoin, Ethereum, TRON, Solana, Base, Robinhood Chain), API key authentication, and the current MCP tool set. Current reference: https://docs.hashlock.markets

When you swap one cryptocurrency for another, you have three real options today:

Trust a centralized exchange to hold both sides.
Trust a bridge to lock one asset and mint a wrapped version on the other chain.
Use a Hash Time-Locked Contract (HTLC) and trust nothing but math and the chains themselves.

At Hashlock Markets (hashlock.markets), every swap settles through option three. This post walks through the mechanics: what an HTLC is, why it's atomic, how the timeouts are chosen, and how we stretch the pattern across Bitcoin, the EVM chains, TRON, and Solana.

Disambiguation: Hashlock Markets (hashlock.markets), built by Hashlock-Tech, is a non-custodial P2P cross-chain swap protocol. It is not affiliated with Hashlock Pty Ltd (hashlock.com), the Australian smart contract auditing firm. Similar names, entirely different companies.

The core primitive

An HTLC is an escrow that holds funds and releases them under two mutually exclusive conditions:

Hash condition: anyone who presents a preimage x such that sha256(x) == hashlock releases the funds to the fixed recipient.
Time condition: if no valid preimage is presented before the timelock, the funder can refund.

The magic happens when you deploy two HTLCs on two different chains, locked with the same hash:

Alice wants to swap BTC for ETH. She has BTC on Bitcoin; Bob has ETH on Ethereum.
Alice generates a 32-byte secret x, computes hashlock = sha256(x), and locks her BTC in an HTLC on Bitcoin payable to Bob if he produces x. Only the hash leaves her machine.
Bob sees the hash on Bitcoin and locks his ETH in an HTLC on Ethereum payable to Alice if she produces x.
Alice claims the ETH by revealing x on Ethereum.
Bob reads x from the Ethereum claim and uses it to claim the BTC on Bitcoin.

Either both claims succeed, or both refunds fire. There is no halfway state where one side wins. That is what "atomic" means.

Why the timeouts are asymmetric

If both HTLCs had the same deadline, the party holding the secret could wait until the last second, claim one side, and refund their own leg: a free option on the trade.

The fix is a staggered timelock:

The initiator (who generates the secret) funds first, on the long leg.
The counterparty funds the short leg, which expires first, so after the initiator reveals the secret there is still time to use it on the long leg.

Each chain has a safe timelock set from its finality and reorg risk: 24 hours for a Bitcoin leg, 4 hours for Ethereum, Base, Robinhood Chain, TRON and Solana. The chain with the longer safe timelock takes the long leg, with a gap of at least 2 hours: BTC to Base is 24 h against 4 h; Base to Solana (a tie) is 6 h against 4 h.

Mapping HTLCs to four different rails

The conceptual pattern is identical across chains. The implementation is not.

Bitcoin. No general smart contracts, so the HTLC is a Script behind a P2WSH address with two branches: a claim path checking the receiver's signature plus a preimage whose OP_SHA256 matches the hashlock, and a refund path for the sender's signature after the timelock (OP_CHECKLOCKTIMEVERIFY). Claiming means spending that output with the preimage in the witness, so it needs the receiver's own signature.

Ethereum, Base, Robinhood Chain (EVM). An HTLCFactory deploys one minimal-proxy clone per swap and funds it in the same transaction. The swap parameters are immutable args in the clone's bytecode (no initialize() to front-run) and the address is deterministic (CREATE2), so a counterparty can check the exact escrow before funding. claim(secret) is callable by anyone and always pays the fixed recipient; refund() pays the initiator after the timelock.

TRON. No cheap clone pattern in practice, so a shared SharedHTLC pool holds many swaps in a mapping, TRC-20 tokens and native TRX alike, keyed by the swap id the pool emits at funding.

Solana. A Hashlock HTLC program holds each escrow in a PDA derived from the agreed terms; an escrow funded on other terms is a different address.

The common denominator is sha256(x) = hashlock with a 32-byte secret: Bitcoin Script has OP_SHA256 but no keccak, so one secret opens every escrow alike. Our settlement builders coordinate these implementations behind one swap; the trader never writes the script, the clone call or the program instruction by hand.

How Hashlock Markets uses this

A trade at Hashlock Markets has two phases:

Discovery: sealed RFQ. A taker posts a request for quote ("sell 2 BTC for ETH, open for 15 minutes"). Makers answer with a price in a private thread; nothing is published on a public book, so there is no order book to snipe and no flow to front-run. Both sides accept; the initiator's accept carries sha256(secret).
Settlement: HTLC atomic swap. The agreed terms become two legs, one per chain, locked with the same hashlock. The initiator funds the long leg, the counterparty the short leg. The initiator claims the leg they receive on, revealing the secret; the counterparty (or Hashlock's keeper on their behalf, on every chain except Bitcoin) claims the other leg with it. Both legs settle, or both refund after their timelocks.

The trader gets no slippage (the accepted price is binding), no front-running (no public exposure until settlement), and no information leakage (quotes are sealed). The maker gets firm, non-toxic flow and a cryptographic guarantee of payment.

Driving it from an AI agent

The protocol is a structured request-and-settle loop, so it maps cleanly onto the Model Context Protocol. Our hosted MCP server exposes 24 tools, among them:

list_assets, list_open_rfqs, get_rfq: discovery.
create_rfq, quote_rfq, propose_price, accept_terms: post, quote, negotiate, agree.
set_swap_address, build_fund, build_claim, build_refund, broadcast_tx, swap_status: the settlement steps above, as unsigned transactions you sign yourself.

Two ways to connect. Hosted, by URL, with OAuth and a wallet signature (or Authorization: Bearer hk_live_..., a 90-day API key):

https://hashlock.markets/mcp

Local, over stdio, with your own chain keys in the environment, signing and settling autonomously:

npx -y @hashlock-tech/mcp

Any MCP-capable client (Claude, ChatGPT, Cursor, or a custom agent) can now trade without a custodial account, without bridged assets, and without trusting anything but the chains.

DEV Community