Lightning Network

Bitcoin's base layer is great for security but bad for small payments. Each transaction confirms in roughly 10 minutes (often longer, sometimes much longer during congestion). Each transaction has a network fee, which during congestion can be €5-50. Paying €30 for a hosting service plus €15 in fees and waiting an hour for confirmation isn't a good user experience.

Lightning solves this by moving most transactions off the blockchain. Two parties open a payment channel by jointly signing a Bitcoin transaction. They can then exchange thousands of payments instantly between themselves without touching the blockchain. When they're done, they close the channel by broadcasting a final settlement transaction.

The clever part: Lightning channels can be chained. Pay through a route of multiple channels, no party in the route can steal funds, and settlement happens atomically across all channels. This is what makes Lightning a network rather than just a bilateral payment channel.

Practical workflow when you pay a Lightning invoice:

1. Recipient creates an invoice. A long alphanumeric string encoding amount, recipient, expiry, and a payment hash. Standard format BOLT-11.
2. You scan the invoice with a Lightning wallet. Wallet decodes it and finds a route through the Lightning network from your channels to the recipient.
3. Payment broadcasts through the route. Each hop forwards the payment, taking a tiny fee. Routing happens in milliseconds.
4. Recipient reveals the payment preimage. Cryptographic proof of payment receipt, broadcast back through the route.
5. Each hop settles its forwarded payment. The whole route resolves atomically: either the entire payment succeeds or none of it does.

From the user's view: scan QR, click pay, payment confirms instantly. Total time typically under 2 seconds. Fees usually €0.01-0.10 for small payments, €0.50-2 for larger ones (€500+ payments).

Honest comparison:

Use Lightning for:

• Recurring small payments (monthly hosting bills, VPN subscriptions, software licences)
• Tipping or microtransactions
• Any payment where instant settlement matters more than maximum security
• Payments under ~€500 where on-chain fees would be disproportionate

Use on-chain Bitcoin for:

• Large one-time payments (€1000+)
• Payments where settlement finality matters more than speed
• Payments to recipients without Lightning capability
• Long-term store of value, not transactional use

For hosting customers paying monthly bills under €100, Lightning is genuinely the better experience. Faster confirmation, lower fees, less awkward exchange-rate management at the borders.

Lightning wallets fall into two categories with very different trade-offs.

Custodial wallets. Wallet provider holds your funds. Easier to use, no channel management, can pay or receive immediately. Trade-off: provider can freeze your funds, lose them, or be compelled to surrender data. Examples: Wallet of Satoshi, Strike, Bitnob.

Non-custodial wallets. You control your private keys. Wallet manages channels with the network. More technically demanding (channels need liquidity, sometimes need to be rebalanced or closed) but no third-party custody. Examples: Phoenix, Breez, Zeus, Mutiny.

For occasional small payments, custodial wallets are pragmatic. For larger or recurring use, non-custodial preserves the underlying value of using cryptocurrency in the first place.

If you run hosting and want to accept Lightning, options:

• BTCPay Server. Self-hosted, open source, full Lightning node integration. Requires running a full Bitcoin and Lightning node, which means real operational work but maximum sovereignty. Used by ProtonMail, Mullvad, many others.
• Strike API. Custodial Lightning gateway. Simpler integration, you don't run a node, fees are reasonable. Trade-off: you depend on Strike not closing your account.
• OpenNode / IBEX Mercury / similar gateways. Custodial Lightning payment processors. Convert Lightning payments to fiat or to Bitcoin in your custody. Convenient, but custodial dependency.

The right choice depends on volume. Below 100 Lightning payments per month, gateway services cost less than running your own node. Above that, self-hosted BTCPay Server is cheaper and more sovereign.

Lightning isn't magic. Real limitations:

• Routing failures. Sometimes payments fail because the network doesn't find a viable route. Wallets retry automatically, but persistent failures happen for routes through congested or low-liquidity parts of the network.
• Liquidity is asymmetric. Channels have inbound and outbound capacity, separate. A channel mostly used for sending can't receive much. Operators with channels have to manage liquidity actively.
• Privacy is better than on-chain but not perfect. Lightning routing is opaque to outside observers, but the path you take through the network is visible to the nodes you route through.
• Channel closes can be slow and expensive. Cooperative closes are fast and cheap. Non-cooperative closes (when one party goes offline or behaves badly) require on-chain transactions and time-locked settlements that can take days.
• Lightning amounts are limited. Single-payment Lightning routes typically max out around €5K-50K depending on network liquidity. Larger payments need multiple hops or on-chain settlement.

Lightning Network adoption through 2024-2026 has continued to grow steadily across the dimensions that matter for hosting and email infrastructure payments. Total channel capacity crossed 5,000 BTC in mid-2024 and has continued growing through 2026. Active node count surpassed 16,000 in early 2026. The number of merchants accepting Lightning has grown by approximately 80% year-over-year for two consecutive years.

For hosting providers and email infrastructure operators specifically, Lightning has settled into a clear operational niche: invoices below 100 EUR equivalent are economically optimal on Lightning because the fee structure produces effectively rounding-error payments, while invoices above that range can settle through either Lightning or on-chain Bitcoin depending on channel capacity and operational preferences. The 100 EUR threshold reflects current operating costs and is conservative; many operators routinely settle 500 EUR or larger invoices through Lightning without operational issues.

The user experience has improved substantially through 2024-2026. Modern Lightning wallets (Phoenix, Breez, Wallet of Satoshi, Mutiny, and self-custodial alternatives like Zeus paired with self-hosted nodes) handle channel management transparently, abstract away the underlying complexity, and produce a payment experience comparable to other instant-payment systems. The technical barrier to adoption that characterised Lightning in 2020-2022 has substantially diminished.

The reliability has also improved. Routing success rates on the public Lightning Network now consistently exceed 95% for payments under 1M sats (approximately 600 EUR at current rates), with most failed payments succeeding on retry within seconds. The early-era complaint that Lightning payments routinely failed has largely been resolved through improved routing algorithms, larger average channel sizes, and node operator behaviour changes that prioritise routing reliability over fee extraction.

The choice between Lightning and on-chain Bitcoin for a specific payment depends on three factors: the payment amount, the urgency of confirmation, and the privacy posture required. The decision framework below captures the patterns we see customers settle on after running both for several months.

Lightning is the clear correct choice when: the invoice is under 100 EUR (fee economics overwhelmingly favour Lightning), the customer needs near-instant settlement for service activation (Lightning settles in seconds versus 10-60 minutes for on-chain confirmations), the customer values privacy and is paying from a source without strong on-chain history (Lightning provides effective unlinkability that on-chain Bitcoin does not), or the customer is paying multiple small invoices in close succession (Lightning batches efficiently while on-chain produces separate fee events).

On-chain Bitcoin is the clear correct choice when: the invoice exceeds the channel capacity available between the customer wallet and the providers Lightning node (typically 5K-10K EUR equivalent on most public channels), the customer is operating from cold storage that does not connect to Lightning (most cold-storage solutions are on-chain only), the customer needs the payment to appear on the public blockchain for documentation or audit purposes, or the customer prefers the operational simplicity of on-chain payments for occasional infrequent transactions.

Either works equally well when: the invoice is in the 100-1000 EUR range with normal urgency and no specific privacy or operational requirement that favours one over the other. Most customers in this range pick based on which wallet they happen to have at the moment of payment.

For invoices that fall outside the Lightning channel capacity but where Lightning settlement properties are desirable, payment splitting works in many cases: a single large payment broken into 3-10 smaller Lightning payments that each route successfully through available channels. The splitting is invisible to the recipient and produces aggregate settlement properties similar to on-chain payment with better individual-payment privacy.

Hosting providers accepting Lightning generally run self-hosted Lightning nodes rather than using custodial services. The structural reasoning is that custodial Lightning services (third-party node operators that handle Lightning on behalf of the merchant) reintroduce the third-party processor problem that motivated cryptocurrency acceptance in the first place. Self-hosted operation eliminates this dependency at the cost of operational complexity.

The reference architecture: an LND (Lightning Network Daemon) instance paired with a Bitcoin Core full node, deployed on dedicated infrastructure separated from the customer-facing site. The LND instance manages channels with peer nodes across the public Lightning Network and exposes payment-creation and settlement APIs to the BTCPay Server (or equivalent) that handles customer-facing invoice flow.

Channel capacity planning matters substantially. Inbound capacity (the ability to receive payments) is the constraint most operators discover after deployment because new Lightning nodes start with zero inbound capacity by default. The remediation is opening channels with high-volume routing nodes, or contracting with channel-liquidity services that lease inbound capacity for a fee. Operators with significant invoice volume should plan for 20-50K USD equivalent of inbound capacity at typical operating levels, scaling up as volume grows.

Operational maintenance involves monitoring channel health (inactive channels close eventually and need replacement), responding to peer channel close events (sometimes prompted by peer node outages, sometimes by intentional rebalancing), and managing channel rebalancing when liquidity drifts from inbound to outbound or vice versa. Several operational tools exist for automated channel management (Lightning Terminal, Charge-LND, Balance of Satoshis) and most production operators use one of these rather than managing channels manually.

The total operational cost of self-hosted Lightning is meaningful but not prohibitive. Most hosting providers report 5-15 hours monthly of Lightning-specific operational work, plus the infrastructure cost of running the node (typically 50-100 USD monthly for the dedicated hardware), plus the opportunity cost of capital locked in channels (typically 5-15K USD for a working node). The total cost is justified for any provider whose Lightning invoice volume exceeds approximately 10K USD monthly, and most providers in this space pass that threshold quickly once they enable Lightning acceptance.

Most Lightning payments succeed on first attempt. Among the small percentage that fail, the failure modes cluster into specific categories that operators recognise and handle through standard procedures.

Routing failure for amounts exceeding channel capacity: the payment cannot find a path of channels with sufficient capacity to relay the requested amount. The wallet typically reports "no route found" or similar. Customer-side resolution is to retry with a smaller amount (the wallet may suggest splitting), open a direct channel to the recipient, or fall back to on-chain Bitcoin for the specific payment.

Timeout during routing: the payment found a route but one of the intermediate nodes failed to forward within the timeout window. The wallet typically reports "payment timeout" after the configured wait. Customer-side resolution is to retry the payment; most wallets retry automatically and most timeouts succeed on retry within seconds.

Stale invoice: the customer attempts to pay an invoice that has already expired (Lightning invoices typically expire in 1-24 hours from generation). The wallet reports "invoice expired" or similar. Customer-side resolution is to request a new invoice from the merchant; the merchant-side workflow should automatically generate new invoices on request without requiring re-entry of payment details.

Wallet desync: the wallet has not received recent channel updates and reports incorrect balance or channel status. Customer-side resolution is typically to wait briefly (channels resync within minutes in most cases) or to reconnect the wallet to its backing service. Self-hosted wallet users may need to restart the wallet node; custodial wallet users rarely encounter this issue.

Recipient node offline: the recipient node is unreachable, either because the node is down or because the channel path to the node has been disrupted. The wallet reports failure with various error codes depending on where in the routing chain the failure surfaced. Customer-side resolution is typically to wait and retry, or to contact the merchant through other channels to verify their Lightning node status. Production merchants should monitor their Lightning node availability through external probes and alert on extended outages.