Initial Proposal for Haven 3.0 Development

​

It’s important to note that this proposal is a draft recommendation.
No decision about our tokenomics has yet been made and nothing is set in stone.

Everything presented in this document are ideas to be discussed futher with the community, and once an agreement has been reached, we will make another announcement.

Ever since conversions were paused, members of the Economics Working Group (EWG) have been busy working on solutions to return the Haven network to a fully functional state without opening the Haven community to further risk of hyperinflation as has been happening to the Terra ecosystem holders.

This work would have been harder and will have taken longer without input from the community.
The ideas brought forward by many of our members, and collated by xVoluntaryv in this document, have given the EWG team a basis from which to work with, which ultimately led us to the proposal being presented here.

We think that we have come up with a workable solution and we would like to open up discussions in our #havenomics channel to get feedback from the community.
These discussions will be important in refining the model and eventually come up with a functional solution.

To some, the measures proposed here may seem harsh and unfair, but we have to remember that the protocol is currently in a bad state; we must ensure that it doesn’t get worse and give the protocol time to recover.

It’s worth reminding everyone that the Vault was never intended to be used as a trading tool; we encourage everyone to trade XHV and xUSD on exchanges, which will boost adoption and increase liquidity.

Terra’s development path gave a hint, trying to use Bitcoin pools for a hybrid-backed algorithmic stablecoin before they would become too big for their stability mechanism to handle extreme exogenic shocks.

But Haven is different; the privacy aspect prevents using public blockchains, collateral and stablecoins for backing purposes.

The key issue with algorithmic stablecoins models so far is that the tokenomics design means that the stablecoin price is supported to the detriment of the native asset price.
In Haven’s case this means buying cheap xUSD to mint into XHV and then sell the XHV on the market. This creates a constant suppression on the native asset price and if the native asset price indefinitely decreases, it can result in a death spiral and a complete loss of confidence in the stablecoin.

Slightly counterintuitively, a tokenomics design that doesn’t prioritise the stablecoin price and instead protects the native asset price has greater longevity as an ecosystem and therefore greater trust in the value of the stablecoin.

So the EWG team came up with a novel idea; Haven is doubling down on “being your own bank” and will be requiring collateral in the form of XHV to use the shoring function.

The new idea can be summed up in one sentence:

To Onshore/Offshore, you have to have the equivalent value of unlocked XHV in your vault.

We call this idea Vault Backed Shoring, or VBS. It is intended to provide liquidity limits for using the shoring function, determined by every user themselves.

With this new collateral requirement, which will lock both the collateral and the minted coins for an extended period, shoring users will constantly be exposed and linked to the volatility of the base collateral while they are actively changing the protocol supply numbers.

They will not be able to use the shoring function if they sell their XHV collateral and don’t hold XHV in their vaults, preventing them from completely “opting out” of the volatile system while the community pays the opposite position with increased inflation.

In short, Vault Backed Shoring is intended to work as both a speed brake and a requirement for skin in the game for users of the shoring function.

NOTE: VBS will only be required for participants that use the shoring functions (XHV <-> xUSD), not standard XHV or xAsset transfers.

Onshoring example:

To convert 100 xUSD into XHV, you need to have at least $100 worth of XHV in the vault, unlocked.
This $100 worth of XHV (known as collateral) will be locked for the duration of the conversion along with the funds being converted.

If the current price of XHV is $0.50, this means that you need to have at least 200 XHV (unlocked) in your vault in order to onshore 100 xUSD.
After successful conversion using this example, you will have 400 XHV locked for a period of time (see proposed lock times further below).

Offshoring example:

To convert 100 XHV into xUSD, you need to have at least the same amount of XHV (100 in this case) in the vault, unlocked.
This means that you can only ever offshore a maximum of 50% of the XHV held in the vault, providing none of the XHV is locked.

Proposed lock times for VBS

Both the funds and the collateral requirement will be locked for 21 days.

If the user does not hold enough collateral to onshore in a single conversion, VBS slows the onshoring process by requiring an onshorer to go through multiple cycles of onshoring, and each onshore takes 21 days to complete.

To illustrate this, here are a couple of scenarios showing how many cycles and how long it would take to onshore the full amount of xUSD held in a vault.

The first example is using a starting amount of 10k XHV, and the second example is using a starting amount of 100k XHV.
Both examples use a 1:1 collateral, meaning that the most you can onshore at any given time are the maximum amount of unlocked XHV you have in the vault.
In Part 2 of the proposal, we will see that the collateral will change based on the state of the protocol.

It’s easy to see that the more unlocked collateral you have in the vault, the fewer cycles you will need to fully convert all of your xUSD back to XHV.

The next couple of scenarios are using an increasing and decreasing XHV price, respectively.

From this, we can see that with an increasing price in XHV, fewer Onshore cycles are required, but you end up with less overall XHV than you would have, had you been able to onshore all of the xUSD in one conversion.

Conversely, as the price of XHV decreases, more Onshore cycles are needed to convert all of the xUSD, but you end up with more XHV.
Although this looks like it’s inflating the protocol, these scenarios do not take into account the state of the protocol, which will prevent the type of inflation seen above.
This takes us to the next part of the proposal.

The first part of the proposal was describing the novel idea around VBS, and how it would be implemented.

On its own, however, VBS will not necessarily stop inflation, especially as the price of XHV decreases over time, it will only lengthen the time required to inflate the protocol.

Therefore, other measures are required in order to counteract uncontrolled inflation and whale manipulation.

Market Capitalization Ratio

As many community members will have already noted through discussions in our havenomics channel, one of the best ways to measure the health of the protocol is by using a ratio of the combined Total Offshore Assets market capitalization (TOAMcap) and the XHV market capitalization (XHVMcap).

This is simply calculated as:

The lower the number, the healthier the protocol, and vice versa.
Although a subjective data point, a very good ratio is considered to be when XHVmcap is 10 times that of TOAMcap, i.e. 0.1 using the formula above.

At the time of writing (23 June 2022), the circulating supply of XHV is ~28.3 million with a market capitalization of $16 million (using the KuCoin price of $0.567).
The Total Asset market capitalization stands at ~$16 million.
So the mcap ratio we have right now is almost exactly 1, which is considered to be a bad ratio and therefore an unhealthy state of the protocol.

Combining mcap ratio with VBS

An unhealthy state of the protocol can be arrived at in the following ways:

• continued drop in XHV price
• very large, single conversions
• too much offshoring
• too much onshoring, which can lead to sell pressure on the open market
• any combination of the above points

If we combine the state of the protocol (mcap ratio) with our VBS model, we can further limit the shoring mechanism to ensure the system doesn’t swing too much towards an unhealthy state.

The way we propose to do this for Onshores and Offshores are different.

ONSHORES

For Onshores, we will increase the collateral needed as the mcap ratio increases, which means that you need to have more XHV in your vault for the same amount of xUSD when the protocol tends towards a bad state.

Let’s assume that the ratio is at 0.5, the protocol is heading towards an unhealthy state. This means that you will no longer be able to use a 1:1 collateral to onshore your xUSD.
A dynamic calculation for this ratio could have arrived at a 1:3 collateral, meaning that you would need to have 3 times as much XHV in your vault as the amount of XHV you are trying to onshore.

To better visualize this, let’s use the same scenario from before: starting XHV amount of 10k with a constant price, but this time with a 1:3 collateral.

With a 1:1 collateral from the previous example, we would have needed 7 onshores to fully convert all the xUSD to XHV.
With a 1:3 collateral, as above, the number of onshores has increased to 17, requiring an entire year to convert all the xUSD to XHV.

Let’s also compare the same scenario, but with a starting XHV amount of 100k.

Previously, with a 1:1 collateral, it would have taken 4 onshores (84 days) to convert all of the xUSD.
With a 1:3 collateral, it has increased to 9 onshores, or 189 days.

Of course, these scenarios are quite unrealistic in the real world; it’s impossible to predict market and price fluctuations, fundamentals, sentiment, conversion tactics, etc.

The conclusion we can draw from this is that as the state of the protocol increasingly worsens, so does the amount of collateral needed to convert xUSD to XHV, which in turn increases the number of cycles and the time taken to onshore the full amount.

OFFSHORES

For Offshores, the current concept is to keep the collateral at 1:1, but we will be increasing fees as the mcap ratio increases. Furthermore, we will also add slippage fees for larger conversions which would take the state of the protocol from good or bad to worse.

NOTE: The reason we are not considering fees for Onshores, other than standard conversion fees, is because it is believed that this would depeg xUSD, which could create a downward spiral of the price in the open market.

Offshore – Conversion Fees

We believe that it is in the best interest of the protocol to burn the majority of the fees in order to keep inflation under control, but also leave enough fees for the operational cost of the project, plus wages.
For the purpose of this proposal, we are assuming a minimum of 0.5% in fees for the treasury, with any surplus being burnt.
Exact figures will be agreed upon at a later stage.

To calculate the conversion fees, we will use a simple exponentiation operation between the mcap ratio and a number which is 2 or very close to it, +/- a few decimals.
If the number is too high, the calculation will become exponential too quickly, which would make this unusable.

To illustrate this, consider the following example, where we are simulating various levels of mcap ratios with 4 different levels of exponents: [1.6], [1.8], [2] and [2.2]
We are also setting a minimum (0.5%) and maximum (80%) in fees, with 0.5% going to the treasury and the rest being burnt.

As the ratio increases and the state of the protocol worsens, fees for any offshores will be increased accordingly.
The idea behind the high fees is not to punish users but to discourage them from moving the protocol towards a bad state, and to protect against uncontrolled inflation by burning a large portion of the fee.
 

Offshore – Slippage Fees

Slippage fees are an additional measure to catch large conversions which would worsen the state of the protocol with a single conversion.

We would add slippage fees to the standard conversion fees as calculated above. Basically, slippage fees are the fees after a potential increase in the ratio which is added to the standard conversion fees.

Here’s an example where the ratio is in a good state before an offshore, but after a single conversion by a whale, it takes it into a bad state.

Other Considerations

Is the Market Cap ratio enough to calculate the state of the protocol?
The answer is no.

There is something else to be considered that we haven’t mentioned yet; the spread ratio between TOAMcap and XHVMcap.

The state of the protocol we are in now, i.e. unhealthy, means that we won’t have many conversions going through the system because it’s either too expensive, or it would take too much collateral.
This however could change as soon as the price of XHV rises to a level where the market cap ratio becomes favourable for onshores.

As people start to onshore and the price of XHV rises, the spread between TOAMcap and XHVMcap widens more quickly, which incentivizes more onshores, inflating the supply.
This could carry on until all the xUSD has been converted to XHV and the circulating supply of XHV would have been greatly inflated.

To counter this, we could work out the spread ratio between the two caps against the XHV price, and if the spread becomes too large, we could apply similar restrictions to conversions, even when the market cap ratio is in a good state.

The simulation chart below shows how this might be calculated.
When the market cap ratio is low (healthy state – blue line), but the spread ratio is high (green line), we could increase the collateral for Onshores and increase fees for Offshores.

To recap, we are proposing the following measures

OFFSHORING

1. VBS with 1:1 collateral, plus Lock time (21 days proposed).
2. Mcap ratio to determine fees based on the state of the protocol.
3. Slippage fees depend on size of the offshore and the state of the protocol after a potential offshore.
4. Spread ratio fees.
5. Applies to XHV -> xUSD conversions.

ONSHORING

1. VBS with lock time (21 days proposed).
2. Minimum collateral of 1:1, and maximum 1:3 or 1:4 (to be discussed).
3. Collateral to be determined by the state of the protocol.
4. Collateral to be determined by the spread ratio.
5. Basic conversion fees.
6. Applies to xUSD -> XHV conversions.

The key takeaway in this proposal is that discussions and feedback from the community should centre around the new idea, VBS.
We would really like to know what you think and if you see any glaring issues in this model.
 

There is significant development work with what we are proposing and whilst the dev team scope this out, we want to take the time to hear the community feedback on this proposal, in particular the novel approach of VBS.

Members can most effectively discuss this in the #havenomics channel. ​