Haven 3.0 Tokenomics Proposal (light) – Haven Protocol XHV

To view the full proposal, click here.
You can also download a PDF version of the full proposal from here.

Overview

Over the past few months, the Economics Working Group (EWG) has worked in close coordination with the Haven devs to produce a proposal for a specific implementation for the Vault Backed Shoring (VBS) proposal that was approved by community vote on 7 July 2022.

At the top of this page is a link to the full 32 page PDF proposal from the EWG to the community. It explains the circumstances that led us here, the theory behind VBS, our proposed formulas and simulations of it in action. It is a mildly technical document and we encourage everyone to read through it to the best of their ability. However, this blog post will be a summarised version intended for more non-technical readers.

Haven Protocol is currently in an unhealthy state because the protection provided by previous configurations of Haven’s offshoring/onshoring mechanisms were insufficient. Our previous tokenomics focused on trying maintain the market price of xUSD towards $1 but it did so at the expense of the XHV price. This was expoited by various parties which caused significant inflation and eventually led to an impending death spiral of the XHV price. This crisis was averted by the EWG’s decision to halt conversions in June 2022 because the actions of general users and, in particular, large whales were on course to destroy the protocol.

In the following weeks and through many hours of debate, the EWG came to the conclusion that it was too easy to benefit from the unlimited liquidity that the shoring functions offered and whilst also to be protected from the negative effect on the XHV price. In our discussions, we realised that all other algorithmic stablecoins had focused on maintaining the stablecoin price rather than the price of the asset supporting the stablecoin and therefore had made a fundamental mistake. Enter VBS.

VBS requires a would-be off/onshorer of XHV to hold a collateral amount of XHV to perform the off/onshore. If a user wants to offshore x amount of XHV, they must seperately hold y amount of XHV that will be locked for the duration of the conversion. Vice versa, if a user wants to onshore b amount of xUSD, they must seperately hold c amount of XHV that will be locked for the duration of the conversion. Specific numbers will be covered further down.

The purpose is to make everyone who wants to utilise the off/onshore functions to be exposed to the XHV price and therefore, the health of the Haven Protocol ecosystem. For example, if a user wants to onshore their offshored xUSD at a later date, they must retain an XHV balance or purchase XHV on the market before they can complete a round trip.

Alongside VBS, we are proposing three other changes that are designed to help protect the protocol and the sustainability of the project:

Lock times
Conversion fees
A cap on the amount that can be converted in each block

The lock times and conversion fees are the simplest so we will cover them briefly before moving onto the VBS collateral requirement and the conversion shoring cap per block.

Lock Times

Lock times provide a delay to how quickly funds can be off/onshored and then be available to be sold on the market or off/onshored. The VBS collateral required for a conversion will also be locked for the same length of time that converted funds are locked for.

The lock times we are proposing are 21 days for both, offshores and onshores.

Conversion Fees

Originally, we have proposed a model where dynamic fees would be used as a measure to protect the system. However, this was untenable for a number of reasons. Instead, we are suggesting 1.5% for Offshores and 1.5% for Onshores. The fees may seem high, but with the treasury being depleted and limited funds through greatly reduced percentage in volume for conversions once VBS is implemented, we have to make sure the project receives enough funds to sustain its operational costs.

The current xUSD < > xAssets conversion fees are 0.5% per conversion, of which 0.4% are burnt and 0.1% are evenly split between miners and the governance wallet.

In order to ensure the protocol receives enough income through conversions, we would like to make the following changes:

xUSD < > xAssets Conversion fees to be increased to 1.5%
1.2% would be sent to the governance wallet
0.3% would go to miners (increase from 0.05%)

The fees will be revised on a regular basis.

VBS

The main question is exactly what amount of collateral should be required to perform a shoring function? There are three key factors to consider:

The amount a user wants to off/onshore
The current health of the XHV ecosystem prior to the off/onshore
The potential inflation/future health of the XHV ecosystem after the off/onshore

Through historical data analysis and modelling potential future scenarios, we quickly realised that the collateral requirement ratios in the initial proposal would not provide adequate protection. The end goal is to have a system that is easy to use, requires little collateral when the system is healthy but protects against severe inflation when the protocol is in danger.

Considering our current unhealthy state, this is challenging and as we are breaking new ground, our current proposal is conservative to protect the protocol. We can refine the formulas to be more user-friendly in the future once we have achieved some stability.

There are three key components used in our VBS collateral calculations:

Market Cap Ratio – The ratio between the value of XHV and xAssets in circulation
Spread Ratio – A measure of the “distance” between XHV market cap and xAssets market cap
Slippage – The impact that a transaction will have on the state of the ecosystem

The specific formulas are up for discussion amongst the community and can be found within the proposal document. Below we will sumarise these in as non-technical way as possible and provide examples.

The total VBS collateral requirement is:

Market Cap or Spread Ratio VBS + Slippage VBS

The first part calculation initially depends on whether it is an off/onshore:

Offshores – Market Cap Ratio
Onshores – The greater of the Market Cap Ratio & the Spread Ratio

The Market Cap Ratio will use two seperate functions that cover seperate ranges of the market cap ratio. We are proposing that below 0.9 mcap ratio, a less agressive formula is used to enable easier use of the system and above 0.9 we use a more exponential formula that causes the collateral requirement to rise sharply.

The Spread Ratio is required as extra protection for onshoring only because as people onshore, the supply of XHV rises, decreasing the mcap ratio, reducing the collateral requirement and creating greater possibility for inflation.

For onshores, we use the worst of two VBS values between mcap and spread ratio, which means we get protection across the entire range of the market cap ratio.

The table below is showing VBS values for a range of mcap and spread ratios, and their corresponding, calculated VBS values. The last column shows the actual VBS value used for Onshores, which is the higher VBS of the two, Mcap and Spread VBS.

Slippage

In order to avoid the market cap ratio increasing too quickly (getting worse) through single, large conversions, we have to add slippage in the form of VBS to the Initial VBS, which is derived from the initial state of the protocol. This will limit whales converting very large amounts with infinite liquidity.

The slippage is calculated differently for offshores and onshores.

For Offshores, we take the percentage increase of the Market Cap Ratio based on how much is being converted.
For Onshores, we take the percentage increase of the Spread Ratio.

The specific formulas are detailed in the proposal document. Due to onshores already requiring additional VBS requirement comapred to offshores, the offshore slippage VBS will be more significant. To show what these numbers might look like, we have included a table below with our suggestion. Like with the Market Cap Ratio, we use a different multipler when the system is in a healthy state (3x when mcap ratio < 0.1) compared to an unhealthy state (10x when mcap ratio > 0.1).

Conversion shoring cap per block

The protection provided by the VBS measures above does leave an attack vector where a sophisticated user could split up a large conversion into many smaller conversions that are processed within the same block. This would avoid Slippage and any changes to Market Cap or Spread Ratios and present them with a more favourable VBS than the system is designed to do.

Our proposed solution to this is a per block cap on the amount of XHV that can be off/onshored. This cap will be dynamic and depend on the market cap of XHV. The specific formula outlined in the proposal document has been chosen to limit the impact on regular users. Below is a table of what the cap would be at various XHV market caps.

Simulation

To help put this into context, we have created three simulations in the proposal document. We have included one below and welcome suggestions for scenarios that we can model. You will find details of how to propose the simulation in the proposal document.

What if VBS was already in place when XHV reached a low of $0.42 back in June 2022, and our xUSD whale started onshoring as much as the system would allow him?

The biggest assumption here is a starting collateral of 500k XHV.

As you can see, in the last 126 days, the whale could only have onshored 76k XHV, due to the bad state we’re in, and a corresponding high VBS.

This is assuming that the whale wouldn’t have bought or sold any XHV during that time, and that price remained within this range.

In Summary

To recap, we are proposing the following measures for the Haven 3.0 tokenomics:

Generic shoring measures

21 days lock time for all XHV < > xUSD conversions
Minimum VBS = 1
No maximum VBS
Shoring cap per block
1.5% fees for all XHV < > xUSD conversions
1.5% fees for xUSD < > xAssets conversions, with 1.2% going to the gov wallet and 0.3% for miners
xAssets conversion unlock times to remain at 48 hours
VBS applicable to XHV < > xUSD conversions only

Offshore specific measures

Variable VBS based on the Market Cap Ratio of XHV and xAssets
Variable Slippage VBS based on the increase of the Market Cap Ratio
Max Offshore functionality

Onshore specific measures

Variable VBS based on the worst (higher) VBS between the Market Cap Ratio VBS and Spread Ratio VBS
Variable Slippage VBS based on the increase of the Spread Ratio
Max Onshore functionality

This is by far the most complex proposal we have published to date, and also the most complex tokenomics we are trying to implement.

Members of the Economics Working Group will be available to answer any questions you may have, but please take the time to read and re-read the proposal in order to get a good understanding. Many questions will have already been answered in this proposal.

Thank you all for your incredible patience and support during these challenging times.