What Is the Lightning Network?

By Blockstream Engineering · Last updated June 2026

Why Lightning Was Created

Bitcoin's base layer prioritizes security and decentralization above all else. Every transaction is broadcast to every node, validated by every participant, and permanently recorded in every copy of the blockchain. This architecture is central to Bitcoin's security, but it limits throughput.

The Bitcoin blockchain produces a new block roughly every ten minutes. Each block is limited to 4 million weight units (4 MWU), which translates to roughly 1.5 to 2 MB of data in typical blocks. In practice, this limits the base layer to roughly 7-15 transactions per second post-SegWit, depending on transaction mix (simple Taproot transactions take less space than complex multisig). For comparison, Visa handles roughly 10,000 transactions per second on average and claims a peak capacity of 65,000.

If every coffee purchase, every peer-to-peer payment, and every micropayment had to be recorded directly on the Bitcoin blockchain, the network would be overwhelmed. Transaction fees would spike as users compete for limited block space, and confirmation times would make point-of-sale payments impractical.

The Lightning Network addresses this by moving the vast majority of transactions off-chain. The base layer settles channel opens and closes with full Bitcoin security. Lightning handles the high-volume, low-value transactions that make Bitcoin usable as everyday money. Both layers work together: Lightning inherits its security from Bitcoin, and Bitcoin gains a scalable payment layer without sacrificing decentralization.

This layered approach mirrors how other successful systems scale. The internet runs on multiple protocol layers (TCP/IP, HTTP, TLS). The traditional financial system separates settlement (Fedwire, central bank reserves) from consumer payments (credit cards, ACH). Bitcoin uses the same principle: a rock-solid settlement layer at the base, with specialized payment layers built on top.

How Lightning Works

Lightning's core mechanism is the payment channel. A payment channel is a private, off-chain connection between two participants that allows them to exchange bitcoin as many times as they want without touching the blockchain. The lifecycle has three phases: open, transact, and close.

Opening a Channel

To open a Lightning channel, two parties create a special Bitcoin transaction called a funding transaction. This is a 2-of-2 multisig transaction on the Bitcoin blockchain, meaning both parties must agree to any changes in the channel's balance. The funding transaction locks a specific amount of bitcoin into the channel. Once the transaction confirms on-chain, the channel is open.

For example, if Alice wants to open a channel with Bob, she might fund it with 0.01 bitcoin. The funding transaction records this on the Bitcoin blockchain. The on-chain footprint is a single transaction. Everything that happens inside the channel after that point is off-chain.

Transacting Within a Channel

Once a channel is open, Alice and Bob can send bitcoin back and forth by updating the channel's balance. Each update creates a new "commitment transaction" that both parties sign, as defined in BOLT 2 (the specification for the peer protocol that governs channel operation). This commitment transaction reflects the current balance: how much belongs to Alice and how much belongs to Bob.

If Alice starts with 0.01 bitcoin in the channel and pays Bob 0.002 bitcoin, the new commitment transaction says Alice has 0.008 bitcoin and Bob has 0.002 bitcoin. If Bob pays Alice back 0.001 bitcoin, the next commitment transaction says Alice has 0.009 bitcoin and Bob has 0.001 bitcoin. These updates happen in milliseconds, with no miners involved, no fees paid to the Bitcoin network, and no block confirmations required.

Both parties hold the latest commitment transaction at all times. Either party can broadcast it to the blockchain to close the channel and claim their balance. The structure of these commitment transactions is specified in BOLT 3, which defines the exact output scripts, including to_local (with a revocation path and a delayed spending path) and to_remote outputs. A penalty mechanism ensures that neither party can cheat by broadcasting an old, more favorable commitment transaction. If someone tries, the other party can use the revocation key to claim the entire channel balance as punishment.

Closing a Channel

When Alice and Bob are done transacting, either party can close the channel. In a cooperative close, both parties agree on the final balance and broadcast a single closing transaction to the Bitcoin blockchain. This transaction distributes the channel's funds according to the last commitment transaction. The on-chain footprint is, again, a single transaction.

If one party disappears or becomes unresponsive, the other can force-close the channel by broadcasting the latest commitment transaction unilaterally. This takes longer (there is a time-lock period to allow the other party to dispute if needed), but it ensures that neither party's funds can be held hostage.

The result: two on-chain transactions (open and close) can support thousands of off-chain transactions in between, each settling in milliseconds with negligible fees.

Payment Channels Explained

What a Channel Actually Is

At the protocol level, a Lightning payment channel is a 2-of-2 multisig output on the Bitcoin blockchain. Both parties hold keys to this multisig, and both must sign any transaction that spends from it. The channel balance is tracked through commitment transactions that both parties sign but do not broadcast (unless they want to close the channel).

Each time a payment occurs within the channel, the old commitment transaction is invalidated using a revocation mechanism, and a new one is created. This revocation is what makes Lightning trustless: if one party broadcasts a revoked commitment transaction (an old state that favors them), the other party can use the revocation key to claim the entire channel balance. Cheating is punished by total loss of funds in the channel.

Capacity and Balance

A channel's capacity is the total amount of bitcoin locked in the funding transaction. It does not change during the channel's lifetime (unless a splice operation is used, a more recent protocol feature). The capacity is split between the two parties. Alice might have 0.007 bitcoin on her side and Bob might have 0.003 bitcoin on his side, totaling a capacity of 0.01 bitcoin.

The balance determines how much each party can send. Alice can send up to 0.007 bitcoin to Bob. Bob can send up to 0.003 bitcoin to Alice. As payments flow in one direction, the balance shifts. Payments in the other direction shift it back. This is why channels are most useful between parties that regularly transact with each other: the balance naturally flows back and forth.

Channel Reserves and Dust Limits

Lightning channels enforce a minimum reserve that each party must maintain. This reserve ensures that both parties always have something at stake, preventing trivially cheap cheating attempts. The standard reserve is 1% of the channel capacity. Each node also sets a minimum payment size (htlc_minimum_msat) to prevent spam, and channels have dust limits below which in-flight payments are not given their own on-chain outputs.

Routing Payments Across the Network

Lightning payments do not require a direct channel between sender and recipient. Payments route through intermediate nodes, hopping across connected channels until they reach the recipient.

Multi-Hop Payments

If Alice has a channel with Bob, and Bob has a channel with Carol, Alice can pay Carol by routing through Bob. Alice sends bitcoin to Bob within their channel, and Bob forwards the same amount to Carol within his channel. Bob's total balance across both channels stays the same; he simply shifted funds from one channel to another.

This works across many hops. Alice might pay Dave by routing through Bob, Carol, and Emily: Alice → Bob → Carol → Emily → Dave. The payment finds a path through the network automatically using pathfinding algorithms built into Lightning software.

Hash Time-Locked Contracts (HTLCs)

Multi-hop payments raise an obvious trust question: what prevents Bob from taking Alice's payment and not forwarding it to Carol? The answer is Hash Time-Locked Contracts (HTLCs).

An HTLC is a conditional payment. It says: "I will pay you X bitcoin if you can produce the preimage of this hash within Y blocks." The recipient of the final payment (Dave, in our example) generates a random secret, called the preimage, and creates a hash of it. This hash is included in the invoice that Dave sends to Alice.

When Alice initiates the payment, each hop along the route creates an HTLC locked to the same hash. Dave reveals the secret to Emily to claim his payment. Emily uses that secret to claim from Carol, Carol from Bob, and so on back to Alice. The payment either completes atomically (every hop succeeds) or fails entirely (no hop succeeds and all funds return to their original owners). No intermediate node can steal funds because they cannot claim the incoming HTLC without first fulfilling the outgoing one.

Under the Hood: How HTLCs Secure Multi-Hop Payments

HTLC security relies on two interlocking mechanisms defined in BOLT 3 (transaction formats) and BOLT 2 (peer protocol). Each HTLC is represented as a separate output in the commitment transaction, with a script that allows the funds to be claimed in two ways during normal operation: by presenting the hash preimage before the timelock expires, or by the sender reclaiming the funds after the timelock (a third, revocation spend path exists to penalize a party that broadcasts a revoked commitment). On-chain, these appear as distinct witness scripts that Bitcoin nodes validate like any other transaction.

The timelock chain is the critical element. If Alice routes a payment through Bob to Carol with a final destination of Dave, the CLTV (CheckLockTimeVerify) expiry decreases at each hop. Alice's HTLC to Bob might expire at block height N+80, Bob's HTLC to Carol at N+40, and Carol's HTLC to Dave at N+20. Per-hop CLTV deltas are set by each node and advertised in BOLT 7 channel updates. Implementation defaults vary widely: CLN defaults to 34 blocks, LND defaults to 80 blocks, and Eclair defaults to 144 blocks. Senders pad their total CLTV expiry to accommodate the worst-case delta along the path they construct. This staggering ensures that each forwarding node has sufficient time to claim its incoming payment after learning the preimage from the next hop. If any intermediate node delays or goes offline, the upstream HTLCs time out and funds return to their senders automatically.

The preimage reveal chain works backwards: Dave reveals the preimage to Carol, Carol reveals it to Bob, Bob reveals it to Alice. At each step, the forwarding node can only claim the incoming HTLC by first settling the outgoing one, because the preimage is the same across all hops. This atomic structure means the payment either fully completes or fully reverts. Partial completion, where a middleman captures funds without forwarding them, is cryptographically impossible.

Onion Routing (BOLT 4)

Lightning payments use onion routing (BOLT 4), based on the Sphinx mix-network construction. The sender builds an encrypted onion packet where each layer can only be decrypted by its intended routing node. Each hop learns only its immediate predecessor and successor; no routing node sees the full path or knows whether its predecessor is the sender or whether its successor is the final recipient. This provides strong sender/receiver privacy from intermediate routing nodes.

Routing Fees

Intermediate nodes charge small fees for routing payments. These fees have two components: a flat base fee (typically less than one sat) and a proportional fee (a percentage of the payment amount, typically 0.01% or less). Each node advertises its fee policy through the gossip protocol defined in BOLT 7, which also propagates channel announcements and node updates across the network graph. Routing fees are competitive; nodes that charge too much get routed around. The total fee for a multi-hop payment is usually a few sats, even for payments worth thousands of sats.

Lightning Invoices

To request a payment on Lightning, the recipient generates an invoice. The standard invoice format is defined in BOLT 11 (Basis of Lightning Technology, specification #11). A BOLT 11 invoice is a string that begins with lnbc (for mainnet) and encodes several pieces of information:

• Payment hash: The hash of the secret that the recipient generated. This is what locks the HTLCs along the payment route.
• Amount: The requested payment amount (in millisatoshis). This can be left blank for "any amount" invoices.
• Description: A human-readable note describing what the payment is for (e.g., "Coffee at Acme Cafe").
• Expiry: How long the invoice is valid. The default is 3,600 seconds (one hour), but this is configurable.
• Routing hints: If the recipient's node is not well-connected or uses private channels, the invoice can include hints about how to reach it.
• Node public key: The recipient's Lightning node identity.

The sender's Lightning wallet reads the invoice, finds a route to the recipient, constructs the HTLC chain, and sends the payment. The entire process takes a few seconds at most. Most Lightning wallets handle invoices through QR codes: the recipient displays a QR code, the sender scans it, confirms the amount, and the payment is done.

BOLT 12 and Offers

BOLT 12 is a newer invoice protocol that addresses some limitations of BOLT 11. It introduces "offers," which are reusable payment requests. Unlike BOLT 11 invoices that expire and can only be used once, a BOLT 12 offer is a static identifier that the recipient can publish permanently. When a sender wants to pay, they use the offer to request a fresh invoice directly from the recipient's node over the Lightning Network itself (no separate communication channel needed).

BOLT 12 offers also support recurring payments (subscriptions), refunds, and improved privacy by not revealing the recipient's node identity in the offer string. Blockstream maintains Core Lightning (CLN), one of the major Lightning Network implementations, and CLN has been at the forefront of BOLT 12 development and adoption.

Lightning Network Capacity and Growth

The Lightning Network has grown from an experimental concept to a production payment network used by millions of people worldwide. Several metrics track its health and adoption.

Network Capacity

Total network capacity refers to the total amount of bitcoin locked in public Lightning channels. As of mid-2026, the network holds approximately 4,800 bitcoin in public channels (per mempool.space). This represents only the visible portion; private channels (not announced to the network) add additional capacity that is difficult to measure.

Nodes and Channels

The network consists of approximately 16,000 publicly reachable nodes connected by roughly 39,000 public channels (mempool.space, mid-2026). These numbers fluctuate as nodes come online and go offline, and as channels open and close. Public node and channel counts have declined from their 2022-2023 peaks, a sign of consolidation rather than reduced usage: smaller channels have merged into fewer, larger channels managed by routing nodes and Lightning service providers, and more capacity has shifted into private channels operated by mobile wallets and service providers.

Real Adoption Metrics

Beyond raw capacity, more meaningful adoption signals include:

• Transaction volume: Lightning processes millions of payments per month across wallets, exchanges, and merchant platforms.
• Merchant adoption: Point-of-sale Lightning acceptance has expanded across Latin America, Africa, Southeast Asia, and Europe. El Salvador's 2021 Bitcoin Law, which made bitcoin legal tender alongside the US dollar, accelerated Lightning adoption as a payment method. Legal tender status was repealed in January 2025 as a condition of IMF lending, but merchant adoption and Lightning use continue.
• Exchange integration: Major exchanges now support Lightning deposits and withdrawals, reducing on-chain congestion and lowering withdrawal fees for users.
• Wallet growth: Both custodial and self-custodial Lightning wallets have seen significant user growth, with several wallets surpassing millions of downloads.

Lightning Use Cases

Point-of-Sale Payments

Lightning's settlement in seconds and near-zero fees make it practical for in-person payments. A customer scans a QR code, confirms the amount, and the merchant receives the payment in under three seconds. Lightning also eliminates chargebacks and removes the 2-3% intermediary cut typical of card networks. For merchants in regions with high credit card processing fees or limited banking infrastructure, Lightning offers a direct alternative.

Micropayments

Bitcoin's base layer is not practical for payments under a few dollars because the transaction fee alone could exceed the payment amount. Lightning removes this limitation. Payments of one sat (a fraction of a cent) are economically viable, enabling entirely new payment models:

• Streaming sats: Pay-per-second for content, podcasts, or music. Instead of a monthly subscription, listeners pay a few sats per minute of playback.
• Pay-per-use APIs: Developers pay for each API call rather than committing to a monthly plan.
• Metered services: Pay for exactly what you use, whether that is bandwidth, compute, or storage.

Cross-Border Remittances

Traditional remittance services charge 5-10% in fees and take one to five business days to deliver funds. Lightning remittances settle in seconds for a fraction of a cent. A worker in the United States can send bitcoin to a family member in the Philippines, who converts it to local currency through a Lightning-enabled exchange or app. The total cost is a few sats in routing fees, compared to $10-50 through traditional services on a $500 transfer.

Tipping and Social Media Payments

Lightning powers native tipping on social platforms. Users send small amounts of bitcoin directly to content creators, often integrated into the platform's interface with a single tap. The Nostr protocol, a decentralized social network, uses Lightning as its native payment layer, allowing users to "zap" sats to posts they value.

Machine-to-Machine Payments

Lightning's programmable, instant payments open the door to autonomous economic agents. An electric vehicle could pay a charging station in real time, streaming sats for each kilowatt-hour consumed. An AI agent could pay for compute resources on demand. IoT devices could settle metered usage without human intervention. These use cases require a payment system that operates at machine speed with machine-scale amounts, which Lightning provides.

Lightning Wallets

Using the Lightning Network requires a wallet that supports the protocol. Lightning wallets fall into two categories, each with distinct tradeoffs.

Custodial Lightning Wallets

A custodial Lightning wallet is managed by a third party. The provider runs the Lightning node, manages channels, and holds the user's funds. The user interacts through a simple app interface, scanning QR codes and sending payments without worrying about channel management, liquidity, or node uptime.

Advantages: Easy setup, with no channel management and no need to keep the wallet online continuously. The app experience is familiar.

Tradeoffs: The provider holds your bitcoin. If the provider is compromised, goes offline, or restricts your account, you may lose access to your funds. Custodial wallets reintroduce the trust assumptions that Bitcoin was designed to eliminate.

Self-Custodial Lightning Wallets

A self-custodial Lightning wallet gives you full control of your funds. You hold the keys. You manage (or the wallet abstracts) the channel operations. No third party can freeze or seize your funds, though self-custody makes you responsible for channel backups and node uptime, as covered in the challenges below.

Advantages: Full sovereignty. No counterparty risk. Your bitcoin remains in your control at all times.

Tradeoffs: Requires some channel management (opening channels, maintaining inbound liquidity). Your wallet or node needs to be online to receive payments. Channel backups are critical, and losing them can mean losing funds. Newer wallets have reduced these friction points significantly, but the learning curve is steeper than custodial options.

The Blockstream app supports Lightning payments alongside on-chain Bitcoin and Liquid, letting you send and receive across all three layers from a single self-custodial wallet. For users who want one interface for all of their bitcoin across multiple layers, this eliminates the need to juggle separate apps.

Lightning's Relationship to Other Bitcoin Layers

Lightning is one of several layer-2 solutions built on Bitcoin. Each layer serves a different purpose, and they complement each other rather than competing.

Lightning and Liquid

The Lightning Network and the Liquid Network address different needs in the Bitcoin ecosystem:

Lightning excels at high-frequency, low-value payments where speed is paramount. Liquid excels at larger transactions where privacy is paramount, and it supports capabilities that Lightning does not, such as issuing new assets (stablecoins, security tokens) and Confidential Transactions that hide both amounts and asset types from outside observers.

The two networks connect through cross-layer swaps. The Blockstream app supports Lightning ↔ Liquid swaps, allowing users to move funds between layers based on their immediate needs, all from a single wallet. An instant payment goes over Lightning; a larger, more private transfer swaps to Liquid.

Lightning and the Base Layer

Lightning depends on the Bitcoin base layer rather than replacing it. Every Lightning channel is anchored to a real Bitcoin transaction. The security guarantees of Lightning (the ability to force-close a channel and claim your funds on-chain) derive entirely from Bitcoin's base-layer consensus. If the base layer were compromised, Lightning's security model would fail. This is why Lightning is described as a layer-2 protocol: it sits on top of Bitcoin's base layer and inherits that layer's security.

Lightning for Institutions

Payment Processing for Merchants and Platforms

For merchants, Lightning offers a payment rail with near-zero fees, instant finality, and no chargebacks. A merchant running a Lightning node receives payments directly, without a payment processor taking a cut. For platforms, Lightning enables instant payouts to users, reducing the float and settlement delays that characterize traditional payment systems.

Credit card processing fees range from 1.5% to 3.5% per transaction. Lightning routing fees are typically less than 0.01%. On a $100 transaction, the merchant saves $1.50 to $3.50 in processing fees. At scale, this represents a material improvement to margins, particularly for businesses with thin margins like food service, retail, and digital content. For businesses that want Lightning node capabilities without the operational overhead of running their own server, Blockstream's Greenlight provides cloud-hosted Core Lightning nodes with key management remaining on the operator's own device.

Lightning Network Capacity as an Adoption Metric

Institutional analysts tracking Bitcoin adoption increasingly reference Lightning Network metrics: total capacity, channel count, routing volume, and the number of Lightning-enabled services. Growing Lightning capacity signals increasing real-world Bitcoin usage, not just speculative holding. For institutions evaluating Bitcoin's viability as a payment network (not just a store of value), Lightning metrics are the data to watch.

Lightning vs. Traditional Payment Rails

The distinction between authorization and settlement matters. When you pay with a credit card, the merchant receives an authorization (a promise of payment), not the actual funds. Actual settlement happens days later through a chain of intermediaries. Lightning payments are both authorized and settled in the same instant. The merchant receives bitcoin directly, with no chargeback exposure or settlement window.

Challenges and Limitations

Lightning is a production-ready payment network, but it has real limitations that users and operators should understand.

Channel Management and Liquidity

Effective Lightning usage requires managing channel liquidity. A channel can only route payments up to the available balance on the sending side. If all of Alice's channel balance has shifted to Bob's side, she cannot send more until the balance shifts back (through incoming payments) or she opens a new channel. For merchants receiving many payments, inbound liquidity (the capacity for customers to pay into their channels) is a constant concern.

Liquidity management is an active area of development. Solutions include submarine swaps (exchanging on-chain bitcoin for Lightning balance), liquidity marketplaces, and automated channel management tools. The friction is decreasing, but it has not been eliminated.

Online Requirements

To receive a Lightning payment, your node (or wallet) must be online. Unlike the Bitcoin base layer, where you can receive bitcoin to an address whether you are online or offline, Lightning requires an active connection. For mobile wallets, this means the app must be running (or using a background service) to receive payments. If a node goes offline for an extended period, its channels may be force-closed by counterparties.

Watchtowers mitigate the always-online requirement for Lightning users. A watchtower is a third-party (or self-hosted) service that monitors the blockchain on a user's behalf, detects any breach attempt (a counterparty broadcasting a revoked commitment transaction), and publishes the penalty transaction to reclaim the channel balance. Watchtowers can be bundled with a wallet or delegated to a dedicated service. For users who cannot keep their Lightning node online continuously, a watchtower is the standard solution.

Backup Complexity

Backing up a Lightning wallet is more complex than backing up a Bitcoin base-layer wallet. A recovery phrase alone is not sufficient to recover Lightning channel state. If a node crashes and restores from an outdated backup, it might broadcast an old channel state, triggering the penalty mechanism and losing all funds in that channel. Static Channel Backups (SCBs) mitigate this by letting a restored node ask its channel partners to close the channels (the partner broadcasts its latest commitment transaction, returning the funds on-chain), but the backup process is more involved than base-layer self-custody.

Payment Size Limits

Lightning is optimized for small to medium payments. Sending large amounts (above a few million sats) can be difficult because it requires sufficient liquidity along the entire payment path. Multi-Part Payments (MPP) help by splitting a large payment into smaller pieces that route independently and recombine at the destination, but very large payments may still face routing challenges.

Active Development

The Lightning protocol is under continuous development. Features like splicing (resizing channels without closing them), BOLT 12 offers (reusable invoices), Point Time-Locked Contracts (PTLCs, which improve privacy over HTLCs), and channel factories (allowing many channels to share a single on-chain funding transaction) are in various stages of specification and implementation. The network is functional and widely used today, with significant improvements still ahead.

Frequently Asked Questions

How much does it cost to send a Lightning payment?

Lightning routing fees are typically less than one sat (a fraction of a cent). The exact fee depends on the route taken and the fee policies of intermediate nodes, but even large payments rarely incur fees above a few sats. Each routing node sets a base fee (fixed per payment) and a proportional fee rate (percentage of the amount), both advertised via the BOLT 7 gossip protocol. The sender's wallet calculates the total fee across all hops before sending, so the cost is known upfront. This is orders of magnitude cheaper than credit card processing fees (1.5-3.5%) or international wire transfers ($15-50).

Is Lightning as secure as Bitcoin?

Lightning inherits its security from the Bitcoin base layer. Every channel is backed by a real on-chain transaction, and either party can force-close a channel at any time to settle on-chain. The penalty mechanism discourages cheating. However, Lightning does introduce new considerations: users must keep their wallet or node online, manage backups carefully, and monitor channels. The security model is different from base-layer self-custody but remains rooted in Bitcoin's consensus.

Do I need to run a full Bitcoin node to use Lightning?

Running your own node gives you the highest level of sovereignty and privacy. However, many Lightning wallets connect to third-party nodes on your behalf, so you can use Lightning without running your own infrastructure. The tradeoff is trust: when you use someone else's node, you rely on them for accurate blockchain data. For casual payments, a well-designed wallet is sufficient. For businesses or users who prioritize sovereignty, running your own Lightning node (which includes a Bitcoin full node) is the standard. Services like Blockstream's Greenlight let you run a Core Lightning node in the cloud while keeping your keys on your own device, bridging the gap between full self-hosted infrastructure and third-party dependence.

What happens if my Lightning channel partner goes offline?

If your channel partner goes offline, you can force-close the channel by broadcasting the latest commitment transaction to the Bitcoin blockchain. Your funds are never at risk of being lost because the channel partner disappeared. The force-close triggers a timelock defined by the to_self_delay parameter negotiated during channel opening (per BOLT 2), typically 144 blocks (about one day) to 2,016 blocks (about two weeks). During this delay, the counterparty has time to dispute if the broadcast state is not the latest. After the timelock expires, your bitcoin will be returned to your on-chain wallet.

Can I use Lightning and Liquid together?

Yes. Lightning and Liquid are complementary Bitcoin layers that serve different purposes. You can move funds between them using cross-layer swaps. The Blockstream app supports Lightning ↔ Liquid swaps within a single interface, letting you shift bitcoin between layers depending on whether you need instant payments (Lightning) or privacy and larger transfers (Liquid).

How is the Lightning Network different from other payment networks like Visa?

Lightning settles payments in seconds with true finality. Visa authorizes transactions quickly but settles days later through intermediaries, and transactions can be reversed through chargebacks for months. Lightning operates 24/7/365, is permissionless (no merchant agreements or bank accounts required), and charges fees measured in fractions of a cent rather than percentages of the transaction amount.