HTLCs: How Lightning Moves Money Through Strangers

Imagine Nigeria experiences one of the worst network outages in its history. Mobile networks are down, internet providers have gone silent and every financial institution in the country is effectively disconnected. Bank transfers don't work. Fintech apps don't work. POS terminals don't work. For the first time in a long time, moving money digitally is no longer an option. Now imagine you need to get ₦5 million from Lagos to your cousin in Kano before tomorrow morning. In a world where every payment system has failed, there is really only one way to do it. You find someone travelling to Kano, hand them the money in cash and ask them to deliver it on your behalf. Let's call him Bob. You don't know Bob. You've never met him before and you'll probably never meet him again after tonight. The only reason you're even considering handing him that amount of money is because someone you know tells you that Bob is reliable. It isn't your own experience that's giving you confidence. It's borrowed trust. You hand Bob the cash. Then you wait. The interesting thing about this story isn't whether Bob is honest. He might be. In fact, there's every chance that he intends to deliver the money exactly as promised. But intent has never really been the problem. Bob could get robbed somewhere along the way. His car could break down halfway through the journey, he could fall sick before he ever reaches Kano, or he could simply decide that disappearing with ₦5 million is worth whatever consequences might come afterwards. The outcome isn't determined by what you want anymore. The moment that money leaves your hands, control leaves with it. That has always been the uncomfortable reality of moving value. Long before the internet, before banks became global institutions and before payment networks connected billions of people, humans were already trying to solve the same problem. How do you send something valuable through another person without losing control over it halfway through the journey? Every solution we have built has started from roughly the same assumption, somewhere along the process, someone has to be trusted. Sometimes that someone is a bank safeguarding deposits. Sometimes it's a payment processor settling transactions between strangers. Sometimes it's a legal system promising consequences if an agreement is broken. The institutions change, the mechanisms evolve and the technology improves, but the assumption beneath them remains remarkably consistent. Trust is always sitting somewhere in the middle. Now stretch that same problem beyond Lagos and Kano. Imagine a payment moving across a network made up of millions of people who will never meet each other. They live in different countries, operate under different legal systems and, in many cases, have no practical way of verifying who the other person even is. There are no mutual friends to vouch for anyone and no shared reputation. No court that meaningfully governs every participant. And yet the network still expects money to move from one end to the other without anyone stealing it, withholding it or simply disappearing halfway through. That is the problem the Lightning Network solves. People often describe Lightning as Bitcoin's scaling solution or its fast payment layer. Both descriptions are true, but neither captures what makes the network remarkable. Speed was never the difficult part; plenty of payment systems can move money quickly. The harder problem, and the one Lightning quietly solved, is figuring out how value can move through complete strangers without asking any of those strangers to become trustworthy first. Because that is exactly what happens on Lightning. If Alice wants to send money to Carol but doesn't have a payment channel with her, the payment has to travel through someone else. Let's call him Bob. Bob sits between the sender and the receiver, forwarding payments from one side to the other. At first glance, this looks almost identical to the story we began with. Alice appears to hand money to Bob, trusting him to pass it on to Carol, and Bob appears to have every opportunity to disappear with it. The interesting part is that he can't. Now, this is not because Lightning has somehow found a way to guarantee that everyone participating in the network is honest. It hasn't. The network makes no assumptions about Bob's character, his intentions or even his competence. It assumes he might act selfishly if given the opportunity. Instead of trying to make Bob trustworthy, Lightning does something far more interesting: it constructs the payment in a way that removes the opportunity to cheat in the first place. That idea sits at the heart of one of the most important mechanisms in the Lightning Network: the Hashed Timelock Contract (HTLC). The name has a habit of intimidating people long before they understand what it does, but the idea itself is remarkably simple. Imagine if, instead of just handing Bob the cash, you sealed it in a lockbox that only opens with a specific key, a key that only your partner has. Bob can carry the lockbox, Bob can even peek at it, weigh it, but Bob cannot open it and take the money, because he doesn't have the key. Bob only gets paid for carrying the box if he can later prove it actually reached your cousin and got opened. That, in essence, is what an HTLC does, except instead of a physical lockbox and key, it's a small piece of cryptographic logic sitting inside a Bitcoin transaction, and instead of one driver, it can chain across a dozen strangers, each one only able to move the money forward, never sideways and never into their own pocket. That's really the whole trick Lightning is pulling off: money can cross a chain of people who have no reason to trust each other, and it still lands exactly where it was supposed to. This article is about how that lockbox actually works, the real script, the real transaction structure, the real sequence of messages that pass between nodes when you send a Lightning payment. We'll build up from scratch, piece by piece, until the phrase "hashed timelock contract" stops sounding like jargon. The Secret Go back to Alice and Carol for a moment. Alice wants to send Carol 50,000 sats, but before Alice can even think about making that payment, Carol has already done something that quietly determines how the rest of the story unfolds. She generates a random 32-byte number known as a preimage, usually written as R. At this point, R exists in exactly one place. Carol knows it, nobody else does. Not Alice nor Bob nor any of the nodes that might eventually help move the payment across the network. For now, the secret belongs to Carol alone. The next thing she does is just as important. Instead of sending R to Alice, Carol runs it through a cryptographic hash function called SHA-256, producing another value we'll call H. H = SHA256(R) This is the value that appears in the invoice she sends to Alice, Not R, Just H. That distinction matters because if Carol simply included R in the invoice, the entire system would fall apart before it even began. Anyone who saw the invoice would possess the very thing needed to claim the payment. Bob could see it. Every routing node along the path could see it. The secret would stop being a secret the moment the payment started moving. Hashing avoids that problem. If you've come across cryptographic hash functions before, this will probably feel familiar. If you haven't, there's only one property that matters for what we're about to discuss: Hashing works in one direction. Given R, anyone can calculate H. Starting with H, however, gives you no practical way of working backwards to R. The hash becomes a kind of fingerprint for the secret. It tells everyone, "there is a secret behind this value," without revealing what that secret actually is. That one idea is enough to change the way the payment itself is constructed. Alice doesn't create a payment that says, "Pay Carol 50,000 sats." She creates a payment with a different rule. Whoever can produce a value that hashes to H may claim these funds. Notice what's happened. The payment is no longer relying on someone's identity, neither is it relying on Bob's honesty either, the only thing the payment cares about is knowledge of the secret. If someone can produce the secret that matches H, the payment can be claimed. If they can't, it remains locked. That's what a hashlock really is. In Script it looks roughly like this: OP_HASH160 OP_EQUALVERIFY Think back to the lockbox from the beginning of this article. The box never cared who was carrying it. Bob could drive it halfway across the country, he could leave it in his boot overnight, he could even decide never to deliver it. None of those things gave him access to the money inside because the lock wasn't checking who he was. It was checking whether he had the key. A hashlock behaves in much the same way. Bob can carry the payment, he just can't unlock it. And that's the first time Lightning removes the need to trust him. Bob isn't prevented from cheating because the network believes he's honest, he's prevented from cheating because he doesn't know the one thing the payment demands before it can be claimed. That solves one problem but it also creates another. Imagine Carol never reveals R. Maybe her node goes offline before the payment reaches her, maybe the invoice expires, maybe something breaks somewhere else along the route. Whatever the reason, the secret is never revealed. Now the payment can't be stolen, neither can it be moved. Without another rule, those funds would remain locked indefinitely. The hashlock answers the question of who is allowed to claim the payment, it says nothing about how long they have to do it. That's where the second idea enters the picture. The Deadline Every HTLC has a deadline attached to it. In Lightning, this deadline is known as a timelock, and its job is surprisingly straightforward. It gives the receiver a fixed amount of time to reveal the secret and claim the payment. If the correct secret is revealed before the deadline expires, the payment succeeds. If it isn't, the payment is cancelled and the sender regains control of their funds. On the surface, that might not seem particularly remarkable. Deadlines exist in almost every kind of agreement. We set them when we sign contracts, repay loans or complete projects. A timelock works in much the same way. It doesn't decide who is entitled to the payment. It simply decides how long that opportunity remains available. That one addition changes the outcome completely. Timelock uses OP_CHECKLOCKTIMEVERIFY, or CLTV. It sets a block height, and until that height's reached, a certain way of spending the output just isn't valid yet. OP_CHECKLOCKTIMEVERIFY OP_DROP So the idea is if nobody's shown up with the preimage by the time that block height hits, the sender gets a way to claim the funds back. No hash needed for this path, just their own signature, once the clock's run out. Without a timelock, a payment protected by a hashlock could remain locked forever if the secret was never revealed. Alice's money wouldn't be stolen, but neither would it return to her. Everyone involved would simply remain stuck, waiting for an event that might never happen. The timelock removes that possibility. Once the agreed time has passed, the payment expires and the funds become spendable by the sender again. There is no room for endless waiting because the contract already specifies what should happen if the receiver never claims the payment. The hashlock and the timelock are solving two different problems. The hashlock answers the question of who can unlock the payment by requiring knowledge of the secret, the timelock answers the question of when that opportunity ends by placing a limit on how long the payment can remain locked. Neither is particularly useful without the other. A hashlock on its own protects the payment from being claimed by the wrong person, but it cannot prevent the funds from remaining locked indefinitely. A timelock on its own ensures the payment eventually comes to an end, but it has no way of determining who should be allowed to claim those funds before the deadline arrives. An HTLC simply combines both ideas into a single agreement. Instead of relying on trust, the payment now follows two conditions that every participant understands. Reveal the correct secret before the deadline and the payment succeeds. Fail to do so before time runs out, and the payment returns to the sender. An HTLC output really has two ways it can be spent, and Script picks between them with an OP_IF. One path is the success path, claim the funds by showing the preimage. The other is the timeout path, here the intended sender claims it after the deadline passes. Roughly, it looks like: OP_IF # Success path: recipient claims with preimage OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG OP_ELSE # Timeout path: sender reclaims after expiry OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG OP_ENDIF At this point, we have all the pieces, a secret that only one person knows, a deadline that everyone agrees on. The only thing left is to see how Lightning actually uses those two ideas inside a payment channel. Because an HTLC isn't a separate object floating around the network. It's built directly into the commitment transactions that every Lightning channel depends on. Where does the HTLC actually live? We now know what an HTLC is trying to achieve. It combines a hashlock and a timelock so that a payment can only be claimed by revealing the correct secret before an agreed deadline. If either condition isn't met, the payment fails and the sender keeps control of their funds. The next question is where those rules actually exist. It is easy to imagine an HTLC as something travelling across the network alongside the payment itself, almost like a digital package moving from one node to another. But that isn't what happens. HTLCs don't exist independently of payment channels. They exist inside them. To understand why, it helps to remember what a Lightning channel actually is. When two people open a payment channel, they lock bitcoin into a shared funding transaction on the Bitcoin blockchain. That funding transaction doesn't change every time they send money to each other. Instead, both participants continuously create updated transactions that describe how those funds should be divided if the channel were closed at that exact moment. These updates are known as commitment transactions. You can think of a commitment transaction as the latest version of the agreement between two channel partners. It records who owns what balance inside the channel and can be broadcast to the Bitcoin network if either party decides to close the channel. Every time a payment is made, the old commitment transaction is replaced with a newer one that reflects the updated balances. The Script behind it Previously, we discussed a stripped-down version of the script, just the hashlock and the timelock, but there is a third piece of the script: revocation path. Every time Alice and Bob update the channel balance, they're not touching the old transaction, they're signing an entirely new commitment transaction and agreeing to throw away the old one. "Throwing away" doesn't mean deleting a file, the old transaction still technically exists, still technically valid, still capable of being broadcasted. What it actually means is exchanging a revocation key, and that key is what lets a person punish the other person if they try to cheat by broadcasting the old state on chain. So say Bob, for whatever reason, broadcasts an old commitment transaction, one from before this HTLC even existed, maybe one where he had a bigger balance. If that gets published to the chain, Alice needs a way to catch it and to also penalize him by taking everything, not just get her money back, but also his, otherwise there's nothing stopping him from just trying old states over and over hoping one sticks. That's what the revocation path is for. Here's what an offered HTLC script actually looks like, this is the version on Bob's side of the channel when Bob is the one sending the HTLC to Carol: OP_DUP OP_HASH160 OP_EQUAL OP_IF OP_CHECKSIG OP_ELSE OP_SWAP OP_SIZE 32 OP_EQUAL OP_NOTIF OP_DROP 2 OP_SWAP 2 OP_CHECKMULTISIG OP_ELSE OP_HASH160 OP_EQUALVERIFY OP_CHECKSIG OP_ENDIF OP_ENDIF And here's a received HTLC, Bob's side when Bob is the one receiving the HTLC, this is the mirror case: OP_DUP OP_HASH160 OP_EQUAL OP_IF OP_CHECKSIG OP_ELSE OP_SWAP OP_SIZE 32 OP_EQUAL OP_IF OP_HASH160 OP_EQUALVERIFY 2 OP_SWAP 2 OP_CHECKMULTISIG OP_ELSE OP_DROP OP_CHECKLOCKTIMEVERIFY OP_DROP OP_CHECKSIG OP_ENDIF OP_ENDIF The difference between the two versions is that on the offered side, the one that hands out the preimage path takes priority if the size check passes, that's Carol claiming her payment. On the received side, it's flipped, because now Bob is the one who'd be claiming with a preimage, and the timeout path is what falls back to the sender. Same two ingredients, hash and clock, just mirrored depending on which direction the money's supposed to flow. All of this Script only actually matters if someone tries to cheat or the payment times out. Ideally, Alice and Bob just keep updating their commitment transactions off-chain, the HTLC output shows up, gets resolved, gets removed once Carol reveals the preimage and it propagates back, and the channel moves on. the script is there as a backstop and that's really the whole point, this is what makes it safe for Bob to hold an HTLC output at all. He's not trusting Alice, he's not trusting Carol, he's trusting that if anything goes wrong, this exact script is what gets enforced. When Alice wants to send a payment that depends on a secret and a deadline, those conditions are written directly into the commitment transactions of the channel. Instead; of simply saying, "Alice owns this amount and Bob owns that amount" the commitment transaction now includes an additional output representing the HTLC. That output can only be spent if the correct secret is revealed before the timelock expires. If the deadline passes first, the output can be resolved in a different way, allowing the funds to return according to the rules already agreed by both participants. This is an important distinction because it means the security of an HTLC doesn't come from a promise between Alice and Bob. It comes from Bitcoin itself. If either participant decides to close the channel, those conditions are enforced by the Bitcoin network exactly as they were written into the commitment transaction. Neither Alice nor Bob can decide to ignore them once the channel has been updated. We've seen how a single HTLC works between two nodes sharing one payment channel. The Lightning Network, however, isn't made up of isolated channels. Payments usually pass through several of them before reaching their final destination. That raises another question. If Alice and Carol don't share a channel, and Bob is only forwarding the payment between them, how does the same HTLC travel across multiple channels without Bob ever gaining control of the funds? Across Multiple Channels The HTLC never leaves one payment channel and travels across the network until it reaches its destination. That is perhaps one of the easiest things to misunderstand about Lightning. Although we often speak about "the HTLC" as though there is only one, every payment that crosses multiple channels is actually made up of several HTLCs. Each one exists inside a single payment channel, each one is a separate agreement between two payment channels and each one is built around the very same hash Carol generated before the payment ever began. Imagine Alice wants to send Carol 50,000 sats, but they don't share a payment channel. The only route available is through Bob. Alice has a channel with Bob, Bob has one with Carol. Alice and Carol have never opened one together, which means Alice can't simply create an HTLC with Carol because there is no channel between them for that contract to exist inside. Instead, she creates an HTLC inside her own channel with Bob using the hash Carol originally included in her invoice. Bob then creates another HTLC inside his own channel with Carol using exactly the same hash. They are different contracts, living in different payment channels, but both are waiting for the same secret to be revealed. At this point, nothing has actually been claimed. Carol still knows R, the secret she generated at the very beginning of the payment. Bob doesn't know it, Alice doesn't know it either. All anyone else has is H, the hash derived from that secret. As far as Bob is concerned, the HTLC in his channel with Alice and the HTLC in his channel with Carol are both locked behind a piece of information he doesn't possess. He can create the contracts, he can forward the payment and he can wait, but he cannot satisfy either HTLC because he has no way of producing the one value both contracts are asking for. Eventually, Carol decides to claim the payment. To do that, she has no choice but to reveal R. The moment she does, something interesting happens. Bob learns the secret for the very first time. He verifies that hashing R produces the same value both HTLCs have been waiting for and immediately uses that very same secret to satisfy the HTLC between himself and Alice. The payment reaches Carol by moving forwards through the route, but the secret that makes the entire payment possible begins moving in the opposite direction. It starts with Carol, reaches Bob and finally arrives with Alice, allowing each HTLC to be settled one after another until every participant has exactly the outcome the contracts promised. That is why Bob never reaches a point where he can simply disappear with Alice's money. The only way he ever learns the secret needed to claim funds from Alice is by first forwarding the payment to Carol and giving her the opportunity to reveal it. Until that happens, he is in exactly the same position as everyone else on the route. He is waiting for a secret he cannot guess, cannot calculate from the hash and cannot obtain unless the payment succeeds for the person after him. Multi-Hop Routing with HTLCs Before any of the Script, before any commitment transaction changed shape, Carol generated R and handed Alice the hash of it, H, wrapped up in an invoice. That happened first. Everything from here on is just different people trying to get their hands on R. So here's the full sequence, start to finish. Alice adds an HTLC to her commitment transaction with Bob. The terms: pay Bob 50,000 sats (plus his routing fee, but let's ignore this for now) if he can produce a value that hashes to H, and he's got until block T1 to do it. Bob doesn't have R, nobody does except Carol does, So Bob can't claim anything yet, what he does instead is turn around and add his own HTLC, this time on his channel with Carol. Same H. Same deal, pay the bearer of R, except Bob sets his own deadline, T2, and here's the detail that actually matters: T2 comes before T1. Not the same block, not later. Earlier. Alice --[HTLC: H, expiry T1]--> Bob --[HTLC: H, expiry T2]--> Carol where T2 < T1 Now Carol's the one holding an HTLC she can actually do something with. She knows R, she made it. So she reveals it and claims the funds from Bob. The second Carol does that, R is out in the open. Bob sees it the moment Carol claims her HTLC, because claiming it means revealing off-chain the preimage as part of the spend, Bob grabs that same R and turns straight back around to claim his HTLC with Alice, using the exact value Carol just revealed. That's the whole loop. One secret, revealed once by the person it was made for, and it ripples backward through every hop that was waiting on it. Why T2 Has to Come Before T1 Say the deadlines were flipped, or even just equal. T1 and T2 land on the same block, or T1 comes first. Now think about what happens if Carol drags her feet, maybe she's not watching closely, maybe there's some network delay, and she claims her HTLC with Bob right up near the deadline, right before T2. Bob's now holding R. Great. Except if T1 already passed, or is about to pass in the next block or two, Bob doesn't have time to turn around and claim from Alice before her timeout kicks in. Alice's side of the HTLC just reverts, refunds itself back to her. Now Bob loses 50,000 sats since he already paid Carol, with no way to recover it from Alice. That gap between T1 and T2 is Bob's safety margin, it's the buffer that guarantees: by the time Carol could possibly reveal R, at the very last legal moment, Bob still has enough blocks left over to get his own claim against Alice confirmed before her timeout closes the door. These T1 and T2 are real number every routing node sets, called cltv_expiry_delta. Every hop along a route adds its own delta on top of the next hop's expiry. So the deadline actually gets longer, not shorter, as you move backward from Carol toward Alice, because each intermediate hop needs its own breathing room. Why Bob still can’t cheat At this point, it might seem as though Bob finally has an opportunity to take advantage of the payment. Carol has revealed the secret, Bob now knows R and he can use it to claim the HTLC between himself and Alice. What stops him from simply holding on to that secret? What if he waits until the last possible moment before settling with Alice, or decides not to complete the payment at all? The answer goes back to the second idea we introduced earlier in the article. Every HTLC has a timelock attached to it, but those timelocks are not all the same. They are deliberately arranged so that each participant has slightly less time to claim a payment than the person before them. That difference might only be a matter of a few blocks, but it is enough to make the entire route work. Imagine the payment moving from Alice to Bob and then from Bob to Carol. The HTLC between Alice and Bob might expire in 30 blocks, while the HTLC between Bob and Carol expires in 20. Carol therefore has to claim her payment before Bob's opportunity to recover his own funds from Alice comes anywhere close to expiring. By the time Carol reveals the secret, Bob still has enough time to use that same secret to settle the HTLC in his own channel. This ordering is what protects every forwarding node on the route. Bob is never expected to pay Carol first and hope Alice eventually reimburses him. Before he agrees to forward the payment, the network has already ensured that the deadlines leave him enough time to recover whatever he forwards. If Carol never reveals the secret, the HTLC with Bob simply expires and he never has to complete the payment. If she does reveal it, he learns the secret while there is still time to settle with Alice. Either way, he isn't left in a position where someone else's actions can trap his funds indefinitely. That doesn't mean Bob is forced to forward payments. Like every other participant on the Lightning Network, he can choose which payments he wants to route and which ones he doesn't. What he cannot do is create an outcome where he keeps Alice's money without paying Carol, or where Carol receives the payment while Alice permanently loses access to her funds. The combination of the hashlock and the staggered timelocks removes those possibilities before the payment even begins. Force-Close Mid-HTLC Here's where revocation mechanism actually gets used. Say Bob's misbehaving in a different way. He's already claimed from Carol, has R in hand, but instead of just claiming normally from Alice off-chain, he tries to broadcast an old commitment transaction with Alice, one from before this HTLC even existed, hoping to walk away with a more favorable balance than his current, honest state allows. This is exactly the scenario the revocation key was built for. Alice's node is watching the chain, the second an old commitment transaction gets broadcasted, she has a window (defined by to_self_delay, a separate timelock that gives the broadcaster's balance a cooldown period) to produce the revocation key for that exact old state and sweep the entire transaction, not just her share, all of it, including what would've been Bob's. This is the part that makes the "Bob can't cheat" claims also true instead of just asserted. It's not that Bob wouldn't want to try something like this. It's that trying it costs him strictly more than just behaving honestly ever would. That asymmetry, cheating is possible in theory but punished severely and immediately in practice, is what "trustless" is actually doing under the hood. Nobody's relying on Bob being a good person, they're relying on the cost of being a bad one. Onion Routing + HTLCs Together Up until this point, we've assumed Alice somehow knows to send her payment through Bob. In reality, the Lightning Network may offer dozens, or even hundreds, of possible routes between Alice and Carol. Once Alice's node finds a suitable route, another problem immediately appears. Bob needs enough information to know where the payment should go next, but he doesn't need to know the entire journey. Giving every forwarding node a complete map of the payment would expose information they have no reason to see. Every participant would know who started the payment, who would eventually receive it and every stop in between. That would reveal far more about the payment than is necessary for it to succeed. That's a real privacy problem, HTLCs were never built to solve this, onion routing was. It's is a different concept from HTLC, a payment instructions wrapped in layers of encryption before the payment ever leaves Alice's node. Lightning wraps the routing instructions in layers, one per hop (or forwarding node), using what's called a Sphinx packet. Alice puts the whole thing together before the payment even leaves her node. Each layer's encrypted so a hop can only peel off the one meant for it, see just enough to know where the payment goes next, and nothing beyond that. Bob knows who sent the payment to him and where he should send it next, but he doesn't know how many nodes came before him, how many still lie ahead or, in most cases, who the final recipient is. Bob can't see what's sitting inside Carol's layer, if there were more hops past Carol, he wouldn't see those either. By the time the payment reaches Carol, every layer has been removed without any single forwarding node knowing the complete route. Nobody except Alice, the person who built the onion in the first place, ever sees the full shape of the route. Alice builds the onion backward, starting from the last hop first. Route's Alice → Bob → Carol, so she wraps Carol's instructions first, that becomes the innermost layer, then wraps the whole thing again in Bob's instructions on top. What Bob actually gets handed is just that outer shell. Onion Alice sends to Bob: [ Bob's layer: "next hop = Carol, amount, hop-specific data" ] [ Carol's layer: "you're the final hop, here's the payment data" ] Bob decrypts it using a key he and Alice derived together, and that decryption only ever opens up his own layer. Peeling it back tells him exactly one thing: here's the packet, send it on to Carol. He can't read Carol's part. He doesn't have the key for that layer, so he just passes it along untouched. Carol gets that inner layer, decrypts it with her own key, and it tells her, this is the end, the payment's yours. No next hop listed, because there isn't one left. When combined with HTLCs, onion routing completes the picture. HTLCs ensure that every participant can safely forward a payment without trusting the next person in the route, while onion routing ensures that every participant sees only the information required to do so. Together, they allow a payment to move across a network of strangers without asking anyone in the middle to become trusted or even fully informed. Where this model can get messy Stuck HTLCs and Force-Closes Say a node in the middle of a route goes unresponsive, not permanently, just long enough to be a problem. The HTLC sitting on either side of it is now in limbo. It can't be claimed, because the node holding the preimage (or waiting to relay it) isn't answering. It can't be cancelled early either, because the protocol doesn't let you back out of an HTLC just because the other side's slow, only the timeout does that, and the timeout might be blocks away still. If the unresponsive node stays down long enough, past the point where waiting off-chain still makes sense, the channel just force-closes. That means the commitment transaction gets broadcast on-chain, HTLC outputs and all, and now those get resolved on the blockchain instead of off it. Tuning cltv_expiry_delta We introduced earlier as the safety margin between hops, T2 needs to sit safely before T1. What that section didn't get into is that this isn't a fixed protocol constant, it's a value every routing node operator sets themselves, per channel even, and getting it wrong has real consequences in both directions. Set it too tight, not enough blocks of buffer between one hop's expiry and the next, and you're recreating exactly the squeeze scenario. A node ends up having paid out on one side of a hop without enough runway left to safely claim on the other side before its own deadline closes. In the worst case that means eating a loss that was entirely avoidable, just because the margin was cut too close. Set it too loose, and the cost shows up differently, it's not a loss, it's inefficiency. Every unit of delta is blocks where liquidity on that channel is potentially tied up in a pending HTLC rather than free to route the next payment. Stack too much margin on every hop across a long route, and payments end up with unnecessarily long worst-case resolution windows, funds sitting locked longer than they actually need to be. There's no single correct number here, it's a genuine tradeoff between safety margin and capital efficiency, and it's one every routing node has to make a judgment call on rather than just accepting a default. When One Payment Becomes Several HTLCs Everything described so far has assumed a payment is one HTLC, one hash, one preimage, moving cleanly hop by hop. That's not always true. With multi-path payments (AMP or MPP), a single payment from Alice to Carol can get split across several different routes simultaneously, each one carrying its own HTLC, each one needing to resolve for the payment as a whole to succeed. This complicates the clean model in a real way. It's no longer "reveal one preimage, done", now there's a coordination problem, multiple HTLCs across multiple paths that all need to land before Carol considers the payment complete, and mechanisms to make sure a partial failure across one path doesn't leave Carol holding some but not all of what was promised, or leave Alice's sats scattered mid-flight if one path fails and the others don't. It's a real extension of everything we’ve covered and would most likely have its own article for it. Conclusion At the beginning of this article, we imagined handing ₦5 million to Bob and asking him to deliver it to Carol in Kano. It was an uncomfortable thought because, the moment the money left Alice's hands, so did her control over it. Everything depended on Bob. If he disappeared, changed his mind or simply refused to complete the journey, there was very little Alice could do about it. That is the problem every payment system eventually has to solve. Once value begins moving through other people, trust becomes unavoidable. Traditional financial systems solve that problem by placing trusted institutions in the middle. Banks, payment processors and clearing houses exist because someone has to guarantee that the payment reaches its destination. The Lightning Network takes a different approach. Instead of trying to make intermediaries more trustworthy, it changes the rules under which they operate. Every Lightning payment depends on strangers agreeing to relay money they don't own. The difference is that the protocol no longer asks those strangers to be trusted, it constructs the payment in a way that makes cooperation the only outcome that benefits everyone involved. That is what an HTLC really achieves. A hashlock ensures that the payment can only be completed with a secret chosen by the recipient. A timelock ensures that nobody's funds remain locked forever if that secret is never revealed. Commitment transactions guarantee that every participant can enforce those rules even if another party disappears. Onion routing ensures that each forwarding node learns only what it needs to complete its own part of the journey. None of these ideas solves the problem on its own, but together they make it possible for value to move safely across a network of people who neither know nor trust one another. That is perhaps the most remarkable thing about the Lightning Network. Its greatest innovation is not that it moves bitcoin quickly or cheaply, but that it rethinks the role of trust itself. Rather than assuming people will always act honestly, it assumes they may not and designs the payment so that honesty is no longer a prerequisite for cooperation. The next time you hear someone describe the Lightning Network as simply "Bitcoin, but faster," remember Bob's journey from Lagos to Kano. The real breakthrough was never about speed alone, it looks into discovering that money could travel through strangers without ever asking those strangers to become trusted custodians of someone else's wealth.