TERM_DEF // LIGHTNING_NETWORK / NATIVE_FORWARDING
NATIVE
FORWARDING
FORWARDING
Native Forwarding. Forwarding an HTLC without intermediate currency conversion.
This page sits in the Lightning Network section — Off-chain payment channels and routed micropayments built on top of Bitcoin. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
This page sits in the Lightning Network section — Off-chain payment channels and routed micropayments built on top of Bitcoin. Read on for what it is, why it exists, how it works under the hood, and what to watch out for.
WHAT_NATIVE_FORWARDING_IS
Native Forwarding — at a glance
LIGHTNING NETWORK
Native Forwarding is part of the Lightning Network — a Layer 2 payment network built on top of Bitcoin that uses bidirectional payment channels and HTLC routing to settle millions of small payments per second without every one of them hitting the base chain. Forwarding an HTLC without intermediate currency conversion.
Why it exists
DESIGN
Bitcoin's base layer settles a few hundred thousand transactions per day — far fewer than a global payment network would need. Lightning solves the scaling problem by keeping most payments off-chain in two-party channels secured by the base layer, with the ability to settle on-chain at any time. Payments inside the network are routed atomically via HTLCs (Hash-Time-Locked Contracts), so a sender pays a receiver many hops away without trusting any intermediate.
HOW_IT_WORKS
Mechanism
HOW IT WORKS
Two parties open a channel by locking BTC into a 2-of-2 multisig output on-chain. They then update the channel state off-chain by exchanging signed transactions — each new state revokes the previous one with a punishment mechanism. To pay someone far away, the sender constructs an HTLC payment that hops through several channels; each hop is cryptographically bound to the same preimage, so all hops succeed or none do.
1. Alice and Bob open a channel: 2-of-2 multisig funding tx on-chain, agreed initial state with their balances.
2. Alice pays Bob 100 sats → both sign a new state with the updated balances (state #2), revoking state #1.
3. Repeat: thousands of payments back and forth, all off-chain, instant, fees in millisats.
4. To pay Carol (no direct channel), Alice routes through Bob: HTLC #1 Alice→Bob, HTLC #2 Bob→Carol, both locked to the same preimage hash.
5. Carol reveals the preimage to claim from Bob → Bob uses it to claim from Alice. Atomic, trustless, all-or-nothing.
6. At any time either party can close the channel by broadcasting the latest signed state on-chain — the network settles to base-layer Bitcoin.
WORKED_EXAMPLE
A Lightning payment in numbers
EXAMPLE
On-chain BTC fee : ~1,000–50,000 sats per tx (depends on congestion)
Lightning fee : ~0–10 sats per hop (often <1 cent total)
Channel opening : 1 on-chain tx
Channel closing : 1 on-chain tx (cooperative) or 2 (force-close)
Per payment after open: 0 on-chain txs
Payment latency : ~100–500 ms (vs. ~10 min for on-chain confirmation)
Payment max size : 0.0429 BTC (4.29M sats), can be lifted with wumbo channels
Typical wallet flow:
open 0.01 BTC channel → 1 on-chain fee
send 10,000 small payments → 0 on-chain fees, <1 second each
close channel → 1 on-chain fee
Total on-chain footprint: 2 txs vs. 10,002 on the base layer.
KEY_PROPERTIES
OFF-CHAIN
Updates happen between two parties only. The base chain settles disputes if either party tries to cheat.
TRUST-MINIMISED
Each state revokes the previous one with a penalty mechanism; cheating loses you the entire channel balance.
INSTANT
~100–500 ms end-to-end, even across many hops. Compared to 10-minute on-chain confirmations, Lightning feels like a card payment.
PAY-TO-INVOICE
Senders pay BOLT-11 invoices: a destination, amount, preimage hash, and a route hint. The receiver can pre-commit to the payment.
COMMON_PITFALLS
Things that catch people out
PITFALLS
- Channels need liquidity/">inbound liquidity to receive payments. New nodes often struggle to receive until they swap or pay an LSP for capacity.
- Force-closes spam the on-chain mempool with extra transactions and incur larger fees than cooperative closes.
- Routing fails silently — many implementations retry with different paths, but a payment can simply not find a route at high volumes.
- A watchtower is needed if you go offline for long periods — without one, your counterparty could cheat with an old state.
RELATED_CONCEPTS
Other terms from Lightning Network — click any to read its page:
TERMINOLOGY_INDEX
TERMINOLOGY
Native Forwarding
Forwarding an HTLC without intermediate currency conversion.
Lightning Network
A network of payment channels enabling instant, cheap Bitcoin payments off-chain.
Payment Channel
A 2-of-2 multisig output funded by both parties; balance is rewritten off-chain via signed commitment txs.
Channel Open Transaction
The transaction/">funding transaction creating the channel's on-chain anchor UTXO.
Channel Close Transaction
Any on-chain transaction spending the channel UTXO, ending the channel.
Cooperative Close
Both parties sign a fresh tx splitting the current balance; lowest-fee close path.
Force Close
One party broadcasts the latest commitment tx unilaterally; pays higher fees and triggers timelocks.
Commitment Transaction
A pre-signed off-chain tx representing the current channel balance; spendable but penalized if old.