Use case specific Lightning Service Providers

Onboarding users on non-custodial wallets is tricky because of inbound liquidity requirements. A closer collaboration with use case specific apps can help Lightning Service providers to reduce capital cost and these apps to improve user experience.   

The State of Lightning Service Providers

Transacting on bitcoin’s lighting network requires a lighting wallet with at least one open channel to a well connected lightning node and liquidity on both ends of the channel to ensure successful incoming and outgoing payments. Consequently more tasks are involved than merely furnishing software to safeguard private keys for transaction signing and a user interface enabling transaction sending, receiving, and listing. 

As a consequence the new discipline of Lightning Service Providers was created to take over this kind of tasks. They provide users with a stable connection to the lightning network, channel management, and liquidity.

Acinq, Blocktank, Breez, c=, LQWD, Olympus or Flow are just a few of them. Since the introduction of the term LSP in 2019 the number of LSPs has steadily increased, with providers notably professionalizing their offerings. Generally, these providers generate revenue through service fees.

Liquidity Allocation Challenges Remain  

Provisioning inbound liquidity is one core task of an LSP enabling the user to receive payments. However, accurately estimating the appropriate amount is not trivial. Excessive liquidity raises capital costs, while insufficient liquidity leads to additional channel openings or splicing, resulting in added expenses for bitcoin on-chain transactions. Ultimately the user is confronted with higher fees and a worse payment experience.   

The General Wallet LSP Model

The Lightning Service Provider Spec helps to source liquidity easily from different providers by a unified API specification for more interoperability between different wallets and LSPs. Dedicated liquidity and channel management services are promising as they enable involved parties to focus on capabilities, knowledge, and resources needed. 

However, 3rd party LSPs know little about their users and their liquidity needs which leads to estimation errors and consequently higher cost for users. One might argue that wallets have the best knowledge about their users and should be able to support these LSPs with data to optimize the channel balance accordingly. However this disregards changes in user behavior such as churn, or simply discovering new apps to pay and receive bitcoin. For wallets covering various payment use cases it is tricky to assume a payment pattern of one specific user directly at signup when a new channel needs to be created. 

Data quality gets particularly worse if users may create channels with different LSPs. For that reason Phoenix users are restricted to utilizing Acinq's service exclusively. While this approach may lead to improved liquidity provision and reduced costs, it limits users' flexibility in opening channels to alternative peers.

The Use Case Specific LSP Model

Imagine if users of the Lightning Network received liquidity tailored precisely to the purpose of their transaction. Wallets might inquire about the user's intended use or analyze historical data to determine liquidity requirements, but such approaches could be seen as overly intrusive by users. However, certain services inherently reveal the purpose upon user registration, such as crowdfunding platforms, podcast hosting apps, or merchant services.

These apps have access to important data points namely the expected transferred amount and life time of an average user as two key input parameters for providing the right channel size and balance. 

Many of them already charge transaction fees, like Geyser, a crowdfunding platform for bitcoin projects, or merchant services such as Opago. Providing the liquidity could attract more projects to their platform and in return charge a slightly higher percentage per transaction in return. Also, billing services like Zaprite or podcast hosting platforms could include a liquidity fee in their monthly subscriptions. 

Umbrel, StartOS, Voltage, Zeus, Mutiny and Alby’s upcoming wallet have lowered the barriers to spin up own lightning nodes drastically, but finding reliable channel partners with the right amount of inbound liquidity still requires research. This search process unnecessarily prolongs the user journey and increases the probability of dropping out of the acquisition funnel or opting for easy-to-use custodial wallets. Instead users of non-custodial wallets could pair their nodes during the registration process with a service like Geyser, Opago, or with a dedicated LSP in close collaboration to receive incoming liquidity specifically tailored to their needs.  

A Model Borrowed From The Fiat World

Airbnb holds funds until the guest checks in and applies a fee based on the paid rate. Gumroad collects sales from consumers, deducts a 10% fee, and then disburses the remaining amount to their publishers. Buy Me a Coffee first collects payments from consumers, deducts a 5% fee, and forwards 95% to publishers. Buzzsprout, a podcast hosting company offering monthly subscriptions, collects value4value payments from listeners upfront and applies a 15% charge to the podcaster.

This list of merchant, publisher and podcasting apps offering financial services can go on. Certainly there are instances that deviate from this pattern, but that’s not the point. Since a routing node does not control or hold custody of the funds, it seems to fall outside of money transmitter and financial service activity. 

This article should encourage existing bitcoin apps to look into additional services to expand their business and reach more users. And if sourcing liquidity for your service is an issue, there are above mentioned LSPs that are open for closer collaborations. Lightning is a liquidity network and enhanced liquidity distribution and allocation benefit all network participants.