How On-Chain Transactions Work
Every on-chain Bitcoin transaction follows the same path. You broadcast a signed transaction to the network. A standard transaction includes inputs (references to previous unspent transaction outputs, or UTXOs), outputs (new UTXOs specifying recipient addresses and amounts), and a witness section containing the digital signatures that prove authorization. The transaction enters the mempool, where it waits alongside other unconfirmed transactions. Miners select transactions from the mempool, prioritizing those with higher fee rates (measured in sats per virtual byte), and include them in the next block. Once a block containing your transaction is mined, the transaction has one confirmation. Each subsequent block adds another confirmation, making the transaction progressively harder to reverse.
This process takes an average of ten minutes per block. For small payments, one confirmation may be sufficient. For larger transfers, recipients often wait for three to six confirmations (30 to 60 minutes) before considering the payment fully settled. The security comes from the cumulative proof-of-work stacked on top of your transaction: reversing a transaction buried under six blocks would require an attacker to outpace the entire mining network for over an hour.
On-Chain Fee Structure
On-chain fees are market-driven. You pay based on transaction size in virtual bytes (vbytes), not the amount of bitcoin being sent. Virtual bytes account for the SegWit discount: witness data (signatures and scripts) is counted at one-quarter weight, while non-witness data counts at full weight. A simple one-input, two-output SegWit transaction is typically around 140-180 vbytes. A transaction sending 0.001 bitcoin and one sending 100 bitcoin can cost the same fee if they have the same data size. During high demand, fees rise as users compete for limited block space (capped at 4 million weight units per block, which translates to roughly 1.5 to 2.5 MB in typical blocks). During quiet periods, fees drop to a few hundred sats.
A transaction that costs 500 sats during a quiet weekend might cost 50,000 sats during a congestion event. For large transfers, these fees are negligible relative to the amount moved. For small payments, they can exceed the payment itself.
On-Chain Privacy
The Bitcoin blockchain is a public ledger. Every on-chain transaction is visible to anyone running a node or using a block explorer. Transaction amounts, addresses, and fees are recorded permanently. While addresses are pseudonymous, chain analysis techniques can link transactions together and often identify the parties involved.
This transparency is useful for auditability and a limitation for financial privacy. Anyone who knows one of your addresses can trace the flow of bitcoin into and out of it and follow your transaction history across the blockchain.
How Lightning Transactions Work
The Lightning Network is a layer-2 payment channel network built on top of Bitcoin. Instead of broadcasting every payment to the entire network and waiting for block confirmations, Lightning routes payments through a web of pre-funded channels that settle instantly between participants.
The process starts with a channel. Two parties create an on-chain funding transaction that locks bitcoin into a 2-of-2 P2WSH multisig output, as defined in BOLT 2 (peer protocol for channel management). This funding transaction is the only part that touches the blockchain. Once the channel is open, the two parties exchange bitcoin back and forth by updating their shared balance, signing new commitment transactions that reflect each payment. Each commitment transaction includes a revocation mechanism: if either party broadcasts an outdated state, the counterparty can claim all funds in the channel as a penalty (the "penalty transaction" defined in BOLT 5). These updates happen in milliseconds, cost almost nothing, and can occur an unlimited number of times.
The power of Lightning is routing. You do not need a direct channel with every person you want to pay. If you have a channel with Alice, and Alice has a channel with Bob, you can pay Bob by routing through Alice. Hash Time-Locked Contracts (HTLCs), governed by BOLT 2 and BOLT 3, guarantee that every hop in the route either completes atomically or fails entirely. Each HTLC locks funds with a SHA-256 hash and a per-hop timelock (the cltv_expiry_delta), staggered so that each node in the route has time to claim its payment before the previous hop's lock expires. The payment either reaches the recipient in full, or it does not leave the sender.
When the participants are done, they close the channel with a final on-chain transaction that distributes the bitcoin according to the latest agreed-upon balance. The blockchain only ever sees two transactions: the channel open and the channel close.
Lightning Fee Structure
Lightning fees are measured in millisatoshis (thousandths of a satoshi). Routing nodes charge a small base fee (fee_base_msat) plus a proportional fee on the payment amount (fee_proportional_millionths), both announced in BOLT 7 channel update messages. A typical routing fee is a fraction of a satoshi. Even for larger payments routed across multiple hops, fees rarely exceed a few sats.
These low fees make transactions economically viable at any amount. The fee does not scale with network congestion the way on-chain fees do, because Lightning payments do not compete for block space.
Security Guarantees Compared at the Protocol Level
On-chain security is probabilistic and cumulative. Each new block of proof-of-work added on top of a transaction increases the cost an attacker would need to spend to reverse it. After six blocks (roughly one hour), reversing a transaction would require an attacker to generate more proof-of-work than the entire mining network produced in that hour. The economic cost scales with Bitcoin's total hashrate, which as of early 2026 exceeds 800 EH/s. At that level, reversing a six-confirmation transaction would cost an attacker more in energy and forgone block rewards than virtually any payment is worth.
Lightning security rests on an economic penalty rather than accumulated proof-of-work. The bitcoin locked in a payment channel is secured by a 2-of-2 multisig enforced by the Bitcoin base layer. The channel's current state is tracked off-chain through commitment transactions that both parties sign and keep off-chain until settlement. The security guarantee comes from the penalty mechanism: if one party broadcasts an old commitment transaction (attempting to claim more than their current balance), the counterparty has a window (defined by the to_self_delay parameter, typically 144 to 2,016 blocks) to broadcast a penalty transaction that claims all channel funds. This mechanism means the bitcoin in a Lightning channel is protected by the same base-layer security as an on-chain transaction, provided at least one party (or a watchtower acting on their behalf) is monitoring the blockchain.
On-chain finality is passive: once a transaction confirms, no monitoring is needed. Lightning finality requires active monitoring during the channel's lifetime. For users who want Lightning's speed with hardware wallet security for their reserves, the Blockstream app supports on-chain and Liquid alongside Lightning, and Jade Plus can sign on-chain and Liquid transactions with air-gapped QR codes for cold storage of larger balances.
Lightning Privacy
Lightning offers a different privacy model than on-chain transactions. Payment details (amount, sender, receiver) are only known to the parties involved and the routing nodes along the path. Payments are not recorded on any public ledger. Onion routing ensures that no single routing node knows both the original sender and the final recipient.
Channel opening and closing transactions are visible on-chain, so an observer can see that a channel exists between two parties and the total amount locked in it. But the individual payments flowing through that channel are invisible to the blockchain.
Side-by-Side Comparison
The following table compares on-chain and Lightning transactions across the dimensions that matter most when choosing between them.
| Dimension | On-Chain | Lightning |
|---|---|---|
| Speed | ~10 minutes per confirmation; 3-6 confirmations recommended for larger amounts | Near-instant settlement |
| Fees | Variable, market-driven. Can range from a few hundred sats to tens of thousands during congestion. | Near-zero. Typically fractions of a satoshi per hop. |
| Transaction Size | No practical maximum. Minimum constrained by fees (dust limit). | Excels at small amounts. Large payments limited by channel capacity and route liquidity. |
| Privacy | Transparent public ledger. All amounts, addresses, and fees permanently visible. | Payment details known only to sender, receiver, and routing path. Not recorded on any public ledger. |
| Finality | Probabilistic. Each confirmation adds security. Six confirmations considered practically irreversible. | Instant local finality. Payment either completes atomically or fails entirely. |
| Capacity | Limited by block space (~4 MWU per block, ~7-15 transactions per second globally post-SegWit depending on transaction mix). | Limited by channel liquidity. Network capacity grows as more channels are opened. |
| Security Model | Full proof-of-work consensus. Most decentralized, highest security. | Payment channels secured by on-chain multisig + HTLCs. Inherits Bitcoin's PoW security for channel funding. |
| Online Requirement | None after broadcast. Transaction confirms whether you are online or not. | Channels require monitoring (node or watchtower) to prevent fraud. |
| Hardware Wallet | Full support. Standard signing workflow. | Limited. Channel management does not map well to offline signing. |
When to Use On-Chain
On-chain transactions are the right choice when security, permanence, and universal compatibility matter more than speed or cost.
Large Value Transfers
For significant amounts of bitcoin, on-chain settlement provides the strongest security guarantee available. A transfer of ten bitcoin secured by six proof-of-work confirmations is protected by the cumulative energy output of the entire mining network over the confirmation period. Institutional settlements, real estate purchases, and treasury movements belong on-chain.
Long-Term Storage Moves
Moving bitcoin into cold storage is an infrequent, high-stakes operation where confirmation time is irrelevant. On-chain transactions produce a simple, verifiable record: one UTXO at an address you control, secured by the full Bitcoin network. No channels to manage, no liquidity to maintain, no counterparty to monitor.
Maximum Security Guarantees
On-chain settlement suits inheritance planning, corporate treasury allocation, escrow settlements, and any situation where irreversibility is the priority. On-chain bitcoin, confirmed by multiple blocks of proof-of-work, is the most secure digital settlement mechanism ever built. When the stakes justify waiting, on-chain is the answer.
Universal Compatibility
Every Bitcoin wallet, exchange, and service supports on-chain transactions. Not every recipient supports Lightning. When you do not know the recipient's capabilities, or when the recipient explicitly requests an on-chain payment, the base layer is the common denominator.
When to Use Lightning
Lightning is the right choice when speed, low fees, and transaction volume matter more than the base layer's maximum security model.
Daily Purchases
Buying coffee, paying for a meal, settling a bar tab. Lightning handles these the way cash does: you pay, the merchant sees the payment arrive, and you walk away. The fee for a 5,000-sat coffee over Lightning is a fraction of a satoshi. The same payment on-chain during a fee spike could cost more than the coffee itself.
Micropayments
Lightning makes it economically viable to send amounts that would be impossible on-chain. Streaming sats to a podcast at one sat per second. Tipping a content creator 50 sats. Paying for an API call at 10 sats per request. On-chain, the minimum practical transaction is constrained by the dust limit: the threshold below which an output costs more in fees to spend than it is worth. On Lightning, there is no floor.
Point-of-Sale Payments
At a physical register, the payment needs to confirm before the customer walks away. Lightning settles in seconds. The payment either completes or fails, with no confirmation window in between. The merchant faces no double-spend risk and does not need to trust an unconfirmed transaction. For retail and food service businesses accepting bitcoin, Lightning is the operational standard.
When Fees Need to Be Minimal
During high on-chain congestion, base-layer fees can spike to 10,000 or 50,000 sats for a simple transaction. Lightning fees remain stable regardless of on-chain conditions because Lightning payments do not compete for block space. For users making frequent smaller transactions, staying on Lightning during congestion periods saves significant fees over time.
Liquid: A Third Option
On-chain and Lightning are not the only choices. The Liquid Network, a federated Bitcoin sidechain, occupies a distinct space between the two and serves use cases that neither handles well on its own.
When Liquid Fits Best
- Trading and exchange transfers. Moving bitcoin between exchanges that support Liquid settles in roughly one minute instead of waiting for six on-chain confirmations (about an hour). For active traders, this speed difference directly impacts their ability to respond to market conditions.
- Privacy-sensitive transfers. Liquid uses Confidential Transactions, which hide both transaction amounts and asset types from outside observers. On-chain transactions are fully transparent. Lightning offers partial privacy but still exposes channel openings and closings on-chain. Liquid's privacy is built into the protocol and applies to every transaction by default.
- Asset issuance. Liquid supports creating and transferring assets beyond bitcoin: stablecoins like USDT, security tokens, and other Issued Assets. Every Issued Asset inherits the same Confidential Transactions privacy as Liquid bitcoin (LBTC). For organizations that need multi-asset functionality on a Bitcoin-based network, Liquid provides the infrastructure.
- Hardware wallet security for layer-2. Lightning's channel architecture does not translate well to offline signing workflows. Liquid transactions use a standard UTXO model compatible with hardware wallets. Jade Plus signs Liquid transactions natively using air-gapped QR codes, making it the only Bitcoin hardware wallet with native Liquid support.
Liquid fills a specific gap: faster than on-chain, more private than both, capable of handling multiple asset types, and compatible with hardware wallet security. For users who need any of those properties, Liquid is worth considering alongside on-chain and Lightning.
The Decision Framework
Choosing between on-chain and Lightning is not a permanent decision. Most active Bitcoin users move between both layers regularly, choosing the one that fits each specific transaction. The following framework captures the key decision points.
Quick Decision Guide
Use on-chain when:
- The amount is large and security is the priority
- You are moving bitcoin to or from cold storage
- The recipient only supports on-chain
- You need the transaction to be verifiable on the public ledger
- Time is not a constraint
Use Lightning when:
- You need instant settlement
- The amount is small to medium
- You are making a point-of-sale purchase
- You want to minimize fees
- You are sending micropayments or streaming sats
Consider Liquid when:
- Privacy is a priority (Confidential Transactions)
- You are moving bitcoin between Liquid-supporting exchanges
- You need multi-asset support (USDT, security tokens)
- You want layer-2 speed with hardware wallet signing
| Scenario | Best Layer | Why |
|---|---|---|
| Buying coffee at a cafe | Lightning | Near-instant settlement, near-zero fees |
| Moving 2 bitcoin to a hardware wallet | On-chain | Maximum security, simple UTXO, no channel management |
| Streaming sats to a podcast | Lightning | Per-second micropayments only viable on Lightning |
| Institutional treasury settlement | On-chain | Highest security guarantees for large amounts |
| Tipping a content creator 100 sats | Lightning | Amount too small for economical on-chain transaction |
| Paying a freelancer's monthly invoice | Lightning or On-chain | Lightning if they support it and fees are high; on-chain if they prefer it |
| Moving bitcoin between exchanges | Liquid | Faster than on-chain, private, no capacity limits |
| Buying a used car with bitcoin | On-chain | Large purchase, recipient likely expects on-chain, security matters |
| Paying for a subscription service | Lightning | Recurring small payment, speed and low fees preferred |
How the Layers Work Together
On-chain and Lightning are not competing systems. Lightning depends on the base layer: channels are opened and closed with on-chain transactions, and Lightning's security model derives from the ability to settle disputes on-chain.
In practice, most Bitcoin users operate across both layers. They hold bitcoin on-chain in long-term storage, move smaller amounts into Lightning channels for spending, and return to on-chain when they want to consolidate or secure funds. The Blockstream app supports on-chain, Lightning, and Liquid from a single interface, letting you send and receive across all three layers without switching between separate wallets.
The Typical Flow
A common pattern: receive bitcoin on-chain from an exchange withdrawal or a sale, move a portion into Lightning for weekly spending, use Lightning for daily purchases and tips, then periodically consolidate back to on-chain for cold storage on a hardware wallet. If you need privacy or want to trade across exchanges, route through Liquid.
Each layer serves its role. The base layer anchors everything with maximum security. Lightning handles the high-frequency, low-value transactions that the base layer was never designed to process individually. Liquid fills the gap for private transfers, exchange settlement, and multi-asset use cases. Bitcoin moves freely between layers based on what each transaction requires.
Cross-Layer Mobility
Lightning ↔ Liquid swaps let you shift between instant payments and private settlement. On-chain ↔ Lightning channel opens and closes move bitcoin between the base layer and the payment network. On-chain ↔ Liquid peg-ins and peg-outs connect the base layer and the sidechain.
The trend in Bitcoin infrastructure is toward making these transitions seamless. Core Lightning (CLN), Blockstream's Lightning implementation, is one of the major open-source node implementations powering this routing infrastructure. As cross-layer tooling matures, users increasingly think about what they want to do (pay, save, trade, transfer) rather than which layer to use. The layer becomes an implementation detail handled by the wallet.
Frequently Asked Questions
Is Lightning less secure than on-chain Bitcoin?
Lightning inherits Bitcoin's security through its on-chain channel funding transactions. The bitcoin locked in a Lightning channel is secured by the same proof-of-work consensus as any on-chain UTXO. The trade-off is operational: Lightning channels require monitoring (either by running a node or using a watchtower) to prevent a counterparty from broadcasting an outdated channel state. The penalty mechanism (BOLT 5) gives the honest party a time window (the to_self_delay, typically 144 to 2,016 blocks) to detect fraud and broadcast a penalty transaction. For the bitcoin locked in channels, the base-layer security is equivalent. The additional requirement is that someone is watching.
Can I send large amounts over Lightning?
Lightning can handle larger payments, but the practical limit depends on channel capacity and route liquidity. A payment of 1,000,000 sats (0.01 bitcoin) routes reliably in most cases. Payments of several million sats may need to be split across multiple routes using Multi-Path Payments (MPP), defined in BOLT 4 as a way to split a single payment across multiple paths. For very large transfers (multiple bitcoin), on-chain is more reliable because it has no capacity constraints beyond the fee.
Do I need to run a Lightning node to use Lightning?
No. Many wallets, including the Blockstream app, handle Lightning connectivity for you. Running your own node gives you full control over channels and routing, but wallets exist for users who want Lightning's speed without managing infrastructure. For self-custodial Lightning use, some form of channel monitoring (a node or a watchtower) is needed to maintain security.
What happens if on-chain fees are high and I need to open a Lightning channel?
Opening and closing Lightning channels are on-chain transactions subject to on-chain fee rates. If fees are high, opening a new channel costs more. The funding transaction that opens a channel is typically 150-200 vbytes (for a standard P2WSH output), so the cost is directly proportional to the prevailing sat/vbyte fee rate. The strategy is to open channels when fees are low and keep them open long-term. Once a channel is open, payments flowing through it are unaffected by on-chain fee conditions.
Can I use a hardware wallet with Lightning?
Lightning's channel management requires active, online key operations that do not map well to hardware wallet offline signing. For bitcoin you want secured by a hardware wallet, on-chain or Liquid are better options. Jade Plus supports both on-chain and Liquid signing with air-gapped QR codes. Most users keep smaller amounts in a software wallet for Lightning spending and reserve hardware wallet security for larger, long-term holdings.
Are on-chain and Lightning the only options?
No. The Liquid Network provides a third option: a federated sidechain with one-minute blocks, Confidential Transactions (which hide both amounts and asset types), and support for Issued Assets like USDT. Liquid is particularly useful for exchange-to-exchange transfers, privacy-sensitive payments, and any use case involving assets beyond bitcoin. The Blockstream app supports all three layers from a single interface.