Liquidity requirements for Lightning payments: Ark servers and LSPs compared
We finally have some research into Ark liquidity requirements that we're ready to share!
To explore this topic, we simulated real-world usage for bitcoin users sending Lightning payments. While Ark users can also send payments directly over the Ark protocol, we expect that initially, users will be mostly using Ark as a Lightning gateway, at least until Ark builds up some momentum. So that's where we started!
To put things into perspective, we'll compare these requirements to those of a Lightning Service Provider (LSP).
Let's dive in.
What drives liquidity requirements?
Before we "run the numbers", let's cover a quick primer on the mechanics of liquidity on both Lightning and Ark.
LSP liquidity
These days, a typical user uses Lightning through an LSP and the user has a single channel with their LSP.
A payment channel between a user and the LSP is shown below. The channel has a capacity of 1 BTC, the user has a balance of 0.4 BTC and the service provider has a balance of 0.6 BTC.
The 0.6 BTC in the channel is owned and provided by the LSP. The LSP can only use this money to serve that specific user and might expect a return for locking in the money. Note that the amount of bitcoin an LSP needs to provide doesn't depend on transaction volume, but solely on the channel balance.
An LSP can optimize liquidity efficiency by regularly adjusting the channel capacity for each user. However, each time the channel capacity is adjusted/spliced, the LSP pays fees for an on-chain transaction. Another option is to close channels to inactive users who don't generate sufficient revenue.
Ark server liquidity
A typical bitcoin wallet manages UTXOs ("unspent transaction outputs"). An Ark wallet manages VTXOs ("virtual transaction outputs"), which are the outputs of normal bitcoin transactions that haven't been broadcast yet.
An Ark server must use its own bitcoin to enable the following actions:
- VTXO refresh: Ark servers must provide liquidity when creating new VTXOs during refreshes in rounds, as they will only claim forfeited bitcoin from expired VTXOs after the
vtxo_expiry_deltaperiod (typically 28 days after the inception of the VTXO). - Paying over Lightning: When users make Lightning payments by giving up their VTXOs, the server covers the payment amount until VTXO expiry.
- Off-boarding (on-chain sends): Servers provide immediate on-chain bitcoin when users off-board their VTXOs, but only access the forfeited VTXOs after expiry.
The following actions don't impose any liquidity requirements on the server:
- Internal Ark payments: Ark payments between users of the same server occur out-of-round and don't require liquidity.
- Boarding: Users board the Ark with their own funds.
- Unilateral exit: Users broadcast their VTXOs independently without server involvement.
The main lever for an Ark server that wants to optimize liquidity efficiency is fees. The server will ask a lower fee when a user performs refreshes, off-boards, or Lightning spends from a VTXO that is soon to expire and a higher fee for a VTXO that expires later. This incentivises users to always use their oldest VTXOs.
Do Ark servers or LSPs require more liquidity for Lightning?
If you hoped for a straight answer, you are out of luck. The truth is, it depends... The liquidity mechanics of an Ark server and an LSP are wildly different.
To compare the two, we have simulated two common modes of bitcoin user behaviour:
- Infrequent top-up, gradual spending: User funds their wallet infrequently from cold storage and gradually spends their balance using Lightning.
- Regular DCA stacker: User buys bitcoin for a fixed amount of dollars every month. Moves funds to cold-storage at the end of the year.
Simulations assumptions on parameters and user behavior
For all simulations, we've assumed:
- All outgoing payments sent over Lightning. For Ark, this provides a worst-case estimation for liquidity burden (overestimating required capital), as Lightning payments require immediate liquidity while internal Ark payments don't. In practice, users will likely make some or most payments directly through Ark. Also, once Ark supports virtual Lightning channels, this model will change entirely.
For LSP simulations, we've assumed:
- No channel capacity adjustments: The LSP does not adjust the user's channel capacity throughout the year.
For Ark simulations, we've assumed:
- VTXO expiry time of 28 days: A server-configured parameter balancing cost and convenience.
- Each received VTXO expires 14 days after receipt: This represents the average VTXO age, as the user will accumulate both newer and older VTXOs over time, resulting in an average lifespan halfway through the 28-day period.
- User refreshes all VTXOs two days before expiry: This would be configured by the user and automated by their wallet app. Two days gives them ample time to re-attempt refreshes in case something goes wrong with the first attempt.
| Parameter | Value |
|---|---|
| vtxo_expiry_delta | 28 days |
| refresh_window | 2 days |
| new_vtxo_age | 14 days |
User profile: Infrequent top-up, gradual spending
This scenario considers a user that periodically funds their wallet and spends gradually using Lightning over a period of one year.
We'll compare LSP and Ark server liquidity requirements for a user that:
- Tops up once a week
- Tops up once a month
- Tops up once a quarter
The total liquidity burden is shown as a blue area in the LSP simulations, and a yellow area in the Ark server simulations. We call this satoshi days (sat-days). One sat tied up for 10 days, or 10 sats tied up for one day, both equal 10 sat-days—the same cost to the server.
If we divide sat-days by the total payment volume we can get the liquidity duration in days. This is the average duration an LSP or Ark server needs to lock up an equivalent amount of sats for each sat spent.
Top up every week
LSP
| Metric | Value |
|---|---|
| Liquidity burden | 62,730,000 sat-days |
| Payment volume | 15,330,000 sat |
| Liquidity duration | 4.09 days |
Ark server
| Metric | Value |
|---|---|
| Liquidity burden | 155,340,000 sat-days |
| Payment volume | 30,930,000 sat |
| Liquidity duration | 10.13 days |
Result
LSP 2.485x times more efficient.
Top up every month
This scenario most closely resembles the typical once-a-month salary and daily spending on life expenses.
LSP
| Metric | Value |
|---|---|
| Liquidity burden | 58,460,000 sat-days |
| Payment volume | 3,600,000 sat |
| Liquidity duration | 16.24 days |
Ark server
| Metric | Value |
|---|---|
| Liquidity burden | 61,252,500 sat-days |
| Payment volume | 3,600,000 sat |
| Liquidity duration | 17.014 days |
Result
Roughly similar (LSP is 1.046x more efficient).
Top up every quarter
LSP
| Metric | Value |
|---|---|
| Liquidity burden | 76,902,000 sat-days |
| Payment volume | 1,200,000 sat |
| Liquidity duration | 64.085 days |
Ark server
| Metric | Value |
|---|---|
| Liquidity burden | 20,600,000 sat-days |
| Payment volume | 1,200,000 sat |
| Liquidity duration | 17.17 days |
Result
Ark server is 3.73x times more efficient.
User profile: Regular DCA stacker
This user aims to accumulate bitcoin and hodl long-term. They buy 100 USD of bitcoin on a biweekly basis. At the end of the year the user drains their wallet and sends all funds to cold-storage.
LSP
| Metric | Value |
|---|---|
| Liquidity burden | 870,449,331.06 sat-days |
| Payment volume | 4,139,500 sat |
| Liquidity duration | 210.27 days |
Ark server
| Parameter | Value |
|---|---|
| vtxo_expiry_delta | 28 days |
| refresh_window | 2 days |
| new_vtxo_age | 14 days |
| Metric | Value |
|---|---|
| Liquidity burden | 130,887,780.61 sat-days |
| Payment volume | 4,139,500 sat |
| Liquidity duration | 31.6 days |
Ark is 6.65x more efficient in the above scenario.
Summary
| Scenario | LSP duration | Ark duration | Winner |
|---|---|---|---|
| Weekly top-up | 4.09 days | 10.13 days | LSP |
| Monthly top-up | 16.24 days | 17.01 days | Similar |
| Quarterly top-up | 64.09 days | 17.17 days | Ark |
| DCA stacker | 210.27 days | 31.60 days | Ark |
Key observations
Balances vs. payment volume
An LSP's liquidity requirements are driven primarily by changes in users' balances, whereas Ark server liquidity requirements are driven by payment volume.
LSPs face greater variability of liquidity duration than Ark servers
The liquidity duration is 4 to 64 days for the LSP and 10 to 17 days for the Ark server. Individual users can exert significantly different liquidity pressures on an LSP.
LSPs need to be much better than Ark servers at predicting user behavior
An LSP must assign an inbound channel capacity to each user, but it can't know in advance how much a user will (net) receive via the channel. It can adjust the channel capacity throughout the year but every adjustment will require a costly on-chain transaction.
In some cases the LSP might be very efficient but in some cases the LSP might allocate a lot of liquidity that will never be used. Poor predictions can result in poor efficiency. Any costs associated with inefficiency will ultimately need to be borne by the LSP's users.
An Ark server doesn't need to play a guessing game. It simply allocates the exact amount of liquidity required at the time of a Lightning spend.
Funding frequency is a key factor in Ark liquidity efficiency
We learned that liquidity efficiency is heavily determined by how frequently the user funds their wallet. An Ark server is most efficient when users top up less frequently than the vtxo_expiry_delta period.
For example, in the monthly top-up simulation, the spike on day 12 to 14 of every month is caused by a refresh of all the VTXOs that have been received in the beginning of the month which are close to expiry.
However, even with a user freqently depositing to their wallet, note that the Ark server's liquidity burden is still consistently reasonable.
Conclusion: Ark can enhance liquidity efficiency for users making infrequent Lightning payments
Based on our simulations, if you're the kind of user that's spending bitcoin over Lightning daily, and receiving payments every week or more, then you're likely to be spending less on liquidity than if you used Ark.
But if you're making less-frequent payments, and only receiving bitcoin each month (e.g., a monthly salary or bitcoin purchase), then using Ark with a Lightning gateway should offer significant savings.
If you're a DCA bitcoin stacker, you absolutely-definitely should be using Ark, with liquidity costs being a small fraction of what it would cost to use an LSP.
And remember, the simulations for Ark assumed the user made only payments over Lightning. It is a conservative, "worst-case" scenario—payments from Ark to Lightning require immediate liquidity, but payments over Ark do not.
At the very least, we hope the simulations demonstrate that the liquidity requirements for Ark are not excessive. That's one common misconception that we're keen to head off!
Follow for more research
We've got more liquidity research to come—it's essential for both our users to understand what to expect from the Ark protocol, and for us as we optimize liquidity. Ark has a lot of parameters we can tweak and any efficiency gains will translate into lower costs for our users!
Make sure you follow us on X or sign up to our newsletter to keep up with the research!