Lightning Economics: How I Learned to Stop Worrying and Love Inbound Liquidity
When mastering a skill, the more difficult aspects of growing and learning often feel like tedious distractions. Running scales on a guitar might feel like a diversion from really playing, and beating eggs might feel very far from haute cuisine.
But it’s vitally important to get those early steps right. It’s only with hindsight, upon achieving mastery, that what seemed to be standing in the way of progress is revealed to be, like, the key to everything. BB King is just scales and soul, and well-beaten eggs are the foundation and essence of a good soufflé.
Like a budding chef or musician, Lightning is also maturing, and we’re all learning how to master it. The intermediate step that currently seems like a distraction — but that in time will reveal itself to be the key to everything — is inbound liquidity. And like scales or stiff peaks, we will all love inbound liquidity once we’ve mastered this network.
Inbound liquidity has been declared a problem by some, and some others, and some others. I can see where they’re coming from, but inbound liquidity is only a problem if you start from the assumption that custodial models are the default and that our goal is to replicate them. However, if you adjust your perspective such that custodial models are an abomination and our goal is to supersede them, then inbound liquidity becomes a thing of beauty. It’s like sore muscles after a workout. It’s proof that the work is paying off and that the system is working.
To induce the necessary perspectival adjustment, let me quickly recap the architecture of Lightning, explain the role and economics of inbound liquidity, and then describe some different ways to monetize it and why it’s a necessary, beautiful component of our bigger, transformative whole.
Lightning Redux: Back to the Abacus
To understand the centrality of inbound liquidity, let’s review the structure of Lightning. Lightning is composed of nodes connected by payment channels. Payment channels are like the wires of an abacus, with the beads representing satoshis. But Lightning is like a hyper-abacus in that several wires/payment channels may connect any two nodes, and all the nodes in the network are connected one way or another by chains of wires and nodes.
Now, a vital, central, crucial point is that moving beads along a wire from one node to another (i.e. an off-chain transaction) is very cheap, but adding and removing beads from wires or transferring them between wires (i.e. on-chain transactions) are costly. So, in order to work as designed, Lightning needs to move beads from one end of the network to the other, over an indeterminate number of nodes and wires, while avoiding any change to the number of beads on any wire.
The trick is to induce a chain reaction of transfers. Let’s assume ubiquitous Alice wants to send a payment to inescapable Carol. While they don’t share a payment channel, they each share a channel with omnipresent Bob. Carol, the recipient, requests payment from Alice via invoice. Alice sends her satoshis to Bob, and Bob accepts her satoshis on one channel before forwarding the same quantity outwards on the other channel he shares with Carol. Crucially, no satoshis were added to or removed from any channel, but the correct quantity made it quickly, cheaply, and trustlessly to the destination.
Bob is the routing node. When routing nodes forward payments from one node to another, no satoshis ever switch wires, so each node in the chain needs enough liquidity on the outgoing wires to complete the next step in the chain reaction. Each incoming action causes an equal and opposite outgoing reaction (except the final receipt). This means that our hyper-abacus needs to be pre-loaded with plenty of liquidity to make these payments possible.
Who’s Supplying the Liquidity?
Executing Lightning transactions requires the liquidity for each payment to be located on the right side of the right payment channels. If the bitcoin is in the right place, it’s because someone put it there. The ones supplying it are routing nodes, LSPs, and users.
Routing-node operators vest the network with capital that they could use or *in*vest elsewhere. The capital they store in their local balances is what allows them to forward payments to the next node.
An LSP is effectively a user-facing routing node. LSPs need to balance their channels with other routing nodes, and they also have to maintain enough bitcoin in their local balances on the channels they share with users (i.e. the users’ inbound liquidity), which allows the users to receive payments.
True, users provide most of the liquidity required for their channels to work, especially in the case of zero-conf channels, and most of the bitcoin is initially in the users’ local balances, which is their outbound liquidity. As they spend their funds, they transfer money from their end of the channel to the LSP, and the LSP’s local balance is the user’s inbound liquidity.
From an LSP’s perspective, the good news is that users gradually fund their own inbound liquidity over time. The catch is that the LSP accumulates useful, valuable capital in its local balances, but that capital is largely illiquid, locked in the channels. In that sense, inbound liquidity is asymmetric from the LSP’s point of view: it’s only liquid from the user’s perspective.
Inbound liquidity is what lets money flow on Lightning. It’s what lets payments move from sender to LSP to routing node to routing node to LSP to recipient. On Lightning, liquidity means inbound liquidity.
Liquidity Is Scarce, Ergo It Is Valuable
Liquidity is the scarce resource, the one that potentially limits Lightning’s capacity and growth. Loading the network with bitcoin presents an opportunity cost to LSPs, and it can be significant. APY rates in excess of 3–5% are not hard to find.*
That opportunity cost is an economic reality. Someone with spare bitcoins has a decision to make: am I better off depositing that value with a crypto financial institution for a (more or less) predictable return or setting up a routing node, connecting to others, and trying to beat that return on Lightning?
Supplying liquidity is an investment, and we need to treat it accordingly. Like lending money or buying stock, investors commit capital for a period and expect a return that increases over time. From the LSP’s perspective, the cost of supplying liquidity increases with the number of users and the length of time that the capital is committed to that purpose, so the returns also need to increase per user and over time. That’s the formula.
However, there are a few important differences between supplying liquidity and making a loan:
- Borrowers take possession of the money loaned to them, but inbound liquidity remains with the LSP, waiting to be forwarded to the user … eventually.
- Borrowers pay interest on the loan and gradually reduce the amount of principal they owe. When supplying liquidity on Lightning, the cost to the LSP derives from the funds that the users don’t possess. As users spend and add to their remote balance, the LSP has more capital locked up in their payment channels. While those funds help to process payments that the user is receiving, it is capital that the LSP has earned but cannot use. The opportunity cost of the channel rises with use.
- Anyone with some spare cash can download a free loan agreement template and try their luck with lending, but beyond a certain level, a DIY RaspiBlitz will no longer suffice to compete as an LSP. The network of routing nodes and users will ignore an LSP that is not run professionally. A serious operation entails investment in hardware, software, and potentially staff to maintain uptime, performance, and efficient liquidity allocation.
Like I said, it’s an investment.
Monetization Models
For LSPs, supplying liquidity is an investment, not a problem. Nobody would describe buying bitcoin or startup equity as “a problem.” What makes it seem problematic is that we’re still devising and discovering ways to provide LSPs with returns on their investment.
An example might help to clarify the cost of supplying liquidity and how different monetization models might provide them with a return. Imagine a user opens a channel with an LSP and deposits funds in their wallet. The channel mostly contains the user’s own funds in their own local balance, so there is little cost to the LSP initially. As the user makes payments, liquidity accumulates on the LSP’s side, but the LSP is compensated with routing fees, so that’s fine too. However, if the user becomes less active, the LSP’s capital remains locked in the channel without earning a return. The longer the inactivity and the higher the LSP’s local balance, the higher the opportunity cost.
That’s the kind of situation our business models need to solve. Users need liquidity and functionality in an effortless, intuitive UX, and LSPs need ROI that reflects their costs.
A few monetization models with different advantages have already emerged, and more are likely to come:
- Subscription:
The first monetization model is based on subscriptions, just like movies, music, and cat food nowadays. In this model, users pay their LSP a monthly fee, and in return the LSP supplies them with a corresponding channel capacity. Sphinx, for example, charges users as little as 0.5% of their channel capacity per month. As with bandwidth from an ISP, higher capacities mean higher nominal fees, but at lower rates.
Despite their familiarity and popularity with end-users and providers alike, subscription models have a couple of disadvantages: they don’t adapt smoothly to actual usage patterns, and they’re really based on channel capacity, not inbound liquidity. Channel capacity is the sum of the balances on each end. This difference is important because users could, in effect, be paying for liquidity in their own local balance, which is their outbound liquidity — their own money. Naturally, users should only pay for the liquidity that someone else — their LSP — supplies. - Leasing:
Those with bitcoin to spare can lease it to those who need it for a fixed period at a predetermined rate using smart contracts. This is the model behind Lightning Pool, for example, which uses an auction mechanism to adjust the rental price of bitcoin to the demand for liquidity. Those who need it most will submit the highest bids, guaranteeing its providers the highest available return.
Again, leasing is a fairly blunt instrument in that it reacts relatively slowly to changes in usage patterns, and it increases capacity without simultaneously allocating the liquidity between the two balances on a channel optimally. - Routing fees:
With routing fees, LSPs charge a fixed fee plus a percentage of each transaction they forward. By endogenizing the incentives to payments moving over the network anyway, this model is arguably truest to Lightning’s purpose as a payment network and its goal of liquifying bitcoin. It’s also cheap for the users, and the cost adapts automatically to their usage patterns.
While an intuitively attractive solution, routing fees have a practical problem: they’re too low, perhaps just a few dollars a day for major routing nodes. As Lightning’s throughput increases, such low fees could remain economical thanks to much higher volumes. But we’re not there yet. Routing fees need to incentivize LSPs today and everyday until Lightning goes mainstream.
Yes, liquidity is a scarce resource, but that’s what economics is all about. It’s not a problem. The business models simply have to reflect the market forces at play, and then software and the market will let bitcoin flow freely to its most efficient use before flowing on again. The network is bootstrapping. It’s cool.
Nurture a Growing Network
To recap: the structure and design of Lightning requires liquidity to work, liquidity is a scarce resource whose suppliers need a return, but that quid-pro-quo is proof that Lightning is working as an extension of bitcoin, not a bastardization.
So how can we feed the network and foster its growth sustainably?
Mobile full nodes — and a fully decentralized network — will be a reality one day. Until then, LSPs are a necessary component of a distributed network.
Active users + solvent LSPs = a healthy, growing network.
In order to maintain a healthy population of LSPs on the network, routing payments and supplying liquidity must turn a profit. Cash flow is quite literally what Lightning is all about, and, like everyone, we LSPs just need a little more cash flowing in than is flowing out or stationary.
Part of the equation, then, is to compensate LSPs for supplying a scarce resource. The other part is preventing that cash from becoming stationary. We do that by closing inactive channels.
Closing inactive channels
Pruning a tree helps it to devote its resources to the fruit instead of to unproductive outgrowths, improving the quantity and quality of the harvest. Intelligent pruning actually fosters growth.
In order to encourage people to use Lightning actively and to allow us to allocate our liquidity more efficiently, we’re planning some judicious pruning. In effect, we need to watch which users are helping us and the network to grow more carefully. If a user has been inactive for 45 days, we might opt to close their channels, depending on the general status of our liquidity and the liquidity state of each specific, inactive channel. Doing so will allow us to provide optimal liquidity to users who need it.
There are few important points to note about closing inactive channels:
- It’s not free for either party. Whoever opens a channel pays the fee for closing it, and we, as an LSP, open channels for our users automatically, so we also pay the closing fee. Users’ residual balances are “swept’’ from the closed channel to an on-chain address that the Breez wallet generates. Users will incur a fee to retrieve them. This retrieval fee is, however, avoidable. Breez will notify users after 30 days of inactivity that a closure might be on the horizon.
- Thanks to multi-path payments, most users will have several channels open whether they know it or not, and even active users might have a few idle channels. However, Breez would close channels based on user activity, not channel activity. Specifically, we would close a user’s channels only if they show no activity over any of their channels for at least 45 days.
- Channel closures due to inactivity are, like many things, both an end and a new beginning. A user whose channels were closed can continue to use Breez. As soon as they receive their next payment, a new channel will be opened automatically and seamlessly.
Closing inactive channels is how we foster growth in our corner of the network. We grow stronger, active users get better functionality, and Lightning gets the liquidity it needs where it’s needed.
Inbound Liquidity Is Lightning’s Wabi-Sabi
Wabi-sabi is the Japanese idea that beauty is not the same thing as “perfection.” Change, growth, and the incompleteness we change and grow out of are part of beauty.
Inbound liquidity is beautiful, albeit in a slightly counterintuitive way. It’s proof that the network is growing sustainably and in accordance with bitcoin’s principles of decentralization, censorship-resistance, openness, and scarcity. An LSP that supplies users with liquidity does not take possession of their money.
Like brains and muscles, Lightning will improve as we use it more. As users make payments — rent, coffee, gaming, tips to podcasters — they generate routing fees. Routing fees are a major component of the LSP business model, and they infuse the network with liquidity. As liquidity becomes less scarce, more users join the network, fees drop, payments become even cheaper, and the network flourishes. It’s a virtuous circle that is yet gathering momentum.
To feed the network with liquidity, no heroic patches, workarounds, or ad hoc solutions are required; we just have to go about our lives and use Lightning the way it was intended.
*Edit:
I originally included rates quoted from Gemini, BlockFi, and Celsius’s own ad copy. Rusty (linked in text) apparently did some research and found these claimed rates to be grossly overstated. The text now reflects the correction.
