You Want to Swap. Neither Chain Knows the Other Exists.

You have bitcoin. Your counterparty has ether. You've found each other on a forum, agreed on a rate, and now you're staring at the oldest problem in trade: someone has to go first. If you send your bitcoin and wait for the ether, your counterparty might just pocket it and vanish. If they send first, the risk flips. There's no shared intermediary you both trust, and a centralized exchange, the obvious workaround, means handing custody to a third party that can be hacked, frozen, or regulated into irrelevance.

This is the exact problem hashed timelock contracts solve. Not abstractly. Mechanically.

What an HTLC Actually Is

A hashed timelock contract is a special locking script that puts two conditions on a payment. To claim the funds, the recipient must reveal a secret (the preimage of a cryptographic hash) before a deadline. Miss the deadline, and the sender gets their money back automatically. No arbitration. No appeals.

The "hashed" part is the secret mechanism. Alice generates a random string, call it `s`, and computes its hash: `H(s)`. She publishes `H(s)` publicly but keeps `s` private. Anyone can verify that a given secret matches the hash without knowing the secret in advance. That's standard cryptographic commitment: locked in, but not yet revealed.

The "timelock" part is the safety net. Bitcoin has had `OP_CHECKLOCKTIMEVERIFY` since the BIP 65 soft fork. Ethereum has block-number-based expiry baked into smart contract logic. Both chains can, independently, enforce a deadline. The trick is using the same hash on both chains simultaneously, with carefully staggered deadlines.

The Four-Step Swap, Walked Through

Here's how Alice and Bob actually execute a cross-chain atomic swap.

Step 1. Alice generates her secret `s` and computes `H(s)`. She creates an HTLC on the Bitcoin network locking 0.1 BTC. The contract says: whoever can produce the preimage of `H(s)` gets the bitcoin, but only within 48 hours. Otherwise Alice gets it back.

Step 2. Bob sees `H(s)` on-chain (the hash is public; the secret isn't). He creates a mirrored HTLC on Ethereum locking the agreed amount of ETH. Same hash `H(s)`. His timelock is shorter, though: 24 hours. The asymmetry is deliberate and important.

Step 3. Alice, who knows `s`, claims Bob's ETH by submitting the preimage to his Ethereum contract. The moment she does, `s` becomes public on the Ethereum blockchain.

Step 4. Bob now sees `s` on-chain. He uses it to claim Alice's 0.1 BTC from her Bitcoin contract before the 48-hour window closes.

The swap is atomic in the technical sense: either both transfers happen, or neither does. If Alice never claims the ETH, she reveals nothing, both timelocks expire, and funds return to their owners. If Alice claims the ETH but Bob somehow fails to claim the BTC in time, that's Bob's operational failure, not a protocol flaw.

If you're wondering why Bob's timelock is shorter, you're asking the right question.

Why the Staggered Clocks Are Non-Negotiable

The timing asymmetry is the part most guides skip. It's also where the whole thing either holds together or collapses.

If both timelocks expired at the same moment, Alice could game the protocol. She'd wait until the last second, claim the ETH (revealing `s`), and if the Bitcoin network happened to be congested, Bob might not get his transaction confirmed before his own deadline expired. He'd lose his ETH and receive nothing. That's not atomic. That's theft with extra steps.

By giving Bob a longer window on the Bitcoin side (48 hours) and a shorter one on the Ethereum side (24 hours), the protocol ensures that once `s` is revealed on Ethereum, Bob has a full 24-hour buffer to claim on Bitcoin. The gap between the two deadlines is the safety margin. Shrink it too much and you reintroduce timing attacks. In practice, implementations typically use a 2:1 ratio or larger.

Think of the staggered clocks as a revolving door timed so the second panel can't slam on you before you're through. The cryptographic hash is elegant, sure, but the careful clock arithmetic is what makes the swap safe to actually use. That distinction gets lost constantly in popular writing about HTLCs, and it shouldn't.

What People Get Wrong About Atomic Swaps

The popular framing is that atomic swaps are a trustless alternative to centralized exchanges, full stop. True in a narrow technical sense. Misleading in practice.

First, both chains need compatible hash functions and scripting capabilities. Bitcoin uses SHA-256; Ethereum smart contracts can implement any hash function, so that part works. A swap with a chain that lacks timelocks or programmable scripts is simply impossible without modifications. Not every chain qualifies.

Second, atomicity doesn't mean privacy. The same hash `H(s)` appears on both blockchains, both publicly. A chain-analysis firm watching both networks can trivially link Alice's Bitcoin transaction to Bob's Ethereum transaction. The swap is trustless. It is not anonymous.

Third, and this one deserves to die as a folk belief: atomic swaps don't eliminate counterparty risk entirely, only theft risk. Bob can still grief Alice by creating his Ethereum HTLC and then simply never claiming, forcing her to wait out the full 48-hour refund window with her bitcoin locked. Her funds are safe, but they're illiquid for two days. In high-volatility markets, that's its own kind of cost.

Actual production deployments ran into all three of these constraints. Decred's team did early cross-chain swap work, and later Lightning Network tooling picked up the mechanism. The protocol held up. The user experience historically has not.

The Honest State of the Thing

HTLCs are not a complete solution to cross-chain interoperability. They're a precise, elegant answer to one specific problem: how do two parties on different blockchains swap assets without trusting each other or a middleman? For that narrow question, they work exactly as described.

What they don't solve is liquidity, latency, or the coordination problem of finding a willing counterparty at a fair rate. The catch: those gaps are exactly why bridges and wrapped-asset protocols proliferated despite their own, sometimes catastrophic, security tradeoffs.

Still, understanding HTLCs matters for a reason beyond the mechanism itself. They're a clean example of what crypto infrastructure looks like when it's built correctly: a protocol where the rules are enforced by math and time, not by any institution's promise. The hash either matches or it doesn't. The clock either ran out or it didn't.

That's a genuinely rare property in this industry, which is precisely why it gets claimed so often by things that don't actually have it.