Lightning Autopilot Strategies Compared

Automated Channel Management Overview

Running a Lightning node requires ongoing channel management: selecting peers, allocating capital, setting fees, rebalancing depleted channels, and acquiring inbound liquidity. Autopilot tools attempt to automate some or all of these tasks, but they vary widely in scope, sophistication, and trust assumptions.

The following table summarizes the major approaches to automated channel management across Lightning implementations, third-party tools, and LSP-based solutions.

For a deeper look at how Lightning implementations differ beyond autopilot, see our Lightning node comparison tool.

LND Autopilot

LND's built-in autopilot is the oldest automated channel opener in the Lightning ecosystem. It uses a constrained preferential attachment heuristic by default: nodes that already have many channels are more likely to be selected as peers, following a power-law distribution. The attachment is non-linear, meaning it favors high-degree nodes less aggressively than a pure preferential model would.

Configuration lives in lnd.conf under the [autopilot] section. Key parameters include autopilot.allocation (the fraction of wallet funds to commit to channels, between 0.0 and 1.0), autopilot.minchansize and autopilot.maxchansize (channel size bounds in satoshis), and autopilot.maxchannels (maximum number of channels to open). Multiple heuristics can be combined using WeightedCombAttachment, where the sub-heuristic weights must sum to exactly 1.0.

The main limitation is scope: LND autopilot only handles channel opening. It does not rebalance existing channels, manage routing fees, or acquire inbound liquidity. Operators who enable it typically pair it with charge-lnd for fee management and bos or Loop for rebalancing.

Lightning Terminal: AutoOpen and AutoFees

Lightning Terminal (litd) from Lightning Labs provides AutoOpen and AutoFees as a more modern alternative to LND's raw autopilot. AutoOpen uses betweenness centrality rather than preferential attachment for peer selection, targeting nodes that serve as critical routing bridges in the network graph.

Operators configure AutoOpen through the Lightning Terminal UI by setting a budget (total on-chain sats to spend), minimum and maximum channel sizes, and optionally specifying preferred peer public keys. A time preference slider controls fee sensitivity: AutoOpen can batch multiple channel opens into a single on-chain transaction to reduce costs when set to wait for low-fee periods. AutoOpen does not close channels.

AutoFees, the companion feature, applies a single set of fee parameters across all channels. While simpler than charge-lnd's per-channel policies, it integrates directly into the Lightning Terminal interface without requiring a separate daemon or cron job.

Privacy note: Enabling AutoOpen shares your node's public key and current channel graph with the Autopilot server operated by Lightning Labs.

CLBOSS: Full Automation for Core Lightning

CLBOSS is the most comprehensive single-tool automation solution available for any Lightning implementation. It handles channel opening, peer selection, rebalancing, fee management, and inbound liquidity acquisition as a Core Lightning plugin.

Peer selection in CLBOSS works by probing candidate nodes for uptime and connectivity. In recent versions (v0.17.0+), channel-open candidates are ranked by their earnings track record: peers that have generated routing revenue are prioritized, unknowns come next, and underperformers are ranked last. Among unknown peers, CLBOSS prefers nodes that advertise splicing support. Channels are opened when on-chain fees are low, and multiple opens can be batched via CLN's multifundchannel RPC.

Rebalancing in v0.17.0 uses a new engine called xrebalance, built on CLN's askrene min-cost-flow router. Each rebalance is planned based on the involved peers' actual earnings, and the fee budget is derived from those earnings rather than a fixed amount. Earlier versions used built-in circular rebalancers and just-in-time rebalancing, but JIT rebalancing was removed because holding an incoming HTLC during a rebalance attempt delays the entire payment path.

CLBOSS also acquires inbound liquidity through Boltz submarine swaps and sets forwarding fees automatically based on channel performance.

Third-Party LND Tools

charge-lnd

charge-lnd is a policy-based fee manager for LND. It runs as a one-shot command (typically scheduled via cron every 1 to 2 hours) and applies fee strategies based on matching criteria. Each policy section in the config file pairs channel selectors (minimum capacity, specific peer public keys, channel age) with a fee strategy. Strategies include static (fixed base fee and ppm), proportional (fees based on channel balance ratio), cost (recover channel open costs over time), and onchain_fee (reference on-chain fee rates). Policies are evaluated top to bottom, with the first match applied. A [default] section catches any channel that no other policy matches.

With LND 0.18+, charge-lnd added experimental support for inbound fees, allowing operators to set pricing for receiving payments through their channels.

Balance of Satoshis (bos)

bos is an open-source CLI tool for LND that provides circular rebalancing, balanced channel opens, batch channel opens, and per-peer fee adjustments. Its circular rebalance command routes a self-payment from an outbound-heavy channel to an inbound-heavy one, restoring optimal balance for routing. Operators can automate bos commands through cron jobs or Telegram bot integrations. bos is distributed as an npm package and works exclusively with LND.

Lightning Loop and AutoLoop

Lightning Loop is Lightning Labs' non-custodial service for moving bitcoin between on-chain and Lightning using submarine swaps. Loop Out sends a Lightning payment to an on-chain address (draining a channel to gain inbound capacity), while Loop In sends on-chain bitcoin into a channel (replenishing outbound capacity).

AutoLoop is the automation layer on top of Loop. Operators define rules specifying minimum and maximum channel balance thresholds, fee budgets, swap size limits, and which channels to manage. When a channel balance falls outside the target range, AutoLoop triggers a swap automatically. Loop optimizes costs through opportunistic transaction batching on the on-chain side. AutoLoop integrates with Lightning Terminal's UI for visual configuration.

Amboss Magma: Liquidity Marketplace

Amboss Magma takes a different approach: instead of algorithmic peer selection, it provides a peer-to-peer marketplace where node operators buy and sell channel capacity. Buyers request inbound liquidity at a specific size and duration. Sellers list their available capacity with pricing. Settlement uses HODL invoices: the seller only receives payment once the agreed-upon channel is confirmed on-chain, and if the seller fails to open the channel, the buyer's payment is refunded.

Pricing on Magma varies by channel size: channels below 1 million satoshis tend to cost disproportionately more per satoshi than larger channels. Amboss also offers liquidity subscription plans that periodically replenish capacity as channels deplete, reducing ongoing manual intervention.

For a broader comparison of liquidity acquisition methods, see our analysis of inbound liquidity acquisition costs.

LSP-Based Channel Management

Lightning Service Providers ( LSPs) abstract away channel management entirely for end users, particularly in mobile wallets. The LSP opens channels on the user's behalf, manages liquidity, and handles routing. The user interacts only with a send/receive interface.

The LSPS specifications (now formalized as bLIPs in the lightning/blips repository) standardize how wallets request channels and just-in-time liquidity. LSPS2 (bLIP-52) defines the JIT channel protocol: when a user needs to receive a payment larger than their current inbound capacity, the LSP opens a zero-conf channel on the fly. This is supported by LND, LDK, and Eclair implementations. The lightning-liquidity crate provides LSPS2 support for LDK-based wallets, allowing them to connect to any LSPS2-compliant provider.

The tradeoff is trust and cost. The JIT channel flow is non-atomic: the user pays the LSP fee first, and the LSP opens the channel afterward. If the LSP fails to deliver, the user must dispute through whatever mechanism the provider offers. LSP fees typically include a channel opening cost plus ongoing routing margins.

Decision Matrix: Which Strategy Fits Your Profile

The right automation strategy depends on your node's purpose, technical comfort level, and willingness to trust third parties.

How Spark Eliminates Channel Management

All of the tools above exist because Lightning's payment channel model creates inherent operational complexity: capacity is locked per channel, inbound liquidity must be separately acquired, and depleted channels require rebalancing or closing. Spark takes a fundamentally different approach as a Bitcoin L2 by removing channels entirely.

Instead of routing payments through a network of funded channels, Spark transfers UTXO ownership by rotating signing keys between the sender, receiver, and a set of operators using Schnorr-based FROST threshold signatures. There is no channel capacity limit, no inbound liquidity requirement, and no need for rebalancing or fee optimization. Users retain the ability to exit to Bitcoin L1 unilaterally without operator cooperation.

For a detailed architectural comparison, see our research on the Bitcoin second-layer scaling landscape.

Frequently Asked Questions

What is Lightning autopilot and how does it work?

Lightning autopilot is a feature in LND that automatically opens payment channels based on graph analysis heuristics. By default, it uses constrained preferential attachment, which favors connecting to well-connected nodes following a power-law distribution. Operators configure the percentage of wallet funds to allocate, channel size bounds, and maximum channel count. Autopilot only handles channel opening: it does not manage fees, rebalance channels, or close underperforming connections.

Should I use LND autopilot or Lightning Terminal AutoOpen?

AutoOpen in Lightning Terminal is generally the better choice for new node operators. It uses betweenness centrality for peer selection (which targets structurally important routing nodes rather than just popular ones), supports budget limits, and can batch channel opens to save on on-chain fees. LND's built-in autopilot is simpler to configure but uses an older heuristic and lacks budget controls.

What is CLBOSS and does it replace LND autopilot?

CLBOSS is a Core Lightning plugin that provides comprehensive automated node management: channel opening, peer selection based on earnings history, circular rebalancing via the xrebalance engine, automatic fee adjustment, and inbound liquidity acquisition through submarine swaps. It is not compatible with LND. CLN operators typically use CLBOSS as their sole automation tool, while LND operators combine multiple specialized tools (autopilot or AutoOpen, charge-lnd, bos, Loop).

How do Lightning Service Providers handle channel management?

LSPs manage channels on behalf of end users, primarily in mobile wallet applications. When a user needs to receive a payment, the LSP opens a just-in-time (JIT) channel using the LSPS2 protocol (bLIP-52), typically as a zero-conf channel for instant usability. The user never interacts with channel parameters, fee settings, or rebalancing. The tradeoff is trust (the LSP controls the channel) and cost (LSP fees cover the channel opening and ongoing liquidity provisioning).

Can I automate Lightning channel rebalancing?

Yes. On LND, AutoLoop triggers submarine swaps when channel balances fall outside defined thresholds, and bos provides scriptable circular rebalancing via cron jobs. On Core Lightning, CLBOSS handles rebalancing automatically using its xrebalance engine, which plans circular payments based on each peer's actual earnings. Alternatively, Amboss Magma subscriptions periodically replenish depleted capacity through the marketplace without requiring manual intervention.

What is the difference between charge-lnd and LND AutoFees?

charge-lnd is a third-party tool that applies per-channel fee policies based on configurable matching criteria (capacity, peer, balance ratio). It supports multiple strategies including proportional, cost-recovery, and on-chain-fee-referenced pricing. LND AutoFees (in Lightning Terminal) applies a single fee policy across all channels through a graphical interface. charge-lnd offers more granular control; AutoFees offers simpler setup and tighter integration with the Lightning Terminal dashboard.

Is there a Lightning solution that requires no channel management at all?

LSP-based wallets hide channel management from end users, but channels still exist under the hood and introduce capacity constraints. Spark eliminates channels entirely by using statechain-based transfers with FROST threshold signatures. There are no channels to open, fund, rebalance, or close. Spark maintains Lightning interoperability through Spark Service Providers (SSPs), allowing users to send and receive Lightning payments without managing any channel infrastructure.

This tool is for informational purposes only and does not constitute financial advice. Software features, configurations, and compatibility may change between versions. Always verify current documentation for your specific Lightning implementation before configuring automated channel management.