Lightning Node
Software that opens and maintains Lightning channels, sends and receives off-chain payments, and forwards payments for others.
A Lightning node is a piece of software that participates in the Lightning Network. It manages your payment channels, tracks the network gossip graph, routes payments through itself when asked, and lets you send and receive instant off-chain payments.
The major implementations as of October 2026:
- LND (Lightning Labs) - written in Go, widely used in node-in-a-box products like Umbrel, Start9, MyNode.
- Core Lightning (Blockstream, formerly c-lightning) - written in C, modular plugin architecture, lightweight.
- Eclair (ACINQ) - written in Scala. Phoenix, ACINQ's mobile wallet, is built on lightning-kmp, a separate implementation from the same company, rather than on eclair.
- LDK (Lightning Dev Kit, Spiral) - a library you embed into your own application rather than a standalone daemon. Used by Cash App, Bitkit, Alby Hub and others.
What running a Lightning node costs you operationally:
- Uptime. A node must be online to send, receive, and watch for fraud attempts. If a peer broadcasts an old state and you stay offline past the channel's dispute window, you can lose funds. By default LND scales that window with channel size, from 144 blocks (about a day) for small channels to 2,016 blocks (about two weeks) for large ones. Payments forwarded through your node have shorter deadlines, often a matter of hours, and a routing node that is offline when one comes due can lose that payment.
- On-chain capital. Channels are funded by on-chain Bitcoin. Opening a channel locks up that BTC until you close the channel. Where both nodes support splicing, which was added to the spec in March 2026, you can also take some of it back out without closing.
- Active liquidity management. Inbound liquidity (your counterparties having balance on their side of your channels) doesn't appear by default and often has to be purchased or earned via routing.
- Watching for fraud. If a channel counterparty broadcasts an old state, you have a fixed window to penalize them. Watchtower services exist for this.
What you might earn: small routing fees when your node forwards payments along a multi-hop route. In practice these are tiny per-payment but accumulate if you run a well-connected node. Most home Lightning operators don't earn meaningful revenue; commercial routing nodes are a different category.
You can use Lightning without setting up and managing a node yourself. A custodial Lightning wallet leaves the node and the funds with a company. Some self-custodial mobile wallets keep the keys on your phone and run a small node there for you, leaning on a service provider for channels and liquidity. Running a node you manage yourself is the sovereign answer and is well worth doing for users who care about that property. See Lightning Network for the protocol view.
Key takeaways
- Interfaces with the LN to send, receive, and route off-chain payments
- Maintains state of channel balances and network topology
- May generate routing fee revenue for connected node operators
Corrected
-
Was: The entry said eclair powers the Phoenix mobile wallet, listed Phoenix among custodial wallets, and named Mutiny (shut down in 2024) and Mercury Layer as LDK users, though LDK's own case studies list neither. It also said only weeks of downtime start to cause problems.
Now: Phoenix is a self-custodial wallet built on lightning-kmp, a separate ACINQ implementation, and LDK's case studies list users such as Cash App, Bitkit and Alby Hub. If a peer broadcasts an old channel state, a node offline past the channel's dispute window can lose funds. LND sets that window by default at about a day to two weeks, depending on channel size, and payments forwarded through a node have shorter deadlines, often a matter of hours. Details
Sources (8)
- BOLT #2 - The open_channel message (to_self_delay)
- LND source - funding/manager.go (MinBtcRemoteDelay 144, MaxBtcRemoteDelay 2016)
- LND source - server.go (remote CSV delay scales with channel size)
- BOLT #2 - cltv_expiry_delta selection (deadlines for forwarded payments)
- BOLTs PR #1160 - Channel splicing (merged March 2026)
- Core Lightning README - C implementation maintained by Blockstream
- ACINQ Phoenix README - self-custodial wallet built on lightning-kmp
- Lightning Dev Kit - case studies (projects building with LDK)
Related terms (21)
- Autopilot (Lightning)
- BOLT
- BOLT 11
- Core Lightning (c-lightning)
- Custodial Lightning Wallet
- Delayed Payment Channel
- Escrowed Lightning Channel
- Fraudulent Channel Close
- Gossip Protocol (Lightning)
- Lightning Channel
- Lightning Channel Capacity
- Lightning Channel Splicing
- Lightning Network
- Lightning Network Daemon (lnd)
- Lightning Probe
- Lightning Refund Invoice
- Lightning Routing
- Lightning Sphinx
- Onion Routing (Lightning)
- Tor Hidden Service
- Wumbo Channels (Lightning)
Published . Revised . One correction logged for this page.
Edit this page on GitHub