Sidecar Channel

What Is a Sidecar Channel?

A sidecar channel is a Lightning Network channel where a third party funds the channel opening on behalf of a recipient node. The buyer pays for the channel lease, a liquidity seller opens the channel, and the recipient node receives inbound liquidity without spending any bitcoin. The term "sidecar" reflects the arrangement: the recipient rides along while someone else drives (and pays for) the liquidity.

In a standard Lightning channel open, the node that initiates the channel must commit its own on-chain funds. This creates a bootstrapping problem: new users who want to receive payments need inbound capacity, but acquiring it requires either already having bitcoin to spend outbound or convincing a peer to open a channel toward them. Sidecar channels solve this by letting a third party (a wallet provider, exchange, or Bitcoin ATM operator) purchase capacity for their users through the Lightning Pool marketplace.

How It Works

Sidecar channels operate through Lightning Pool, a non-custodial auction marketplace where node operators buy and sell channel leases. Pool matches buyers who need channel capacity with sellers who have capital to deploy. Sidecar channels extend this model by letting the buyer direct the purchased channel to a different node.

The process involves three parties:

• Buyer (Alice): has a Pool account and funds to purchase a channel lease, but wants the channel delivered to someone else
• Seller (Bob): a liquidity provider matched through Pool's batch auction who opens the channel and commits the leased funds
• Recipient (Carol): the target node that receives the inbound channel from Bob, without needing a Pool account or any on-chain bitcoin

The Sidecar Ticket Workflow

A sidecar ticket is an encoded data structure that carries all the information needed to route a leased channel to the intended recipient. The workflow proceeds in several steps:

1. Alice creates a sidecar ticket in Pool, specifying the channel capacity and lease duration she wants to purchase
2. Alice sends the ticket to Carol through any communication channel (QR code, deep link, messaging app)
3. Carol registers the ticket with her LND node, which adds her node's public key and connection details to the ticket
4. Carol returns the completed ticket to Alice
5. Alice submits a bid in Pool's batch auction referencing the sidecar ticket
6. When the auction clears, Bob (the matched seller) opens a channel directly to Carol with the agreed capacity

The result is a standard Lightning channel between Bob and Carol, funded by Bob's liquidity and paid for by Alice. Carol now has inbound capacity and can receive payments immediately.

Sidecar Ticket Structure

The ticket passes through several states during the workflow. Pool's API exposes endpoints for creating, registering, and decoding tickets:

# Step 1: Alice creates a sidecar ticket
pool sidecar offer --capacity 500000 --lease_duration_blocks 2016

# Step 2: Carol registers her node with the ticket
pool sidecar register --ticket <encoded_ticket>

# Step 3: Alice finalizes and submits to auction
pool sidecar expect-channel --ticket <registered_ticket>

# Decode a ticket to inspect its contents
pool sidecar decode --ticket <encoded_ticket>

Trust Model

Sidecar channels are non-custodial: Alice never takes custody of Carol's funds, and Bob's funds go directly into the channel with Carol. However, Alice must trust that Carol's node will be online to complete the channel open. If Carol goes offline during the process, Alice's auction bid may fail. The channel itself, once opened, operates as a standard Lightning channel with normal commitment transaction mechanics.

Use Cases

Wallet Onboarding

Mobile wallet providers can use sidecar channels to bootstrap new users onto Lightning. When a user installs a wallet app, the provider purchases a sidecar channel on their behalf, giving the user immediate receive capacity. This eliminates the need for the user to acquire on-chain bitcoin first or understand channel management.

Exchanges and ATMs

Bitcoin exchanges and ATMs can provision Lightning channels for customers who want to receive payments. Instead of opening channels from the exchange's own node (which concentrates connectivity), sidecar channels connect users to diverse liquidity sellers across the network. This helps decentralize Lightning's topology.

Gift Channels

One user can gift Lightning capacity to another. A technically savvy node operator can purchase a sidecar channel for a friend or family member, onboarding them to Lightning without requiring them to learn about channel management, on-chain transactions, or liquidity markets.

Enterprise Provisioning

Businesses building on Lightning can pre-provision channels for their merchants or counterparties. A payment processor, for example, might purchase sidecar channels for all merchants in its network, ensuring they can receive Lightning payments from day one.

Comparison with Other Liquidity Solutions

Several approaches exist for solving Lightning's inbound liquidity bootstrapping problem. Each makes different tradeoffs:

Sidecar channels are unique in supporting true third-party funding: the entity paying for the channel is neither the seller nor the recipient. This makes them ideal for onboarding scenarios where the recipient has no capital. Liquidity ads offer a more decentralized approach but require the recipient to pay. LSPs provide the most seamless user experience by handling everything behind the scenes, and some LSPs use Pool's sidecar channels internally to source liquidity from a broader market.

For a deeper analysis of these tradeoffs, see the research article on Lightning liquidity marketplaces and the comparison of dual-funded channel economics.

Why It Matters

The inbound liquidity problem is one of Lightning's biggest barriers to adoption. New users cannot receive payments until someone opens a channel toward them with sufficient capacity on the remote side. Sidecar channels offer a market-driven solution: they let any funded participant purchase capacity for any other node, creating a pathway for wallet providers, exchanges, and communities to subsidize onboarding.

Sidecar channels also help decentralize Lightning's network topology. Rather than routing all new users through a single LSP node, sidecar channels connect recipients to whichever liquidity seller wins the Pool auction. This distributes connectivity across a broader set of routing nodes.

As the Lightning ecosystem evolves, the liquidity bootstrapping problem is being addressed through multiple complementary approaches. Layer 2 protocols like Spark take a fundamentally different approach to scaling Bitcoin, using statechains and virtual UTXOs to avoid the channel liquidity problem entirely.

Risks and Considerations

LND and Pool Dependency

Sidecar channels are specific to Lightning Labs' Pool marketplace and require LND nodes on all sides. They are not part of the BOLT specification and are not supported by other implementations like Core Lightning or Eclair. This limits the addressable market to LND operators.

Recipient Online Requirement

The recipient node must be online during the ticket registration and channel opening process. If the recipient goes offline at a critical moment, the buyer's auction bid can fail. This makes sidecar channels less suitable for intermittently connected mobile nodes unless an LSP mediates the process.

Lease Expiration

Channel leases purchased through Pool have a defined duration (typically 2,016 blocks, or roughly two weeks). When the lease expires, the seller can close the channel and reclaim their funds. The recipient must plan for channel turnover or renew the lease to maintain their inbound capacity.

Auction Cost Variability

The price of channel leases fluctuates based on supply and demand in Pool's batch auctions. During periods of high demand for inbound liquidity, lease rates increase. Buyers must decide how much premium they are willing to pay, and there is no guarantee of being matched in any given auction batch.

Coordination Overhead

The multi-step ticket exchange between buyer and recipient adds complexity compared to simpler approaches like JIT channels, where an LSP opens a channel automatically when a payment arrives. For consumer-facing applications, this coordination is typically handled programmatically through wallet APIs rather than manually.

This glossary entry is for informational purposes only and does not constitute financial or investment advice. Always do your own research before using any protocol or technology.