Key takeaways
- The Lightning Network is a payment layer on top of Bitcoin. Payments are balance updates between two channel partners, and only the opening and closing of a channel are recorded on the blockchain.
- The design comes from a paper by Joseph Poon and Thaddeus Dryja. The draft published at lightning.network is dated 14 January 2016.
- A payment can cross several channels. Every step depends on the same secret, so a routing node cannot keep the money without passing it on.
- To be paid you show an invoice. Under the BOLT 11 format it expires after 3,600 seconds (one hour) unless the recipient sets another time.
- Each routing node sets its fee as a base fee plus a share of the amount. Opening and closing a channel costs a normal Bitcoin network fee.
- Lightning fits small, frequent payments. The main chain fits large or occasional transfers and long-term storage.
The Lightning Network in one minute
The Lightning Network is a way to make Bitcoin payments without recording each one on the Bitcoin blockchain. Two parties lock some bitcoin into a payment channel, then pay each other by signing new versions of the balance between them.
The design was set out by Joseph Poon and Thaddeus Dryja in their paper on scalable off-chain instant payments. The draft published at lightning.network is version 0.5.9.2, dated 14 January 2016. Today the rules that wallets and nodes follow are written down in a set of open documents called BOLTs, short for Basis of Lightning Technology.
The one idea to remember: a Lightning payment is a balance update between channel partners. The Bitcoin blockchain is involved only when a channel is opened or closed, or when the two sides disagree and need it to settle the matter. This guide is one of all CoinCorner Bitcoin guides.
Five terms used in this guide
- Sats. Satoshis, the smallest unit of bitcoin. One bitcoin is 100,000,000 sats.
- On-chain. Recorded in a block on the Bitcoin blockchain. Off-chain means agreed between the parties and not broadcast.
- Payment channel. Bitcoin locked by two parties so that they can divide it again and again without a blockchain transaction each time.
- HTLC. A hashed time-locked contract: a payment that completes only if the recipient reveals a secret before a deadline.
- Invoice. A request for one Lightning payment, created by the recipient.
Linked terms open their short definition. For the rest, see the Lightning terms in the glossary.
Why Bitcoin needed a second layer
Bitcoin records every payment on one shared ledger that every node checks, and that limits how many small payments it can carry.
A payment on the main chain, an on-chain payment, counts as settled only once it is included in a block. The Bitcoin white paper's own arithmetic supposes one block every 10 minutes. Each block has limited room, so transactions compete for space by offering a network fee. When demand is high the fee rises, and for a very small payment it can be more than the payment is worth.
Poon and Dryja's argument was about scale. If every node must know about every transaction in the world, everyday payment volumes would need blocks so large that only a few operators could process them. Their paper put Bitcoin's capacity at fewer than 7 transactions a second under the 1 megabyte block limit of the time, against a quoted peak of 47,000 a second for Visa. Their answer was to keep most payments off the blockchain and use it as the place where disputes are settled.
How a payment channel works
A payment channel is a pot of bitcoin that two parties control together and can divide again as often as they like without touching the blockchain.
The example below is an illustration: the numbers are made up, kept round and ignore fees. Alice opens a channel with Bob, who runs a café, and pays him three times.
Opening a channel
Opening a channel takes one ordinary Bitcoin transaction, called the funding transaction. In the example it pays 100,000 sats into an output that can be spent only with both Alice's and Bob's signatures.
Before she broadcasts it, Alice receives a signed transaction that returns the whole amount to her. This is the first commitment transaction, and it means her money cannot be stranded if Bob disappears. Normally the funding transaction has to be confirmed on the blockchain before the channel is used, so opening a channel is not instant and it costs a network fee.
Paying inside the channel
To pay Bob 30,000 sats, the two of them sign a new commitment transaction that divides the same 100,000 sats differently: 70,000 to Alice and 30,000 to Bob. Then they revoke the old one. Nothing is broadcast. The payment is complete as soon as both hold the new signatures, which takes an exchange of a few messages.
Two more payments, of 10,000 and 20,000 sats, work the same way. The balance moves to 60,000 and 40,000, then to 40,000 and 60,000.
Revoking matters. If either side broadcast an old, more favourable balance, the other could use a revocation key to claim everything in the channel through a penalty transaction. That threat is what lets two strangers keep a running balance without trusting each other.
Closing the channel
Closing takes one more Bitcoin transaction, which pays each side its final balance: 40,000 sats to Alice and 60,000 to Bob in the example, less the network fee.
If both cooperate, this is a mutual close. The specification notes that it lets both sides reach their funds straight away and can be negotiated with lower fees. If one side has vanished, the other can close alone by broadcasting its latest commitment transaction. That works, but the transaction is larger, and the side that broadcasts it must wait for a delay agreed in advance before it can spend its share.
Three payments, two on-chain transactions. The count would be the same for three hundred payments, and that is the point of a channel.
How payments are routed across the network
Channels join up into a network, so you can pay someone you have no channel with, as long as a path of channels leads to them.
Say Alice has a channel with Bob, and Bob has one with Carol. Alice wants to pay Carol. Carol picks a random secret and gives Alice its hash, a fingerprint that reveals nothing about the secret itself. Alice offers Bob a conditional payment: he gets the money if he can show the secret before a deadline. Bob offers Carol the same deal with an earlier deadline. Carol knows the secret, so she claims her payment from Bob by revealing it. Bob now knows it too and uses it to claim from Alice.
This conditional payment is the HTLC. The specification's own example gives the first hop six hours and the next hop five, which is why Bob always has time to collect after he has paid out. Bob can refuse to forward a payment, or go offline and hold it up until the deadline passes and the money returns to Alice. He cannot keep it, because he is paid only if Carol is.
Before any of this, Alice's wallet has to find the path. Nodes tell each other which channels exist and what each one charges, and the sender's software chooses a route from that map. A route can fail, for example when a channel along it does not have enough balance on the right side. The wallet then tries another.
Invoices, Lightning addresses and LNURL
To be paid over Lightning, the recipient gives the payer a request to pay. The basic form of that request is an invoice, and the other formats exist to fetch one.
Lightning invoices (BOLT 11)
A Lightning invoice is a payment request created by the recipient's wallet for one payment. The format is defined in BOLT 11, which describes it as QR-code-ready, and on the Bitcoin network an invoice starts with the letters lnbc.
An invoice carries the hash of the recipient's secret and a description, usually an amount, and often an expiry time. If no expiry is set, the default is 3,600 seconds, or one hour. The payer's wallet reads the code, finds a route and pays. The secret that comes back when the payment succeeds is the payer's proof of payment.
Lightning addresses
A Lightning address looks like an email address, for example [email protected], and it can be used again and again (LNURL document LUD-16). When you type one into a wallet, the wallet asks the web server behind the address for a fresh invoice in the background. The glossary has the short definition of a Lightning address.
LNURL pay and withdraw
LNURL is a family of small protocols that let a wallet talk to a web service through a link, a QR code or an NFC tap. A pay request (LUD-06) is a static code that can be scanned many times, and each scan produces a new invoice. A withdraw request (LUD-03) runs the other way: your wallet creates the invoice and the service pays it, which is how a contactless card can pull a payment. The glossary entry for LNURL has the one-line version.
| Format | Looks like | Reusable | Typical use |
|---|---|---|---|
| Lightning invoice (BOLT 11) | A long code starting lnbc, usually shown as a QR code | No. One payment, and it expires | Paying at a till or an online checkout |
| Lightning address (LUD-16) | [email protected] | Yes | Tips and donations |
| LNURL pay (LUD-06) | A static QR code or link | Yes | A printed code on a counter |
| LNURL withdraw (LUD-03) | A QR code, a link or an NFC tap | Decided by the service | Cashing out of a service; contactless cards |
Formats as defined in BOLT 11 and in LNURL documents LUD-03, LUD-06 and LUD-16, read 12 October 2026. The typical uses are examples, not rules.
What a Lightning payment costs
A Lightning payment can involve three kinds of cost: routing fees, on-chain fees for opening and closing channels, and whatever your wallet or provider charges.
Routing fees go to the nodes that forward your payment. Under BOLT 7, each node sets its own price per channel in two parts: a fixed base fee, quoted in thousandths of a sat, and a proportional fee, quoted in millionths of the amount forwarded. The sender's software adds up the fees along the route before it sends and can refuse routes that cost too much; the Bolt Card service, for one, has a setting for the maximum network fee.
Worked example: one routing fee
The prices here are invented for illustration. A payment of 50,000 sats crosses two routing nodes. Each charges a base fee of 1 sat plus 100 millionths (0.01%) of the amount.
Each hop costs about 1 + 5 = 6 sats, so the route costs about 12 sats, or 0.024% of the payment. Real fees differ from node to node and change over time, so take the method from this example, not the numbers.
On-chain fees apply at the edges. Opening a channel and closing it are ordinary Bitcoin transactions and pay the network fee of the day. If a provider runs the channels for you, you may never see those fees directly, but someone pays them, and the provider may add its own charge or build it into an exchange rate. For CoinCorner's own services, the fees page lists every fee CoinCorner publishes.
Lightning or on-chain: which to use when
Lightning and on-chain payments move the same bitcoin in two different ways, and each is better at a different job.
| Question | Lightning | On-chain |
|---|---|---|
| Speed | Usually seconds, once a route is found | Waits for a block, roughly every 10 minutes (the interval the white paper supposes); recipients often wait for more than one |
| Cost | Routing fees set by nodes, usually small next to the payment, plus on-chain fees to open and close channels | A network fee per transaction that depends on demand for block space, not on the amount sent |
| Size of payment | Limited by the balances in the channels along the route | Any size |
| Finality | Settled between channel partners at once; enforced on the blockchain only if a channel closes | Recorded on the blockchain and harder to reverse with each block added |
| Who needs to be online | Sender, recipient and routing nodes, or a provider acting for them | Only the sender, at the moment of sending |
| Good fit for | Everyday spending, tips, tills and frequent small transfers | Large or occasional transfers, opening channels and long-term storage |
| Main drawback | A payment can fail to find a route, and channels need a device or a service watching them | Slower, and the fee can exceed the value of a small payment when the network is busy |
The two work together: on-chain to move larger sums and to open channels, Lightning to spend. Either way you need some bitcoin first, and the buy page shows how to buy Bitcoin to fund a Lightning wallet with pounds.
Lightning in a shop: tapping a Bolt Card
A Bolt Card is a contactless card that pays over the Lightning Network, and one tap of it uses every idea described above.
CoinCorner sells the card in its shop for £4.99 per design and describes it as “the world's first contactless Bitcoin Lightning card”. That is the firm's own description. The card's open specification says it lets a customer pay at a merchant's point of sale over Lightning, and it builds on the LNURL withdraw request. The about page has more on the company behind the Bolt Card.
This is one tap, step by step, as the specification and CoinCorner's product page describe it:
The till shows a request
The merchant enters the amount, and the point-of-sale device creates a Lightning invoice for it.
The card is tapped
The reader picks up a web link from the card's NFC chip. The link changes with every tap, so a copied link cannot be used a second time.
The card service applies its rules
The merchant's system calls the service behind the card. The service confirms the card is genuine and checks its rules; the specification lists a switch to enable or disable the card and limits per transaction and per day as examples.
The invoice is paid
The service pays the merchant's invoice from its Lightning node. The payment is routed across the network as described earlier, and the till shows it as received.
The card holds no bitcoin. It is a key that asks a service to pay, so the balance and the rules stay with the service. CoinCorner's card can be set up as a debit card linked to your account or as a gift card.
The original open-source repository is now marked as no longer maintained and points to a newer implementation, Bolt Card Hub. The steps above follow the original specification, read 12 October 2026.
Lightning for businesses
A business can use Lightning to take Bitcoin payments at a till in seconds, and it does not have to run the technology itself.
Three properties matter to a merchant. Speed: a Lightning payment usually completes in seconds, with no wait for a block. Finality: there is no card scheme behind the payment and no chargeback mechanism, so a refund is a new payment in the other direction. Cost: the sender pays the routing fees, and what the merchant pays depends on the processor.
Instead of running a Lightning node, a business can use a payment processor that issues the invoice, receives the bitcoin and pays out in pounds, so the firm is not exposed to the bitcoin price after the sale.
CoinCorner Checkout is that kind of service. It takes Bitcoin payments in a shop through an app, online through a payment gateway or by email invoice, charges a 1% fee and converts each payment to pounds or euros straight away, with no chargebacks. Which networks your own set-up accepts, the main chain, Lightning or both, is a question to settle when you sign up. The product page explains how to accept Bitcoin and Lightning payments in your business.
Sending money abroad over Lightning
Lightning can also carry a cross-border transfer, with bitcoin acting only as the vehicle in the middle.
CoinCorner's Send Globally works this way. You start with a balance in pounds or euros. It is converted to bitcoin and sent over the Lightning Network to a third-party partner, which converts it into the recipient's local currency and pays it into a bank account or a mobile money wallet. The sender starts in pounds or euros and the recipient ends in local currency; the bitcoin leg happens in between.
CoinCorner's fee for the transfer is £0.00, and its page says a third-party service fee may be added, so check the amount the recipient will get before you send. The exchange rate at each end is part of the cost too. The destination countries differ between CoinCorner's own pages, so they are not listed here. The fees page keeps the current Send Globally and Bolt Card charges.
Limits and risks of Lightning
Lightning trades some of the simplicity of on-chain Bitcoin for speed, and that trade has costs.
- Liquidity and size. A payment can be only as large as the balances available along its route, and you can receive only as much as the other side of your channels holds. BOLT 2 also suggests that each side keeps a reserve of 1% of the channel that it does not spend.
- Being online. To receive a payment your node has to be reachable, and something has to watch the blockchain in case an old balance is broadcast. Otherwise you rely on a provider.
- Custodial or not. With a custodial wallet a company holds the bitcoin and you hold a claim on that company. With a non-custodial wallet you hold the keys and the responsibility for backups. The security page explains how balances are protected at CoinCorner.
- No reversals. A completed payment cannot be recalled. Check the amount and the recipient before you pay.
- Young software. The protocol is still being extended, and the specification labels itself version 0. Bugs and failed payments happen.
None of this changes the risk of bitcoin itself, whose price can fall sharply. The legal background is in the guide to how Bitcoin is regulated in the UK.
Frequently asked questions
Is the Lightning Network the same as Bitcoin?
No. Lightning is a separate payment layer built on top of Bitcoin, and it moves the same bitcoin, not a different coin. Payments are made by updating balances inside channels, and the Bitcoin blockchain records only the transactions that open and close those channels. If a channel partner misbehaves or disappears, the blockchain is where the final balance is enforced.
Are Lightning payments instant?
Usually within seconds, but not always. A payment inside an open channel settles as soon as both sides sign the new balance, with no wait for a block. Across the network it also needs a route with enough balance, and finding one can take several attempts or fail. Opening a channel in the first place is an on-chain transaction and needs confirmation.
What are Lightning Network fees?
They are routing fees paid by the sender to the nodes that forward a payment. Each node sets a fixed base fee plus a proportional fee measured in millionths of the amount, so the cost is usually small next to the payment. Opening and closing a channel also costs a normal Bitcoin network fee, and a wallet or service provider may add its own charge.
Can I move Bitcoin between the main chain and Lightning?
Yes. Bitcoin moves onto Lightning when a channel is opened and back to the main chain when it is closed. A wallet or service can also swap between the two for you by taking a payment on one side and paying out on the other. Each route involves at least one on-chain transaction, so it costs a network fee and takes longer than a Lightning payment.
Is the Lightning Network secure?
It is designed so that nobody you route through can take your money, but it carries risks of its own. Each payment is locked to a secret and a deadline, and an attempt to broadcast an old channel balance can be punished by losing the whole channel. Against that, funds sit in online wallets, channels must be monitored, software can have bugs, and with a custodial wallet you depend on the provider.
Do I need to run a node to use Lightning?
No. A wallet app can do the work of a node for you, either by running a small node on your phone or by connecting to one run by a provider. Running your own node gives you more control and privacy, but you have to keep it online, manage channel balances and keep backups. With a provider-run wallet you trade that work for reliance on the provider.
Sources
- Joseph Poon and Thaddeus Dryja, The Bitcoin Lightning Network: Scalable Off-Chain Instant Payments, draft version 0.5.9.2, 14 January 2016: https://lightning.network/lightning-network-paper.pdf (read 12 October 2026)
- Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System: https://bitcoin.org/bitcoin.pdf (read 12 October 2026)
- Lightning specifications, BOLT 0: Introduction and Index (channels, conditional payments, glossary): https://github.com/lightning/bolts/blob/master/00-introduction.md (read 12 October 2026)
- Lightning specifications, BOLT 2: Peer Protocol for Channel Management (channel reserve, closing a channel): https://github.com/lightning/bolts/blob/master/02-peer-protocol.md (read 12 October 2026)
- Lightning specifications, BOLT 7: P2P Node and Channel Discovery (how routing fees are set): https://github.com/lightning/bolts/blob/master/07-routing-gossip.md (read 12 October 2026)
- Lightning specifications, BOLT 11: Invoice Protocol for Lightning Payments: https://github.com/lightning/bolts/blob/master/11-payment-encoding.md (read 12 October 2026)
- LNURL Documents: LUD-03 (withdraw request), LUD-06 (pay request) and LUD-16 (paying to static internet identifiers): https://github.com/lnurl/luds (read 12 October 2026)
- Bolt Card project: overview and card specification: https://github.com/boltcard/boltcard (read 12 October 2026)
Facts about CoinCorner's own products (the Bolt Card, Send Globally and Checkout) were read from the product pages on coincorner.com on 6 October 2026.
For information only. Not investment advice. Nothing in this guide is a recommendation to buy, sell or hold bitcoin.