Lightning Network

Rejected venues wait the longest for re-review; a rejection has to earn another look before the scheduled date.

REJECTED. Lightning is valuable Bitcoin payment infrastructure, but public channel capacity is not a passive investable protocol position. Earning routing or lease fees requires operating a hot, continuously available node, choosing peers, balancing inbound and outbound liquidity, managing backups, and monitoring for revoked-state broadcasts. That operating business is unsuitable for a standard advisory diversification sleeve even though the underlying settlement asset and base chain are approved.

Kill criteria: the events that revoke this verdict
• A separate sophisticated mandate authorizes Lightning routing as an operating business with node, key, peer, liquidity, and loss limits
• A named wallet or Lightning service passes a custodian/provider review for transactional use
• A proposed-size cooperative and unilateral close test completes within the documented fee and time limits
• Any lost channel state, missed breach remedy, or unrecoverable node-key event opens an immediate review

The research file

Mechanism and client claim

Two peers lock Bitcoin in a 2-of-2 payment channel and exchange signed commitment transactions that update their balance without publishing every payment on chain. Multi-hop payments use hashed timelock contracts so intermediate routing nodes forward value atomically. A routing node earns small fees only when its directed channel liquidity sits on a useful path; capital on the wrong side of a channel cannot forward the desired payment. The DefiLlama worklist value reflects network channel capacity, not deposits in a fungible fund whose pro-rata shares and yield an advisor can purchase.

Control, governance, and legal perimeter

Lightning has no global administrator or token governance, which is a strong sovereignty property. Control instead moves to the node operator: software and key management, peer and channel selection, fee policy, liquidity rebalancing, uptime, watchtower configuration, and force-close response. Implementations and nodes are heterogeneous, while a client using a custodial Lightning service replaces those operating duties with a named provider claim. An RIA cannot call an unmanaged hot node self-custody without documenting who operates it and how keys, backups, monitoring, upgrades, and incident response work.

Incident and operating record

The protocol deliberately handles a dishonest peer through revocation and penalty transactions, but protection is time-sensitive. Lightning Labs documents that a node or watchtower must monitor blocks within the CSV arbitration window; a 144-block example is about 24 hours. The network and implementations have matured, and no single protocol-wide loss event governs this decision. The relevant record is operational: payment failures, force closes, channel database loss, fee spikes, routing imbalance and watchtower failure can impair a particular operator even while the broader network remains live.

Exit, liquidity, and failure path

Cooperative close requires the peer; unilateral close publishes the latest commitment and waits through the configured timelock before the initiating side can spend. A force close can add on-chain fees and delay, and a stale-state breach must be contested before its CSV window expires. Channel capacity is directional, so aggregate public capacity says little about a particular node’s ability to send, receive, rebalance, or close at a desired moment. Private channels are omitted from public measurements, further separating a network statistic from client-specific executable liquidity.

Comparison and decision

Native on-chain BTC provides the same base asset without hot-node operations and is the correct portfolio holding. A client who needs frequent low-value payments may use Lightning as a transactional rail through a separately reviewed wallet or provider; that is an operational service decision, not a yield allocation. Professional routing can be a business strategy for a sophisticated mandate, but it needs uptime, peer, liquidity, cyber, accounting, and loss controls comparable to running infrastructure. Reopen only under that explicit mandate.

Sources

The claims above trace to these. Where a number could not be independently verified, the thesis says so.

• Lightning Labs Builder Guide — opening channels · primary · accessed 2026-08-19
  Supports: 2-of-2 channels, channel capacity, node connectivity
• Lightning Labs Builder Guide — channel liquidity · primary · accessed 2026-08-19
  Supports: directional liquidity, rebalancing, liquidity leases
• Lightning Labs Builder Guide — watchtowers · primary · accessed 2026-08-19
  Supports: revoked states, CSV delay, monitoring duty
• Lightning BOLTs — protocol specifications · primary · accessed 2026-08-19
  Supports: HTLCs, commitment transactions, routing protocol
• Bitcoin Optech — Lightning Network topic · secondary · accessed 2026-08-19
  Supports: protocol record, implementation changes, security topics
• DefiLlama — Lightning Network protocol data · secondary · accessed 2026-08-19
  Supports: protocol category, chain perimeter, current TVL

Inherited controls

The verdict above grades the protocol layer. Every position also inherits the asset it holds and the chain it settles on. The least safe layer sets the position’s grade, and the position table names which one that is.