Learn › Module 5 of 6

Lightning and swaps

On-chain payments are public, final and relatively slow. Lightning moves payments off the chain — inside a shared deposit called a channel.

1. Why Lightning exists

Every on-chain payment occupies space in a block, must be confirmed, and costs a fee. That is fine for buying a house, and terrible for buying coffee.

Lightning pays for the coffee by moving value off-chain between two parties who already locked funds together, and only settles on-chain when they decide to close. Result: instant confirmation, fees of a few satoshis, and privacy by default (payments are not published).

The trade: you depend on a counterparty staying reachable and on having liquidity where you need it.

2. Anatomy of a channel

A channel is a shared deposit between you and another node:

1. Open — one on-chain transaction locks funds in a contract that requires both signatures (2-of-2). From the chain's point of view the money now belongs to "the channel".
2. Use — you and the peer exchange signed updates. Each payment shifts the split: some of it is yours, some is theirs. Updates are instant and do not touch the chain.
3. Close — the final split goes back on-chain, to your address and theirs, in a normal transaction.

Think of it as a tab at a bar: you deposit an amount, you both keep signing the current balance, and at the end you settle once.

3. The words you will meet

• Capacity — the total locked in the channel. It never grows by itself; you can add funds with a splice or a new channel.
• Your side / peer's side — how the capacity is split right now. Your side grows when people pay you and shrinks when you pay.
• Inbound liquidity — how much the peer can send to you. A freshly opened channel has none: you can pay, not receive. To receive you need someone to open toward you, or a service that sells inbound liquidity.
• Reserve — a slice of your side that stays locked as a safety margin, so a misbehaving peer cannot empty the channel.
• Force close — broadcasting the last signed state unilaterally. Irreversible, slower and more expensive than a cooperative close.
• To-self delay — after a force close, your money is encumbered for a number of blocks before you can spend it. That delay is what punishes cheating.
• HTLC — a conditional payment: "these funds move if the receiver reveals the secret before the deadline". It is how a payment hops across several channels safely.
• Routing fees — what a node earns for forwarding someone else's payment through its channel. If you route payments, this is income, not a cost.
• Peers — the nodes you are directly connected to. Connectivity is not the same as having a channel.

4. Closing: cooperative vs forced

A cooperative close is the normal path: both sides agree, one on-chain transaction, funds available after it confirms, fees shared.

A force close is the emergency exit: you stop waiting for the peer and publish the last state yourself. You pay the on-chain fee alone, wait for confirmations, and then wait again for the to-self delay. Use it when the peer is offline or hostile — not as a shortcut.

5. Your node, and the app as a remote control

Lightning needs a node that stays online: a small computer or a VPS running the Lightning daemon. This app can connect to your node and act as its remote control, keeping the keys on your machine.

• Channels, payments, invoices, peers and channel management are all driven from the app.
• Your node's identity (pubkey) and funds stay yours; the connection is authenticated, not a cloud account.
• Node installer, checksum verification and the threat model: node page.

6. Swaps: paying without a node

If you do not run a node, you can still pay a Lightning invoice with an atomic swap through a provider:

1. the provider pays the invoice immediately on Lightning;
2. you reimburse the provider on-chain;
3. an escrow contract with timelocks guarantees that either both legs execute or your funds come back — after the timeout.

What to know before using it:

• it is experimental on this network and depends on the provider's liquidity;
• you pay the swap fee on top of the on-chain fee;
• if the provider disappears mid-way, you wait for the timelock to reclaim your funds — so never swap an amount you may need urgently;
• an "atomic" guarantee protects you from losing the money, not from losing time.

7. Starting small

1. Open a channel with a modest amount — enough to pay for a few weeks of tests, small enough to lose without drama.
2. Leave funds on-chain for fees and for emergencies: an empty on-chain balance with an active channel is a bad place to be.
3. Pay something to yourself (another wallet, or an invoice you generated) to see confirmations, statuses and fees in the app.
4. Only then think about inbound liquidity, routing and bigger channels.

8. Check yourself

1. You open a channel with 100 000 sat. Can you immediately receive 5 000 sat over Lightning?
2. Why does a force close take longer than a cooperative one?
3. What does the escrow in a swap guarantee, and what does it not guarantee?