Swimming in the Stability Pool: Part 2

In our previous article (Swimming in the Stability Pool: Part 1), we described a conservative HODL-based strategy that resembles our previous SuperHODL strategy. The new strategy showcases an exciting use case for Zero's stability pool, particularly with the introduction of DLLR, a new asset, and the latest Sovryn dApp.

By means of a short re-cap: the StableHodl algorithm is a collateral management system in the Zero protocol that utilizes the stability pool. It deposits a reserve of DLLR stablecoins in the stability pool and leverages the assumption that Bitcoin will appreciate against the USD over time. As the value of collateral in Bitcoin increases, more DLLR are minted and more bitcoin is purchased. At the same time, it uses the deposit to avoid liquidations and redemptions against bitcoin price volatility.

In this second part, we will analyze the numbers behind the StableHODL concept, describe the assumptions made, perform backtesting, and introduce recent improvements. Let’s dive in!

Modeling Liquidations on Zero

A simple (yet elegant) liquidation returns model from Fishing for Gains in the Zero Stability Pool: Logistic Regression Analysis was used.

There are a few limitations to this model. First, the model is based on a dataset from a limited timeline, which may not be a reliable data source for long-term extrapolation. Second, the model assumes there's enough liquidity in the SP to cover any liquidation without redistributing debt to the LoCs. Since the relative size of the stability pool is likely to grow over time, this model most likely overestimates the returns.

Besides modeling liquidations, one key change since the last article introducing StableHODL is how the algorithm handles liquidations. In order to maintain reserve balances through liquidations, StableHODL:

1. Sells the amount of bitcoin to obtain the equivalent burned DLLR tokens from the liquidation event;
2. Transfers the newly obtained DLLR to the stability pool;
3. Keeps the profits from the liquidation event in bitcoin in the user’s wallet.

Selling is the “easy way out”. Alternatives would be to add the obtained bitcoin to the Zero LoC collateral and obtain the DLLR tokens back from Zero. However, this is most likely not sustainable: the DLLR tokens are burned at a ~110% collateral ratio (liquidation value of BTC obtained) while they are minted at a potentially much higher CR depending on system conditions.

Please keep this in mind if you have any tax implications from such sales in your jurisdiction. Notably, liquidations occur infrequently.

Strategy to Avoid Redemptions

Redemptions enable the protocol to guarantee a base value by allowing anyone to always exchange 1 DLLR for 1 USD worth of RBTC. When a redemption is triggered by any user, the protocol automatically exchanges the incoming DLLR to pay back the equivalent loan amount on the outstanding line(s) of credit with the lowest CR in the system. At the same time, the collateral on those lines gets paid out to the redeemer. 

No value is lost in the line of credit, as the user is paid at the market rate for providing the RBTC to enable the redemption. However, redemptions can create a poor user experience on Zero protocol. One day you open a loan, set your CR to well above the liquidation limit, and the price is stable. Next day, all of a sudden, your line of credit is changed! What happened? Was I hacked? It is probable you were redeemed against.

In order to avoid redemptions for users of the algorithm, the newest version of the algorithm is updated to adjust the CR target based on the Total Collateral Ratio (TCR) of the protocol. Since it is assumed the user line of credit is safe against redemptions once we are above the protocol TCR on a regular basis, the target CR is always tuned to be higher than the TCR. In that way, by guarantee, there is another loan with a lower CR than the user line of credit.

Clearly, the TCR needs to be modeled in order to backtest. This is very hard due to very limited historical data and the speculative nature of trying to see how the TCR would behave against market conditions, user growth, … Therefore, a very simple model was taken where the CR makes a full sinusoid sweep from a 250% TCR with an amplitude of +/-100%. This means TCR reaches any value between 150% and 350%, not correlated to price. Further study of dynamic modeling of the TCR is out of scope for the results in this study. 

On-chain Transaction Fees

In the long term, the transaction fees on all the operations on the Rootstock sidechain require significant funding, and all those costs are accounted for by the algorithm (through estimates of operations based on June 2023 operations). However, while we have a daily check on avoiding possible liquidation and redemption risks against the lower bound (repayment) target, we do not necessarily need to accept having a buy trigger on the daily when we hit our upper bound (buy) target. In fact, if we are just a few %-points above the buy target CR, often the fees significantly eat into the profit ratio.

Of course, every sat counts. If we wait too long before triggering a buy, we will miss out on valuable stack opportunities. Therefore, in our testing, we have played with a parameter we will call “SkippedDays”. This means we only check for and trigger a possible buy every SkippedDays. If we have SkippedDays=3, every fourth day is a day where the check is done to extend our loan and buy more BTC. In the intermittent days, it may be that we are above target, but we’re not acting yet. 

Therefore you will see on occasion that the loan CR extends (sometimes significantly) above the target CR upper limit before a buy trigger brings the CR back to the target. Since we only bought once instead of four consecutive days, we saved 4x on the transaction fees. SkippedDays=3 is the parameter value we landed on as giving the optimal trade-offs between transaction fees and returns on long-term backtesting.

Origination Fees Versus Stability Pool Rewards

While we are in the early stages of Zero roll-out and building valuable on- and off-ramps to the system, it is prudent to grow DLLR supply at a reduced pace. So, while the origination fees were originally set to 0.5% during the Zero Beta, this created a very low bar to mint new tokens. Instead, fees are currently raised to a range between 5 – 7.5% based on the demand. So far it has remained mostly at 5%. That is not surprising, because that is already a high base rate. As a result, Zero is not experiencing many new loans being taken out, and the Bitocracy goals of this adjustment are met.

In the meantime, the team has been very busy: the DLLR/RBTC AMM was launched for LPs to generate a return by liquidity mining, a lending pool is available to earn a return on DLLR, and last but not least: the stability pool is already a very attractive approach to store your value, servicing liquidations on the protocol. These are the key mechanisms that need to be in place to create a basic marketplace for the DLLR token, and it also allows our algorithm to function!

Importantly, it was also proposed and voted on by Bitocracy to launch a rewards mechanism on the Stability Pool: you can now earn >=5% (in SOV terms) on a yearly basis on your stability pool deposits! 

This made me think: can’t we balance out those returns against the origination fees to ensure long-term yields? And, since we see that both origination fees and stability pool rewards might be further tuned to maintain favorable market conditions for DLLR and the protocol revenues (like a … decentral bitcoin bank), it begs the question if these do in fact trade off against each other.

What have we covered so far?

• The StableHODL algorithm uses the Zero stability pool in a strategic way.. When liquidations occur, StableHODL sells Bitcoin to obtain the equivalent amount in burned DLLR tokens and transfers these tokens to the stability pool, keeping the profits in Bitcoin. 
• To avoid redemptions, the algorithm adjusts the Collateral Ratio (CR) target based on the Total Collateral Ratio (TCR) of the protocol. 
• On-chain transaction fees are significant, and to optimize the trade-off between transaction fees and returns, the algorithm incorporates a parameter to specify how often it checks for a possible buy (while protecting the collateral on a daily basis).
• The simulations of the StableHODL algorithm in this study use a logistic regression model to calculate returns from liquidations.

The stability pool is an attractive option for storing value, and a rewards mechanism has been introduced, allowing users to earn a percentage in SOV tokens based on their deposits in the stability pool.

Time for some numbers on StableHODL! It gets technical, so hang on. If you made it to this article at all, we are thankful even if you don’t make it to the end. 

Simulation parameters:

• Starting deposit to Zero of $10,000 equivalent in bitcoin.
• The backtesting period is from ~2013 until ~2023, comprising ~117 months.
• The algorithm has a daily “clock”, and runs checks + adjusts the loan based on that clock cycle (except for SkippedDays actions, see above discussion).
• The DLLR funds of the user in the simulation always represent a fixed 1% of the whole stability pool (i.e. total stability pool funds are assumed to grow along with whatever deposit the user has outstanding)
• A $10k bitcoin starting collateral deposit is used to reduce backtesting scope. From our testing, lower starting deposits have more trouble to reliably cover operational costs in the long run. Some lower-deposit tests are included in the appendix to this article.
• At the end of the running period, a one-time BTC sale is made to close the outstanding line of credit in case we can’t pay back from the reserve deposit alone. If any DLLR is left after paying back, it is used to buy more BTC and sent to the user's wallet.
• While in the protocol, rewards are paid out in SOV, for simplicity we assume they are paid out in DLLR since the rewards are liquid. In reality, one would need to convert (regularly) to DLLR to ensure the rewards value is marked to market in DLLR terms. The rewards are also automatically kept in the stability pool as part of the DLLR reserve, leading to compounding rewards when the reserves are not emptied for long periods.

Let’s first look at results for a single run of the algorithm so that we can understand more visually the behavior of the algorithm across many market conditions—and giving a certain confidence in the baseline.

As a starting condition, we will show the result of the algorithm assuming the current rates of 5% stability pool deposit rewards and 5% origination fees. This will be compared against other values later.

First, we see the BTC price plot (linear, top); and (logarithmic scale, bottom) the growth of (1) the DLLR-denominated value of the collateral (blue), (2) the DLLR outstanding in the open line of credit (orange) and (3) the DLLR reserves in the stability pool (yellow).

From this overview it is clear that from our initial $10K investment, the algorithm has created over $1.5M at the run’s end, a 156X gain in USD terms. That’s mostly just bitcoin doing what it does best, but we’ll come back later to evaluate this point in more depth.

Second, note the “buying power” of the algorithm. By keeping up with price increases and targeting a safe CR, we can safely grow our DLLR stack and reap the stability pool rewards.

It’s also evident that the stability pool deposit outpaces the open Line of Credit over time due to the liquidation- and reward-based gains.

Now, let’s look at the user balances over time:

• The first plot here shows the total RBTC portfolio in dark orange, including RBTC as part of the collateral deposit. 
• The blue line shows only the collateral RBTC locked in Zero.
• Light orange indicates our wallet, i.e. BTC available from stacking and liquidations. 
• Purple tracks the amount of BTC equivalent we would need to sell at a given day to close the loan. 
  If the payback required is below the wallet amount, i.e. under the yellow line, it means the loan can be closed at any date. 
  Negative required payback means we do not need to introduce external funds to pay back the loan and the loan can be paid back based on the DLLR reserves in the stability pool alone.

In the second sub-plot we show the fees and returns. These are split between accumulated transaction fees expressed in USD terms over time (blue), origination fees on Zero (orange) and accumulated DLLR-expressed returns (yellow).

‍

• From the top plot, we can see that, except before the initial liquidations, we can close the loan at any point in time. 
• The fees and returns are shown in the same plot to see how and when the algorithm is factually profitable (besides being able to exit), i.e. that the algorithm is self-sustainable and compensates its own operating costs.
• Transaction fees are included and very low compared to origination fees.

Next, we look at the collateral ratio of the loan. In the top plot in the next figure, you see the average protocol CR (orange line), the target CR the algorithm uses to “reset to” upon trigger conditions, and the actual DLLR loan CR for the user.

In the sub-plot underneath, you see the reserve ratio of the user loan, i.e. the deposits in the stability pool as a percentage of the outstanding loan. 

Notably, the reserve ratio hits 100% after about 500 days and remains above 100% throughout the remainder of the price history. Several sharp jumps are observed both up (liquidations) and down (payback to recover CR). In general, a slow incremental growth can be observed (5% YoY rewards from the stability pool deposit rewards), while major growth is a result from liquidations.

We can also see that the CR always remains above the protocol average, and hence;

1. is always safe from liquidation; and
2. is always safe from redemption since loans below the average CR will be selected for redemption first.

Given the very high origination fees, this positive result is, well, positive. The 10-year run summary:

• 1.28X linear BTC-denominated gain → 2.9% yearly average returns (in BTC)
• 174X linear USD-denominated gain → 1774% yearly average returns (in USD)
• +11.8% in absolute USD-denominated gain versus a buy-and-hodl strategy

Considering that both origination fees and rewards may be reduced in the future, let’s summarize in a table those same results for various values of origination fees and stability pool deposit rewards, as well as including and excluding liquidation yield:

Note in these results, where liquidations are included, they are identical for all simulations and not a differential factor between them. Note the liquidations in our simulation are either on or off, while in reality, liquidations are almost guaranteed during longer durations but clearly hard to predict exactly (see previous section).
The following can be deduced from this table:

• The strategy always outperforms buy-and-hodl.
• Liquidations are a significant part of the returns, much more so than the rewards. 
• Even in the most pessimistic scenario (turning off all rewards), the user was never liquidated and CR was always maintained above average protocol CR.

The backtesting period is the same, from ~2013 until ~2023.

• The whole timeline comprises ~117 months, which are tested against on that step-basis.
• Tests are performed in two ways:
  Backwards-moving: backtesting moving the start-time backwards, always ending at the same end date (=2023)
  Forwards-moving: backtesting moving the end-time backwards, always starting at the same start date (=2013)

We hope these results get you as excited as they got us! Will you StableHODL with us?

Backwards-moving testing (5% rewards, 5% origination fees)

First we show the linear gains for the USD portfolio end/start gain, expressed in %. These are shown in logarithmic format since it includes the BTC price history.

Both the StableHODL performance and baseline (Buy-and-Hodl) are shown. In all runs where the algorithm can close the Zero position, it has achieved a larger amount of BTC as an end result and hence the % gain of the blue line (StableHODL) lies above the orange line (Buy-and-Hodl).

Notably, in some occasions, the algorithm achieves negative gains in USD terms due to the falling price of BTC (not visible on a logarithmic plot). Remember the algorithm essentially “force closes” the loan at the end date of the run, regardless of price. For these negative runs, as you will see later, positive BTC/BTC gains do exist, however since the price went down in USD these plots don’t show a positive number.

Next-up are linear BTC/BTC gain in %, showing a generally increasing trend as more BTC is accumulated by the algorithm over its volatile price history. A peak of about 28% is seen for the longest run in the test, which equates to the single-run test we presented earlier.

Forward-moving testing (5% rewards, 5% origination fees)

When taking this dataset and moving forward from the fixed starting time, we always achieve positive USD-denominated % gain, since the price of bitcoin was lowest at the starting point.

The BTC/BTC linear gain now shows that no gain is achieved in the first 2 runs because the Zero loan could not be closed without external funds: no liquidations had occurred yet and the compounding rewards did not build up over time yet, hence the amount of bitcoin accumulated was too low to close the gap.

What if there were no rewards and we remained at the high 5% origination fees (backwards-moving)

This case only leans on having liquidation gains in order to produce an output.

‍What if rewards stopped but the Bitocracy voted in a reduced 2% origination fee when DLLR demand increases? (backward-moving)

‍What if rewards stopped but the Bitocracy voted in a reduced 2% origination fee when DLLR demand increases? (forward-moving)

‍What if we have different TCR behavior in the protocol: +pi/2 offset in sine wave model for TCR? (backward-moving)

‍What if we have different TCR behavior in the protocol: +¾pi offset in sine wave model for TCR? (backward-moving)

‍What if we have different TCR behavior in the protocol: +pi offset in sine wave model for TCR? (backward-moving)

‍What if we have different TCR behavior in the protocol: 150-200% amplitude in sine wave model for TCR? (backward-moving)

‍What if we have different TCR behavior in the protocol: 150-500% amplitude in sine wave model for TCR? (backward-moving)

‍What if we have different TCR behavior in the protocol: 2x frequency in sine wave model for TCR? (backward-moving)

‍What if we have different TCR behavior in the protocol: 4x frequency in sine wave model for TCR? (backward-moving)

‍What if we have a $1,000 initial BTC-denominated deposit to the algorithm? (backward-moving)
Note: negative numbers here imply a liquidation or an open loan at the end requiring external funds, which are both considered bad outcomes.

‍In this case, 13 runs did not close, and an additional 7 were liquidated.

What if we have a $5,000 initial BTC-denominated deposit to the algorithm? (backward-moving)