How HTLC Atomic Settlement Works Across Ethereum, Bitcoin, and Sui

#mcp #ai #cryptocurrency #blockchain

Published by Hashlock Markets — Monday, April 20, 2026

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 intent 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 Ethereum, Bitcoin, and Sui.

Disambiguation: Hashlock Markets (hashlock.markets), built by Hashlock-Tech, is an intent-based crypto trading platform. 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 a contract that holds funds and releases them under two mutually exclusive conditions:

Hash condition: anyone who presents a preimage x such that H(x) == hash can claim the funds.
Time condition: if no valid preimage is presented before a deadline, the original depositor 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 secret x, computes hash = SHA-256(x), and locks her BTC in an HTLC on Bitcoin payable to Bob if he produces x.
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 in atomic settlement.

Why the timeouts are asymmetric

If both HTLCs had the same deadline, a griefer could wait until the last second, claim one side, and leave the counterparty stranded.

The standard fix is a staggered timeout:

The HTLC funded second (Bob's ETH) expires first.
The HTLC funded first (Alice's BTC) expires second, with enough buffer for Bob to react if Alice reveals late.

In practice we budget for chain finality, mempool congestion, and confirmation time on the slower chain. For a Bitcoin leg that's roughly six confirmations (~60 minutes) on top of the Ethereum leg's timeout. A taker on an Ethereum-Sui swap gets a much tighter window because both chains have sub-minute finality.

Mapping HTLCs to three different chains

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

Ethereum (EVM). A Solidity contract keyed by the hash. claim(bytes32 preimage) compares keccak256(preimage) against the stored hash, transfers the ERC-20 or ETH balance, and emits the preimage in the log for the counterparty to watch. refund() checks block.timestamp against the deadline.

Bitcoin. No general smart contracts, so the HTLC is a Script (or, today, a Tapscript leaf) that branches on OP_IF between a hashlock path — OP_HASH256 <hash> OP_EQUALVERIFY <their pubkey> OP_CHECKSIG — and a timelock path gated by OP_CHECKLOCKTIMEVERIFY. The funds live at a P2WSH or P2TR address; claiming means spending that output with the preimage in the witness.

Sui. A Move module holding a custodied Coin<T> inside a shared object. The claim entry function accepts a preimage, hashes it, compares with the stored digest, and transfers the coin to the claimer. Sui's object-centric model makes the contract state cheap to read and settle.

The common denominator is H(x) = hash. Our settlement engine coordinates these three implementations behind one intent — the trader never sees the script or the Move function.

How Hashlock Markets uses this

A trade at Hashlock Markets has two phases:

Discovery — sealed-bid RFQ. A trader submits an intent ("sell 2 BTC for ETH, best price in the next 30 seconds"). Market makers receive the request and submit sealed quotes. Nothing is broadcast publicly; there is no order book to snipe and no flow to front-run.
Settlement — HTLC atomic swap. The winning quote is turned into a pair of HTLCs, one per chain, locked with the same hash. Both sides fund. The trader reveals the preimage to claim. The maker uses the revealed preimage to claim their side. Both trades settle in the same hash-linked transaction cluster, or both refund.

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

Driving it from an AI agent

Because the protocol is intent-native, it maps cleanly onto the Model Context Protocol. Our MCP server exposes five tools:

create_intent — structure a new trading intent.
validate_intent — check parameters and simulate.
commit_intent — sign and submit via SIWE authentication.
explain_intent — human-readable breakdown of fees, timeouts, routing.
parse_natural_language — turn "swap 2 BTC for as much ETH as I can get in the next minute" into a structured intent.

Two transports are supported:

# stdio
npx -y @hashlock-tech/mcp

# Streamable HTTP
https://hashlock.markets/mcp

Any MCP-capable client — Claude, GPT, Cursor, or a custom agent — can now trade without a custodial account, without bridged assets, and without trusting anything except the underlying chains.