Lightning Network and Estate Planning: Channel Balances, Routing Nodes, and the 2026 Guide

How Lightning Channels Work (For Estate Attorneys)

If you already understand on-chain Bitcoin estate planning, Lightning adds an entirely different layer of complexity. Here is the simplified version estate attorneys need.

A Lightning channel is a two-party financial arrangement built on top of Bitcoin. Two participants — call them Alice and Bob — lock bitcoin into a shared on-chain address controlled by a 2-of-2 multisignature arrangement. That on-chain transaction is the "funding transaction." Once confirmed, the channel is open.

From that point forward, Alice and Bob can send bitcoin back and forth between themselves without touching the blockchain. Each payment updates the "channel state" — a signed but unbroadcast Bitcoin transaction that reflects who owns what portion of the locked funds. If Alice funded the channel with 0.5 BTC, she starts with 0.5 BTC of outbound capacity. As she pays Bob, her balance decreases and Bob's increases. The total never changes — it is always 0.5 BTC — but the split shifts with every payment.

The critical insight for estate planning: these intermediate states exist only on the participants' computers. The blockchain knows that 0.5 BTC is locked in a 2-of-2 multisig address. It has no idea how Alice and Bob have divided it between themselves. That information lives in the channel state files on each node.

Inbound and Outbound Capacity

Every channel has two numbers that matter: outbound capacity (what you can send) and inbound capacity (what you can receive). A node operator running a routing node might have 8 BTC spread across 50 channels — but only the channel state data reveals how much of that 8 BTC belongs to the operator versus their channel partners.

An executor looking at the blockchain sees 50 funding transactions. Without the node's channel database, they cannot determine what portion of those funds belongs to the estate. This is the fundamental problem.

The Channel Balance Problem

With on-chain Bitcoin, an executor who has the private keys can see the exact balance on the blockchain. The funds are unambiguous. Self-custody inheritance is already complicated enough — but at least the balances are transparent.

Lightning destroys that transparency.

Consider a decedent who operated a routing node with 8 BTC in total channel capacity. The executor recovers the seed phrase and gains access to the on-chain wallet, which might hold an additional 2 BTC. The executor sees 10 BTC on-chain — the 2 BTC in the hot wallet and the 8 BTC locked in channel funding transactions. But how much of that 8 BTC actually belongs to the estate?

It could be anywhere from 0 to 8 BTC. If the decedent had routed significant volume and most channels had shifted to high inbound capacity, the estate's actual Lightning balance might be 2 BTC across those 50 channels, with the remaining 6 BTC belonging to channel partners. Only the channel state database — stored on the node itself — reveals the true number.

This creates a documentation obligation that does not exist with on-chain holdings. The estate plan must ensure that:

• The executor knows a Lightning node exists
• The executor can access the node (physically or remotely)
• The channel database is preserved and accessible
• The executor understands that channel balances are separate from on-chain balances

Without all four, Lightning bitcoin can become invisible estate assets — wealth that legally belongs to the estate but cannot be recovered because no one knows it exists or how to claim it.

Force-Close Implications at Death

When a Lightning node goes permanently offline — as it will when the operator dies — channel partners will eventually force-close their channels. This is not malicious. It is the protocol working as designed. A channel partner cannot leave their funds locked in a channel with a counterparty that will never come back online.

The Mechanics of Force-Close

A force-close broadcasts the most recent commitment transaction to the blockchain. This returns each party's balance to their respective on-chain addresses. But there are several complications for estate planning:

Timelock delays. The party initiating the force-close faces a timelock — typically 144 to 2,016 blocks (roughly 1 day to 2 weeks). During this period, their funds are locked. The non-initiating party (in this case, the estate) receives their funds immediately. This is actually favorable for the estate, but only if the estate's node was running the most recent channel state.

Outdated commitment transactions. If a channel partner broadcasts an old commitment transaction — one that reflects a higher balance for them than the current state — the estate has a window to broadcast a "penalty transaction" that claims the entire channel balance. But this requires the estate's node to be online and monitoring the blockchain. If the node is offline (because the operator is deceased), the estate cannot execute the penalty. The channel partner gets away with broadcasting the stale state.

This is not a theoretical risk. It is the exact scenario that occurs when a node operator dies without a succession plan. Every channel partner has a financial incentive to broadcast whichever commitment transaction favors them. The protocol relies on both parties being online to enforce honesty. Death removes one party from that equation entirely.

Tax Implications of Force-Close

A force-close creates an on-chain transaction. Under current IRS guidance, this is a taxable event — the channel settlement constitutes a disposition of property. The estate must track the cost basis of the bitcoin that was locked in the channel versus the fair market value at the time of force-close.

If the decedent receives a stepped-up basis at death (under IRC §1014), the force-close occurring after death may result in minimal gain or loss, since the basis resets to fair market value at the date of death. But timing matters: if force-closes occur before the estate is formally opened, the tax treatment becomes ambiguous.

For estates with significant Lightning holdings, the interaction between capital gains rules and channel closures needs careful attention from a tax advisor who understands both Bitcoin and estate law.

Routing Nodes as a Trade or Business

A Lightning routing node that earns fees presents a question the IRS has not directly addressed: is routing fee income a trade or business under IRC §162, or is it passive investment income?

The Case for Trade or Business

A routing node operator who actively manages channels — opening and closing channels, rebalancing liquidity, adjusting fee rates, maintaining uptime — is conducting an activity with regularity and continuity for the primary purpose of generating income. Under the Commissioner v. Groetzinger standard, this likely qualifies as a trade or business.

The implications are significant:

• Ordinary income. Routing fees are ordinary income, not capital gains. They are taxable when received (in sats), valued at fair market value at the time of receipt.
• Business deductions. Node hardware, electricity, internet service, hosting costs, and software subscriptions are deductible under §162. For a serious routing node, these can be meaningful — a dedicated server, UPS backup, and high-availability internet easily run $2,000–$5,000 annually.
• Qualified Business Income. If the routing operation qualifies as a trade or business, routing income may be eligible for the §199A QBI deduction — a 20% deduction on qualified business income for pass-through entities. For a routing node earning 2 million sats per month at $100,000/BTC, that is approximately $24,000 per year in gross income, with a potential $4,800 QBI deduction.
• Self-employment tax. The flip side: if it is a trade or business, routing income is subject to self-employment tax (15.3% up to the Social Security wage base, 2.9% above). This is a real cost that passive income avoids.

Estate Planning Implications

When the node operator dies, the routing business does not automatically terminate. The estate must decide: does the executor continue operating the node (preserving income and channel relationships), or close it down?

If the trustee or executor lacks the technical ability to operate a routing node, the channels will go offline and eventually force-close. The routing income stream ends. If the estate plan contemplated the node as an ongoing business (perhaps in a revocable trust that becomes irrevocable at death), the trustee needs explicit authority — and technical capability — to continue operations.

For estates above the $15 million per person federal exemption (2026), a routing node's capitalized value could be relevant for estate tax purposes. A node earning $24,000 annually might be valued at $120,000–$240,000 using a 5–10x income multiple, depending on the stability and growth trajectory of routing fees.

LSPs and Custodial Lightning Wallets

Not all Lightning usage involves self-custody. The rise of Lightning Service Providers (LSPs) has created a spectrum of custody arrangements that complicate estate planning differently.

Fully Custodial Wallets

Wallets like Wallet of Satoshi hold the user's bitcoin entirely on the provider's infrastructure. The user does not control private keys. From an estate planning perspective, these function like bank accounts — the executor needs the account credentials, and recovery depends on the provider's cooperation. There are no channels to close, no node to maintain, and no channel state to preserve.

The risk is different but real: if the custodial provider goes offline, restricts access, or exits the market, the funds may be unrecoverable. This is counterparty risk, not protocol risk.

Semi-Custodial and Non-Custodial LSPs

Wallets like Phoenix (from ACINQ) operate a hybrid model. The user holds private keys, but ACINQ manages the Lightning channels. Channel state is backed up to ACINQ's servers. If the user's phone is lost, they can recover using their seed phrase plus ACINQ's backup infrastructure.

For estate planning, these wallets occupy a middle ground. The executor needs the seed phrase (self-custody inheritance applies), but channel recovery depends on the LSP remaining operational. If ACINQ shuts down, the user can force-close channels using their seed phrase — but only if they (or the executor) know how.

The estate plan should document: which wallet, which type of custody, where the seed phrase is stored, and what to do if the LSP is no longer available. The procedures for recovering from a Phoenix wallet are materially different from recovering from a Core Lightning routing node. Your multisig estate planning documentation should address Lightning alongside on-chain holdings.

Backup and Recovery: Static Channel Backups

Lightning node implementations (LND, Core Lightning, Eclair) support Static Channel Backups (SCBs). An SCB does not contain the current channel state — it contains enough information to initiate a cooperative or force-close of all channels, recovering the node's balance to an on-chain address.

Why SCBs Matter for Estate Planning

If the node hardware fails or becomes inaccessible, an SCB allows recovery of funds without the original channel database. The executor imports the SCB into a new LND instance, the software contacts each channel partner, and initiates a close. The estate's funds return to on-chain addresses controlled by the seed phrase.

There is a critical limitation: SCBs must be updated after every channel open or close. An outdated SCB may not include channels opened after the backup was created. Those channels' funds could be lost.

Automated Backup Strategies

Best practice for node operators who are serious about estate planning:

• Automated SCB export. Configure the node to automatically copy the SCB file to a secondary location (cloud storage, secondary device, or a USB drive in a safe deposit box) every time a channel is opened or closed.
• Seed phrase separation. The seed phrase and SCB should be stored in different locations. Together, they enable full recovery. Separately, neither is sufficient. This mirrors the key separation principles used in multisig inheritance setups.
• Documentation for the executor. A written procedure — not just the technical artifacts — explaining what the SCB is, where it is stored, and how to use it. Most executors are not Lightning developers.

Trust Provisions for Lightning Operations

Standard revocable trust language does not contemplate Lightning Network operations. A trust that grants the trustee authority over "digital assets" or even "cryptocurrency" may not clearly authorize the specific actions required to manage Lightning channels.

Specific Authority Needed

Trust provisions for a Lightning node operator should explicitly grant the trustee authority to:

• Operate the Lightning node. Continue running the node software, maintaining uptime, and managing the underlying hardware or hosting infrastructure.
• Open and close channels. This involves committing and recovering on-chain bitcoin — the trustee needs clear authority to deploy trust assets into bilateral channel arrangements.
• Rebalance channels. Circular rebalancing and submarine swaps involve moving bitcoin between channels without a net change in holdings, but they do involve transaction fees and counterparty interactions.
• Set and adjust routing fees. This is a business decision that affects income — the trustee needs discretion to manage fee rates.
• Execute force-closes. In adversarial situations (unresponsive channel partners, suspected fraud), the trustee must be able to force-close channels unilaterally.
• Engage technical service providers. Unless the trustee is a Lightning developer, they will need to hire one. The trust should authorize payment for technical management of the node.

Without these provisions, a trustee managing a Lightning node could face fiduciary liability for actions that fall outside their explicit authority — even if those actions are necessary to preserve trust assets.

Successor Node Operator

Consider naming a "Lightning successor" — a technically competent individual who can manage the node during the transition period between the grantor's death and the trustee's full assumption of control. This person does not need to be the trustee; they can serve as a technical advisor with limited, defined authority.

This is analogous to naming a digital executor alongside a traditional executor — a concept that is gaining traction in estate planning for tech-forward families. The comprehensive estate planning guide covers the broader framework for digital asset succession.

Valuation for Estate Tax Purposes

For estates that exceed the $15 million per person federal estate tax exemption in 2026 (or $30 million for a married couple using portability), Lightning holdings must be valued alongside on-chain holdings.

Snapshot Timing

Estate tax valuation uses the fair market value at the date of death (or the alternate valuation date, six months later). For Lightning channel balances, this requires:

1. Determining the channel state at the date of death. This requires access to the node's channel database as of that moment. If the node was online at death, the channel database reflects current balances. If it was offline, the last known state applies.
2. Converting sat balances to USD. Use the BTC/USD price at the date of death (or alternate valuation date). The IRS has not issued specific guidance on which price source to use, but a reasonable approach is the average of high and low prices on a major exchange for the date in question.
3. Aggregating all Lightning balances. The executor must sum the estate's share across all open channels. This is not the total channel capacity — it is only the local balance in each channel.

Ongoing Channel Activity Post-Death

If the node remains online after death (running on automated infrastructure), channel balances will continue to change as payments route through. The valuation date is fixed, but the practical challenge of capturing the exact state at that moment adds complexity. Best practice: take a snapshot of all channel balances immediately upon death, before any post-death routing occurs.

The $19,000 annual gift exclusion (2026) is also relevant for lifetime planning — gifting routing node interests or channel capacity during life can be a tax-efficient transfer strategy, though the mechanics of transferring a channel (versus closing and re-opening) remain technically constrained.

Lightning, Privacy, and Disclosure Obligations

Lightning's onion routing provides meaningful privacy improvements over on-chain Bitcoin. A routing node does not know the origin or final destination of payments — only the immediately preceding and following hops. This makes tracing Lightning payments significantly harder than tracing on-chain transactions. For node operators who value privacy, this is a core feature. For their estates, it is a significant complication.

On-chain Bitcoin is pseudonymous but traceable. Chain analysis firms can follow the flow of funds across addresses with increasing accuracy. Lightning payments, by contrast, leave almost no public trace. A payment routed through five hops is visible only to each individual hop — no single observer sees the complete path. There is no "Lightning blockchain" an executor can search. The network's topology is partially visible through gossip protocol announcements, but private channels — increasingly common — do not appear in the public graph at all.

The Estate Planning Tension

Privacy is a feature for the living. For the deceased, it becomes an obstacle. Estate administration requires full disclosure of assets. The executor has a legal obligation to identify and account for all estate property — including assets the decedent may have kept private during life. Lightning's privacy features can make this difficult in several ways:

• No public ledger of Lightning balances. Unlike on-chain bitcoin, where a known address reveals its balance on the blockchain, Lightning channel balances are private between the two channel parties.
• Routing history may reveal income. A node's routing history (if preserved) shows fees earned — this is taxable income that must be reported on the decedent's final return.
• Channel partners may not cooperate. There is no legal framework compelling a channel partner to disclose the other side's balance. The estate must rely on its own node data.

The practical solution is disclosure during lifetime. The node operator should maintain a current, accurate record of Lightning holdings as part of their asset inventory. This record should be stored with the estate planning documents and updated regularly — ideally automated through node management software that exports balance reports.

The Watchtower Problem

Lightning watchtowers are third-party services that monitor the blockchain for fraudulent channel closures and automatically broadcast penalty transactions on behalf of the channel owner. They exist because not every node can be online 24/7 — and a channel partner who broadcasts an old commitment transaction while the other party is offline can steal funds.

Why This Matters at Death

When a node operator dies, their node will eventually go offline. Without a watchtower, every channel is vulnerable to fraud during the period between death and the executor taking control of the node. A channel partner could broadcast an outdated commitment transaction — one reflecting a higher balance for themselves — and the estate would have no automated defense.

Watchtower services solve this by monitoring on the node owner's behalf. But watchtower arrangements create their own estate planning considerations:

• Continuity of service. Is the watchtower service paid? By subscription? If the subscription lapses after death, monitoring stops.
• Access credentials. The executor needs to know that a watchtower exists, who provides it, and how to maintain the service during estate administration.
• Self-hosted watchtowers. Some operators run their own watchtower on separate infrastructure. The estate plan must account for this additional piece of infrastructure and ensure the executor can access or maintain it.

The economic analysis is straightforward. A watchtower service costs a small fee — typically nominal or even free for basic monitoring. The potential loss from a single fraudulent channel closure could be the entire channel balance. For a node with 8 BTC across 50 channels, even one successful fraud attempt could cost tens of thousands of dollars at current prices. The watchtower is insurance, and like all insurance, it must remain active after the insured event (death) occurs.

For serious node operators, a watchtower arrangement should be treated as essential infrastructure — documented in the estate plan alongside the node itself, with payment provisions that survive the operator's death. The trust should explicitly authorize the trustee to maintain watchtower services and include the watchtower provider's contact information and access credentials in the sealed technical addendum.

Lightning-Native Business Assets

Beyond routing fees, Lightning enables entirely new categories of income and assets that must be addressed in estate planning.

LNURL and Lightning Addresses

A Lightning address (user@domain.com format) is a static endpoint for receiving payments. If the decedent operated a Lightning address — whether for a business, for tipping, or for payment processing — incoming payments will continue to arrive after death. These payments are estate assets. The executor must be able to access the underlying infrastructure and either continue receiving payments (if the address serves a business) or redirect/disable it.

Nostr Zaps

Nostr, the decentralized social protocol, integrates Lightning payments ("zaps") as native tipping. A content creator who earns zaps has Lightning income that flows to a wallet associated with their Nostr identity. The estate must account for: the Nostr private key (which controls the identity), the linked Lightning wallet, and any pending or future zap income.

Point of Sale and E-Commerce

Businesses accepting Lightning payments via BTCPay Server, LNbits, or similar infrastructure have Lightning funds flowing into channels or custodial wallets continuously. These are business assets with the same estate treatment as any other business revenue — but the technical recovery path is different from recovering a bank account.

Every Lightning-native income stream should be documented in the estate plan with the same rigor as traditional income sources: what it is, where the funds flow, how to access the underlying system, and who to contact for technical support.

Case Study: The Nakamoto Node Operator

To illustrate how these issues converge, consider a composite client profile.

The Setup

Satoshi Nakamoto (obviously a pseudonym) operates a serious Lightning routing node. The numbers:

• 50 open channels with a total capacity of 8 BTC
• Approximately 5.2 BTC of that capacity belongs to Satoshi (local balance)
• Routing fees: approximately 2 million sats per month (~$2,000/month at $100,000/BTC)
• On-chain wallet: 12 BTC in cold storage (multisig)
• Phoenix wallet: 0.15 BTC for personal spending
• Nostr account earning zaps: ~100,000 sats/month
• Total estimated holdings: ~17.35 BTC (~$1,735,000)

Satoshi is married, has two children, and lives in a state with no state estate tax. The federal estate is well below the $15 million per person exemption (or $30 million with spousal portability), so federal estate tax is not the primary concern. The primary concern is operational continuity and asset recovery.

The Plan

Layer 1: On-chain holdings. The 12 BTC in cold storage is held in a 2-of-3 multisig arrangement. Keys are distributed per the multisig inheritance framework — one key with the spouse, one in a safety deposit box, one with the estate attorney. The seed phrases and key locations are documented in the trust.

Layer 2: Lightning node. The routing node runs on a dedicated server with UPS backup. The trust provisions explicitly authorize the trustee (Satoshi's spouse) to:

• Continue operating the routing node for up to 12 months after death
• Close channels at the trustee's discretion
• Engage a Lightning technical advisor (identified by name in a sealed addendum)
• Pay for continued hosting, watchtower services, and technical support from trust assets

A technical successor — a trusted friend who also operates a Lightning node — is named as the "Lightning Operations Advisor" with authority to access the node infrastructure, take channel state snapshots, and execute orderly channel closures if the spouse elects not to continue operations.

Layer 3: SCB and recovery. Automated static channel backups are replicated to an encrypted cloud storage account and a USB drive in the safety deposit box. The seed phrase for the Lightning node is stored separately from the SCBs, following the same separation-of-concerns principle as the multisig keys.

Layer 4: LSP wallets. The Phoenix wallet seed phrase is stored with the estate documents. A note explains that recovery requires installing Phoenix, importing the seed phrase, and waiting for ACINQ's servers to restore the channel state. If ACINQ is no longer available, the note explains how to force-close using the seed phrase directly.

Layer 5: Income streams. The Nostr private key is documented (encrypted, stored with the attorney). Instructions explain how to access the linked Lightning wallet and either continue the Nostr identity or disable it. Routing fee income for the current tax year is tracked via automated exports and included in the final tax return.

Layer 6: Watchtower. Satoshi runs a self-hosted watchtower on a separate VPS. The VPS credentials are included in the sealed technical addendum. The watchtower subscription (a third-party backup) is paid annually; the trust provisions authorize continued payment.

What Happens at Death

1. The Lightning Operations Advisor is notified immediately and takes a snapshot of all channel states.
2. The watchtower continues monitoring for fraudulent closes.
3. The spouse (as trustee) decides within 30 days whether to continue node operations or begin orderly wind-down.
4. If winding down: channels are cooperatively closed over 2–4 weeks, funds return to on-chain addresses controlled by the trust.
5. If continuing: the technical advisor manages the node under the trustee's direction, routing fees flow to the trust.
6. The estate attorney files the final tax return including routing fee income through the date of death.
7. The stepped-up basis under IRC §1014 applies to all bitcoin holdings (on-chain and Lightning) at the date of death value.

Building Your Lightning Estate Plan

If you operate a Lightning node or hold meaningful funds in Lightning channels, your estate plan is incomplete without addressing these issues. The summary framework:

1. Inventory all Lightning assets. Channel balances, routing fee income, Lightning addresses, Nostr zaps, custodial wallet balances.
2. Document the technical recovery path. Seed phrases, SCBs, node access credentials, watchtower arrangements — all stored securely with separation of concerns.
3. Draft Lightning-specific trust provisions. Trustee authority to operate nodes, close channels, rebalance, engage technical advisors, and pay for infrastructure.
4. Name a technical successor. Someone who understands Lightning and can act quickly after death to preserve channel states and prevent fraudulent closures.
5. Address tax implications. Routing income is ordinary income, force-closes are taxable events, and the stepped-up basis at death applies to channel balances.
6. Update regularly. Channel configurations change constantly. SCBs must be current. The estate plan should be reviewed whenever significant changes occur to the node's channel structure.

Lightning is Bitcoin's scaling layer. As adoption grows, more wealth will reside in channels rather than on-chain. The estate planning frameworks that work for on-chain Bitcoin — comprehensive as they are — do not capture the bilateral, ephemeral, and technically demanding nature of Lightning. Building a plan that does is not optional for node operators. It is a fiduciary necessity.