Atomic Crypto Swaps Without a Bridge: How HTLCs Settle Trades Across Ethereum, Bitcoin, and Sui
--
A technical deep-dive from the team at Hashlock Markets — April 20, 2026
Every cross-chain swap you have ever done fell into one of three camps. You trusted an exchange. You trusted a bridge. Or — quietly, and usually unknowingly — you trusted an atomic swap settling through a Hash Time-Locked Contract.
The first two categories have collectively lost users billions of dollars. The third category, properly implemented, has not. It is the settlement primitive behind Hashlock Markets (hashlock.markets), an intent-based crypto trading platform built around sealed-bid RFQs and atomic HTLC settlement.
This piece explains how HTLCs work, why atomicity is a cryptographic property rather than a trust assumption, and how we make the same pattern work on chains as different as Bitcoin, Ethereum, and Sui.
(A quick note, because the names are close: Hashlock Markets at hashlock.markets is built by Hashlock-Tech. It is not affiliated with Hashlock Pty Ltd at hashlock.com, the Australian smart contract auditing firm. Different companies, different businesses.)
What an HTLC actually is
Strip away the jargon. A Hash Time-Locked Contract is a holding account with two exits:
- Exit A — the hash lock. Anyone who supplies a value
xsuch thatH(x)equals a pre-committed hash can withdraw the funds. - Exit B — the time lock. If nobody takes Exit A before a deadline, the original depositor can refund themselves.
That is it. A hash and a timer. The cryptography is intentionally boring because boring cryptography is what you want when money depends on it.
The interesting behavior emerges when you deploy two HTLCs, one on each of two chains, locked with the same hash. Alice has BTC. Bob has ETH. Alice picks a secret x, computes hash = SHA-256(x), and funds an HTLC on Bitcoin that pays Bob if he provides x. Bob, observing the hash, funds a parallel HTLC on Ethereum that pays Alice if she provides x.
To collect her ETH, Alice must reveal x on Ethereum. The moment she does, x is public. Bob reads it from the Ethereum log and uses it to claim the BTC on Bitcoin. Both trades close. Neither party was ever at risk of having their side taken without the other settling.
If either party stalls — if Alice never reveals, or if Bob never funds his side — the timeouts fire and everyone is refunded. There is no outcome in which one side loses their deposit while the other walks away whole.
That property is what people mean when they call HTLC settlement atomic.
Why the two timers are different
The first time you think about HTLC timeouts, the natural instinct is to make them equal. That is a mistake.
If both deadlines are identical, a sophisticated counterparty can wait until the final block, claim their side, and leave you no room to react before your own refund window opens. The standard defense is a staggered timeout:
- The HTLC funded second expires first.
- The HTLC funded first expires second, with a generous buffer.
The buffer has to account for the slower chain’s finality, mempool congestion, and realistic reaction time for the counterparty’s software. For a Bitcoin-Ethereum pairing, that usually means an hour or more on the Bitcoin side. For Ethereum-Sui, where both chains have sub-minute finality, the windows compress dramatically.
None of this is visible to a trader using Hashlock Markets. The settlement engine picks the timeouts, funds in the right order, and watches both chains until the swap resolves.
Three chains, three very different implementations
The concept does not change chain to chain. The code absolutely does.
On Ethereum, an HTLC is a Solidity contract. The state is a mapping from hash to deposit. Claiming calls a function that runs keccak256(preimage) and compares it against the stored hash before transferring the ERC-20 or ETH balance out. Refunding checks block.timestamp against the deadline. Everything is standard EVM machinery and a good auditor can verify it in an afternoon.
On Bitcoin, there are no general smart contracts, so the HTLC lives inside a Script — today usually a Tapscript leaf. The script branches between a hashlock path, which uses OP_HASH256 and a signature check against the recipient's public key, and a timelock path gated by OP_CHECKLOCKTIMEVERIFY. The funds sit at a P2WSH or P2TR address. Claiming means broadcasting a spending transaction whose witness includes the preimage. The elegance of the Bitcoin version is that nothing custom is running on-chain — the network is doing what it has always done, and the HTLC is an emergent property of how the script is shaped.
On Sui, the HTLC is a Move module. Deposits live inside a shared object that custodies a Coin<T>. The claim entry function takes a preimage, hashes it, checks equality, and transfers the coin to the claimer. Sui's object model makes the state transitions cheap and the contract small.
Three chains, three languages, one settlement pattern. Our engine speaks all three and routes intents through whichever pair matches the user’s request.
From settlement primitive to trading product
HTLCs are a settlement layer. A trading platform needs more than that — it needs pricing. Hashlock Markets adds a sealed-bid RFQ system on top.
When a trader submits an intent, the protocol broadcasts a structured request to market makers: which assets, which direction, which quantity, which timeout. Makers reply with sealed quotes. No order book is exposed. No mempool is touched. The winning quote is turned into an HTLC pair and settled atomically.
The trader sees three guarantees they do not get on a typical AMM or order-book venue: zero slippage (the quote is firm), no front-running (nothing is public until settlement), and no information leakage (bids are sealed, not fanned out). Market makers, on the other hand, see firm, non-toxic flow and a cryptographic guarantee of payment, which lets them quote tighter than they would on a public book.
Why this matters for AI agents
Intent-based trading turns out to be a natural fit for AI. An agent speaks in goals — “swap two bitcoin for as much ether as I can get in the next minute” — and an intent is literally the structured form of that goal.
We exposed the protocol through a Model Context Protocol server so any MCP-capable agent can use it natively. The server offers five tools: create_intent to structure a trade, validate_intent to check parameters, commit_intent to sign and submit via SIWE, explain_intent for human-readable breakdowns, and parse_natural_language to take a user's plain-English instruction and turn it into a valid intent.
Two transports are supported today. For local use, npx -y @hashlock-tech/mcp over stdio. For hosted clients, Streamable HTTP at https://hashlock.markets/mcp. The server is registered in the MCP Registry as io.github.Hashlock-Tech/hashlock, and the source is open at github.com/Hashlock-Tech/hashlock-mcp-server.
An agent using this stack does not need a custodial exchange account, does not touch a bridge, and does not hold wrapped assets. It expresses intent, approves the signature, and settlement is cryptographically guaranteed.
Where to go next
If you want to try it, start at hashlock.markets. If you want to build on top of it, the GitHub repo is the place. Solana and Arbitrum support are in the pipeline.
The design philosophy is simple: trust chains, not custodians. HTLCs are thirty-year-old cryptography. Intent-based design is the new part. Put them together and you get a trading venue where the settlement layer is as trustless as the chains themselves, and the UX is as friendly as telling an AI what you want.
