Sidecar Channels: For Onboarding A Billion People to Bitcoin, Lightning Is Needed

Ryan Gentry
May 26, 2021

Today we are excited to announce a new addition to Lightning Pool: sidecar channels, a feature that makes it easier to onboard new users to Lightning without the need to commit funds.

In late 2020 we released Lightning Pool, a non-custodial, peer-to-peer marketplace for Lightning node operators to buy and sell channel leases. Lightning Pool connects node operators who need access to bitcoin liquidity with those who have capital to deploy on the Lightning Network. With Pool, node operators are able to bid on and purchase inbound liquidity while maintaining custody of their funds. However, Pool required those in search of inbound liquidity to fund their account with bitcoin before placing a bid, which isn’t ideal for all users.

Sidecar channels solve this problem by enabling a third party to purchase channels on behalf of a user. These are regular channels created through Pool, but where the buyer of liquidity is purchasing on behalf of a third party who does not have a Pool account yet. This makes it incredibly easy to onboard new users in a non-custodial manner to Lightning: spin up LND, scan a QR code from a node with a funded Pool account, and gain the ability to receive payments through a well-connected routing node. It also creates a new trust-minimized line of revenue for node operators interested in brokering channel leases to onboard these new users, and provides an incentivized way to create dual-funded channels between users.

How It Works: Bob’s Buddy Pass

In the simplest case, Alice decides she wants to start receiving bitcoin payments over the Lightning Network. However, she doesn’t have any bitcoin to fund channels. In this scenario, Alice could be a non-custodial wallet user, a merchant onboarding to BTCPayServer, or a podcaster onboarding to Sphinx.Chat. Prior to sidecar channels, Alice would have needed to fund a Pool account with bitcoin before purchasing an inbound channel through which she would receive Lightning payments.

However, with sidecar channels enabled, Alice can use the funds in Bob’s Pool account to purchase a channel instead. Bob could be the non-custodial wallet developer who wants to give his users a seamless onboarding experience, a BTCPayServer grant paying for a new merchant’s first channel, or the Podcast Index helping new podcasters get onto Lightning. The common thread is Bob’s funded Pool account, which gives him access to a marketplace of well-funded, highly connected routing nodes selling channels in return for yield on their bitcoin.

Let’s say Carol is such a routing node. So Alice pays Bob to provide her with an inbound channel (either in fiat or over LN directly), Bob pays the channel lease fee to Carol from his Pool account, and Carol opens a channel to Alice. Alice can now accept bitcoin payments over the Lightning Network, Bob made a small profit for brokering the channel lease, and Carol earned a risk-free yield on her bitcoin.

The Lightning Network is, of course, permissionless. There's no approval required in order to set up Lightning payments. Alice could be anyone creating value with an internet connection: DJs on Lightning Music Store, artists on Scarce.City, podcasters on Sphinx Chat, streamers on Twitch, and so much more.

But wait there’s more: New Channel Constructions

Sidecar channels also allow for a few new channel constructions:

  • Dual-funded channels: Alice doesn’t necessarily have to only be in need of receiving payments. She could pay Bob extra out-of-band and have him fund a balanced channel between her and Carol, so she can both send and receive payments right off the bat. This is also very useful for routing nodes that want to start off with a balanced channel, especially as it is cheaper than buying one inbound channel lease and selling one outbound channel lease with the current Pool configuration.
    • Additionally, using the original Pool channel process with just Alice and Bob, Alice can now add funds via the "self balance" field, which atomically pushes funds to Bob’s side of the channel in the batch to simulate dual funding.
  • Direct exchange withdrawals to a channel: If Alice is a Lightning-enabled exchange with a Pool account, Bob could request an on-chain withdrawal directly to a new channel between his Lightning node and Carol. Alice would pay Carol’s Pool account (with Bob’s money) both the full channel balance and the premium so that Carol would open a channel to Bob with the entire balance pushed to Bob’s side of the channel.





This feature does require Bob’s client software to have some lightweight Pool functionality to be able to register with the auctioneer, which is coming soon to Lightning Terminal.

New Users, New Revenue Models

In short, sidecar channels make Lightning liquidity more portable and flexible within the network, without compromising on trust. They allow for a new line of revenue for node operators via brokering channel leases, and potentially for a new trust-minimized business model for those interested in onboarding merchants to the Lightning Network in a non-custodial manner.

Sidecar channels are available via a new release of the command line using the reference Go client (poold) and will be available in Lightning Terminal with the upcoming LiT v0.4.2 release (UI coming soon!). APIs are available for gRPC and REST integrations. As always, we want to hear from our community, so please email us, find us on Twitter, or join our developer Slack to let us know what you think, get help, or ask questions about sidecar channels and Pool.

This is the first of many continuous improvements to Lightning Pool, including (but not limited to) zero-conf channels. Stay tuned! 🚆

About the authorRyan Gentry

Ryan holds an MSc in Electrical and Computer Engineering from Georgia Tech and a BS in Aerospace Engineering from the University of Texas. Prior to joining Lightning Labs, he spent two years on the deal team as Lead Analyst for Multicoin Capital. Ryan graduated from UT in 2014 and went to work for Intel as a Controls Engineer. He caught the Bitcoin bug in 2017 while building Internet of Things prototypes when he realized all of these Things were going to need some way to pay each other and USD wasn't going to cut it.

Ryan holds an MSc in Electrical and Computer Engineering from Georgia Tech and a BS in Aerospace Engineering from the University of Texas. Prior to joining Lightning Labs, he spent two years on the deal team as Lead Analyst for Multicoin Capital. Ryan graduated from UT in 2014 and went to work for Intel as a Controls Engineer. He caught the Bitcoin bug in 2017 while building Internet of Things prototypes when he realized all of these Things were going to need some way to pay each other and USD wasn't going to cut it.