By Matthew Vuk
We are ready to share some research on Ark's liquidity requirements.
To explore this topic, we simulated the use case of a Bitcoin user sending a Lightning payment. While Ark users can send payments directly through the Ark protocol, we expect that initially, users will primarily use Ark as a Lightning Network gateway, at least until Ark becomes more widespread. So, we'll start there.
To properly understand the problem, we will also compare these requirements with the liquidity requirements of Lightning Service Providers (LSPs).
Factors that generate liquidity requirements
Before we "speak with numbers", let's first briefly understand why LSP and Ark service providers have liquidity thresholds.
LSP Liquidity
Today, a typical user uses the Lightning Network through an LSP, and the user will only open one Lightning channel with the LSP.
The payment channel between a user and an LSP is shown in the figure below. The channel capacity is 1 BTC, the current balance of the user in the channel is 0.4 BTC, and the current balance of the recipient is 0.6 BTC.
The 0.6 BTC in the channel is held by the LSP and injected into the channel by the LSP. The LSP uses this money to serve this user, hoping to earn a reward (at the cost of locking up these funds). Note: The amount of Bitcoin the LSP needs to provide is not determined by the transaction volume, but only by the balance in the channel .
(Translator's note: This means that the amount of liquidity an LSP injects into a channel does not strictly depend on the amount of a user's transaction, but only on the initial balance distribution the LSP wants the channel to have. After the channel is created, the balance status in the channel will continue to change as users receive/send Lightning payments.)
LSPs can optimize liquidity utilization by regularly adjusting channel capacity for each user. However, each time a channel capacity adjustment is performed (a so-called "channel splicing"), the LSP must pay on-chain transaction fees. Another option is to close channels with inactive users—users who are not generating sufficient returns.
Ark Service Provider Liquidity
Standard Bitcoin wallets manage UTXOs (“unspent transaction outputs”). Ark wallets manage VTXOs (“virtual transaction outputs”), which are outputs from regular Bitcoin transactions that have not been broadcast.
An Ark service provider must use its own Bitcoin to support the following operations of users:
- VTXO Refresh : When refreshing a VTXO at a user's request during a round, Ark providers must advance funds because they can only withdraw funds from old VTXOs (i.e., abandoned VTXOs) after they expire. (The expiration date is determined by
vtxo_expiry_delta, which is typically 28 days after the VTXO was created.) - Lightning Payment : When a user initiates a lightning payment (and gives up their VTXO at the same time), the service provider must pay first and can only recover the funds when the VTXO expires.
- Exit (on-chain payment) : When a user wants to leave the Ark protocol, the service provider must immediately provide on-chain Bitcoin, but the funds can only be recovered after the VTXO that the user has abandoned expires.
However, the following activities will not impose liquidity requirements on service providers:
- Ark Internal Payments : Ark payments between users of the same service provider occur outside of the round and do not require the service provider to provide liquidity.
- Entry : Users enter the Ark Protocol using their own funds.
- Unilateral withdrawal : The user broadcasts his or her VTXO without the participation of the service provider.
Ark providers' primary tool for optimizing liquidity efficiency is provider fees. When users refresh, exit, or make a lightning payment, the fees charged by the provider are linked to the remaining expiration time of their VTXOs: VTXOs nearing expiration incur lower fees, while VTXOs with a longer expiration time incur higher fees. This incentivizes users to always use their earliest generated VTXOs.
Ark Service Providers and LSPs: Who Needs More Liquidity?
If you're looking for a simple answer, you might be disappointed. It really depends. The liquidity mechanisms for Ark service providers and LSPs are quite different.
To compare the two, we simulated two common Bitcoin user behavior patterns:
- Low-frequency top-ups, slow spending : Users don’t frequently withdraw funds from their cold storage to their hot wallets, and spend their balances slowly using the Lightning Network.
- Regular investment hoarders : Users use a fixed amount of US dollars to purchase Bitcoin every month and transfer the funds to cold storage at the end of the year.
Model assumptions about parameters and user behavior
For all simulations, we assume that:
- All outgoing payments go through the Lightning Network . For Ark, this represents a worst-case liquidity burden (and overestimates the required funds), as Lightning payments always require immediate liquidity from service providers, while internal Ark payments do not. In reality, users may initiate some or even all payments through Ark. Furthermore, once Ark supports "virtual Lightning channels," this model will completely change.
For the LSP simulation, we assume that:
- No channel capacity adjustment : LSP does not adjust the capacity of the user's channel throughout the year.
For the Ark provider simulation, we assume:
- VTXO expiration is 28 days : this is a provider-configurable parameter that balances cost and convenience.
- Every VTXO received will expire 14 days after receipt : this represents the average VTXO lifespan, as users accumulate both older and newer VTXOs, so the average lifespan of VTXOs is half of the 28 days (expiration time).
- Users always refresh their VTXOs two days before the expiration date : this is a parameter that users can adjust, and can be automatically performed by their wallet app. The two days allow them to try again after a failed refresh attempt.
The above assumptions can be summarized as follows:
| parameter | Numerical |
|---|---|
| vtxo_expiry_delta | 28 days |
| refresh_window | 2 days |
| new_vtxo_age | 14 days |
User scenario: low-frequency top-up, slow spending
In this scenario, users would regularly top up their wallets and slowly spend the funds via the Lightning Network over a period of one year.
We compared the liquidity requirements of LSPs and Ark service providers under the following three conditions:
- Recharge once a week
- Recharge once a month
- Top up once every quarter
In the figure below, the liquidity burden of LSPs is represented by the blue area, while that of Ark service providers is represented by the yellow area. The unit we use to measure liquidity requirements is the " satoshi-day ." Whether locking up 1 satoshi for 10 days or 10 satoshi for 1 day, both equal 10 satoshi-days, resulting in the same cost to the service provider.
If we divide the daily satoshi value by the amount of payments, we get the “liquidity lock time” in days. This is the average time it takes for an LSP or Ark service provider to lock up an equivalent amount of satoshis for every satoshi a user spends.
Recharge once a week
LSP
| index | Numerical |
|---|---|
| Liquidity burden | 62,730,000 satoshi-day |
| Payment volume | 15,330,000 Satoshi |
| Liquidity lock time | 4.09 days |
Ark Service Provider
| index | Numerical |
|---|---|
| Liquidity burden | 155,340,000 satoshi-day |
| Payment volume | 30,930,000 Satoshi |
| Liquidity lock time | 10.13 |
result
The liquidity efficiency of LSP is 2.485 times that of Ark service providers.
Recharge once a month
This situation is similar to the common situation of receiving salary once a month and spending some money every day.
LSP
| index | Numerical |
|---|---|
| Liquidity burden | 58,460,000 satoshi-day |
| Payment volume | 3,600,000 Satoshi |
| Liquidity lock time | 16.24 |
Ark Service Provider
| index | Numerical |
|---|---|
| Liquidity burden | 61,252,500 satoshi-day |
| Payment volume | 3,600,000 Satoshi |
| Liquidity lock time | 17.014 days |
in conclusion
Both are almost equally efficient (LSP is slightly more efficient).
Top up once every quarter
LSP
| index | Numerical |
|---|---|
| Liquidity burden | 76,902,000 satoshi-day |
| Payment volume | 1,200,000 Satoshi |
| Liquidity lock time | 64.085 days |
Ark Service Provider
| index | Numerical |
|---|---|
| Liquidity burden | 20,600,000 satoshi-day |
| Payment volume | 1,200,000 Satoshi |
| Liquidity lock time | 17.17 |
result
The efficiency of Ark is 3.73 times that of LSP.
User scenario: Regular investment
Such users attempt to accumulate Bitcoin and hold it for the long term. They might purchase $100 worth of Bitcoin every two weeks. At the end of the year, they clean out their wallets and transfer everything to cold storage.
LSP
| index | Numerical |
|---|---|
| Liquidity burden | 870,449,331.06 satoshi-day |
| Payment volume | 4,139,500 Satoshi |
| Liquidity lock time | 210.27 days |
Ark Service Provider
| index | Numerical |
|---|---|
| Liquidity burden | 130,887,780.61 satoshi-day |
| Payment volume | 4,139,500 Satoshi |
| Liquidity lock time | 31.6 days |
The efficiency of Ark service provider is 6.65 times that of LSP.
Summarize
| long | LSP Fund Locking Period | Ark Fund Lockup Period | Winner |
|---|---|---|---|
| Recharge once a week | 4.09 days | 10.13 days | LSP |
| Recharge once a month | 16.24 days | 17.01 days | tie |
| Top up once every quarter | 64.09 days | 17.17 days | Ark |
| Regular investors | 210.27 days | 31.60 days | Ark |
Insight
Balance vs. Payment Volume
The liquidity requirements of LSPs are primarily determined by changes in user balances, while the liquidity requirements of Ark service providers are primarily determined by payment volume.
The liquidity lock-up period of LSP is more variable than that of Ark service providers.
The liquidity lock-up period for LSPs can be as short as 4 days or as long as 64 days, while the lock-up period for Ark service providers is 10 to 17 days. Different users may bring significantly different pressures to LSPs.
LSPs must be better at predicting user behavior than Ark providers.
LSPs must allocate appropriate channel capacity (receivable amount) for each user. However, the user’s net receivable amount is unknown in advance. LSPs can only adjust channel capacity, but each adjustment incurs a costly on-chain transaction fee.
In some cases, an LSP may be more efficient, but it can also allocate liquidity to users that they don't need. Poor forecasting leads to inefficiencies. Any costs associated with inefficiencies are ultimately borne by the LSP's users.
Ark service providers don’t have to play this guessing game. They simply allocate a specific amount of liquidity when a user initiates a Lightning Payment.
The frequency of deposits is a key factor in Ark’s liquidity efficiency
We found that liquidity efficiency is closely related to how frequently users top up their wallets. Ark providers are most efficient when the interval between user top-ups is longer than vtxo_expiry_delta .
For example, in the simulation of monthly recharges, the peak from the 12th to the 14th of each month is because the VTXO received at the beginning of the month is about to expire and needs to be refreshed.
However, even if users frequently top up their wallets, the liquidity burden on Ark service providers remains at a reasonable level.
in conclusion
Ark can increase liquidity requirements for users who infrequently initiate Lightning payments .
Based on our simulations, if you are the type of user who sends lightning payments every day and receives lightning payments every week (or longer), you may save more money using LSP than using Ark.
However, if your payments are less frequent and you only receive payments once a month (such as monthly salary and regular Bitcoin investments), then using an Ark provider with a Lightning Network gateway may save you a lot of money.
If you are a regular investor, then you should definitely use Ark, as the liquidity fees you pay will be a fraction of what you would pay using LSP.
Furthermore, the Ark simulation assumes that users will only initiate payments via the Lightning Network. This is a conservative, “worst-case” assumption, as initiating Lightning payments from the Ark protocol requires immediate liquidity from the service provider, while payments within the Ark protocol do not.
Finally, we hope this simulation demonstrates that Ark service provider liquidity requirements are not excessive. This is a common misconception we hear!
(over)
