Integrated Music Streaming Service With the Lightning Network
Recently, I have become incredibly fascinated with the Lightning Network. In helping to co-create www.lightninghood.com I’ve come to learn about myriads of interesting applications that have been built or proposed that utilize micro-transactions in a new or interesting way. This in turn really peaked my curiosity and led me to ponder about what future business models that utilize the Lightning Network could look like and more specifically what would the value proposition look like to both the users and content creators.
In this post I will walk you through a hypothetical business model for a Music Streaming Service that has integrated the Lightning Network for payments.
If you want to cut to the chase and view the Excel analysis click here.
Background On The Music Streaming Industry
According to Digital Music News streaming services such as Apple Music and Spotify typically pay artist $7 per every 1,000 streams of a song. That $7 dollar payment doesn’t even go entirely to the artist as record labels, producers and song writers all get a cut of that money which on average adds up to be about a 70% royalty according to an article from CNBC. In this analysis for this hypothetical company it will look to try and dis-intermediate record labels by cutting exclusive deals directly with artists and only taking a royalty of 10%.
Streaming Service Functionality
With this hypothetical service I make the assumption that users will pay a few satoshi’s per some amount of seconds in order to stream any song that they choose. This model seemed the most logical and straightforward however the one big issue with this potential model is adjusting for bitcoin price volatility. In order to account for this I designed a two-way peg algorithm that is fully dynamic based upon a set fixed price in terms of USD.
The algorithm essentially works by goal-seeking the appropriate time interval and amount of satoshi’s to charge to end up at the desired set fixed price to charge for streaming. By doing this you can completely negate the effects of bitcoin price volatility and this would also allow the hypothetical company to set prices at whatever competitive rate they believe makes sense.
You can experiment with this in the model by simply changing the price of bitcoin and seeing how the algorithm adjust the time interval and amount of satoshi’s to be charged at various price levels.
Excel Analysis And Assumptions
The link to Excel analysis can be found here. The analysis is locked so you’ll have to download your own copy to play with the assumptions. All inputs are colored in blue and everything formulaic is colored in black so all you have to do is change the few blue inputs to see the impacts.
Some Key Considerations and Developments With The Lightning Network That Could Make This Hypothetical Business Model More Feasible
1.) Atomic Multi-Path Payments (AMP) — AMPs allow for large payments to be split into multiple small payments by the sender. AMPs will allow for additional routing flexibility and will also allow for multiple small channels to be represented to the user as a single unified balance. This will allow for users to more easily make recurring payments or subscription type model payments without having to reopen and close channels often once all of the liquidity gets used.
2.) Neutrino Wallets — Neutrino is a protocol to verify payments, except that the bulk of the work is done on the client side. This is significant because currently setting up a Lightning node is rather difficult especially if you aren’t technologically savvy. Neutrino will allow for Lightning Wallets to be run as a light client giving users the ability to not have to rely on a centralized server and without having to go through the process of setting up there own full node on a VPS. As a result neutrino wallets will help onboard several new users onto the lightning network in a frictionless way.
3.) Channel Splicing — Splicing will allow user to “top up” funds in an existing Lightning channel, or “drain” funds from it, while keeping the channel open. When “splicing in,” users take the opening transaction to instead send funds to a replacement opening transaction, which includes more bitcoin, from one or both users. Once this new opening transaction confirms on the blockchain, the channel is topped up. Until the new opening transaction is confirmed, the two users can simply update both the old and the new channel at the same time to avoid any “channel downtime.” Conversely, when they “splice out,” users take the opening transaction to send funds to a regular (on-chain) address, and potentially keep some of it in the channel using the same trick. This way, users can make on-chain transactions straight out of a Lightning channel. In addition this will also help to reduce to cost of keeping channels liquid.
4.) Sphinx — Sphinx send removes the need to create a payment invoice for a transaction, allowing more “spontaneous” activity effectively allows users to stream payments. This is huge for any subscription based Lightning Network service and can also help to alleviate some of the technical hurdles for users on-ramping onto the Lightning Network and making payments.
Based on the analysis and assumptions presented in my Excel analysis even with certain sensitivities it seems clear to me that services that plan to use the Lightning Network or a micro-transaction model have a clear opportunity to dis-intermediate incumbents while generating more value to users and content creators. A few things that are not taken into account in this hypothetical model that do present very real challenges are bootstrap, weaning both artists and users off of incumbents such as Spotify and Apple, technical questions such as how would liquidity would be managed, and whether the service would be a custodial or noncustodial.
I would like to give a special shoutout and thanks to Nic Carter for reviewing my analysis.
Follow me on Twitter @Coinbeezy and @Lightning_hood