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

Overview

Several months after the initial proposal, we, the Economics Working Group, are finally ready to present to the community the next major development in Haven’s tokenomics life cycle, Haven 3.0.

Before we start describing the proposal in detail, let us look at the preceding versions to find out what led us to this point.

Haven 1.0

July 2020 marked the beginning of the first private algorithmic stablecoin after the highly successful launch of xUSD, using coloured coins technology based on Monero code.

But even before Haven 1.0 got off the ground properly, it was subject to immediate attack and manipulation by some bad actors with large holdings of XHV, who managed to circumvent the fee structure.

This resulted in an immediate revision of Haven 1.0 with the following measures put in place:

A 24 hour Moving Average (MA) for the XHV/USD price quoted by Chainlink.
A priority system with 4 different lock times and fees for Offshores and Onshores:
6 hours and 20% fees
24 hours and 10% fees
48 hours and 5% fees
7 days and 0.2% fees

Initially this worked well, especially during the uptrend that followed, where the protocol saw some deflation, but flaws in the system were soon exposed as the trend in the market started reversing. This was worsened by the subsequent exploits that followed.

Haven 2.0

The exploits that took place in June 2021 forced Haven to halt conversions and roll back the chain. A long process of rebuilding the conversion code base began, which was completed by November 2021 and audited by Cypher Stack, a company led by skilled Monero developers.

After the launch of Haven 2.0 and upon conversions being enabled, the protocol started seeing a steady inflation of the XHV supply as users who offshored after the last major pump to $20 (prior to the launch of Haven 2.0), were beginning to onshore at much lower prices.

The 24h MA allowed anyone to see a future price of XHV on exchanges compared to the price inside the vault, which gave users an advantage and the opportunity to convert between XHV and xUSD before the price in the vault started moving towards the spot price. Even with higher fees of 10% and 20%, users managed to inflate their own bags (and the overall supply), since price fluctuations exceeded well beyond the maximum of 20% in fees.

The ever-increasing inflation of the XHV supply had not gone unnoticed by our community, contributors and developers; there was an urgent need to do something about it.

Haven 2.2

Haven developers were already planning a fork in Q1 of 2022 to reduce the unlock time on any change given during a conversion, to just the standard 10 blocks. More information about this can be found here.

As part of that fork, the Economics Working Group were tasked to come up with an interim solution that would stop the quick inflation until a more permanent solution could be found.

The measures put in place for this version of the tokenomics were:

Change XHV and xUSD unlock times to an asymmetric model and eliminate priority options.
Offshore (XHV to xUSD): 21 days
Onshore (xUSD to XHV): 12 hours
Streamline conversion fees to a flat 0.5% for all conversions.
Eliminate delta advantage between spot and MA price for XHV <-> xUSD conversions.

More information on the 2.2 tokenomics proposal can be found here.

Although the fork and tokenomics updates were successful, it didn’t stop the inflation. Things got worse after the market took a turn for the worst in April 2022, and the XHV pump to $8 was sold off very quickly.

By the end of May 2022, the virtual supply of XHV was at an ATH, over 45 million, as can be seen on the chart below.

During the same period, the price of XHV reached an ATL (All Time Low) on KuCoin and this is when the next attack on the protocol started. A sustained and systematic sell event began when large amounts of xUSD were being converted to XHV and market sold on exchanges. The price went below 50 Cents and it was clear that this was not going to stop, as there were still over 15 million xUSD in circulation, ready to be deployed to create a death spiral for XHV, with a projected circulating supply reaching hundreds of millions.

A decision by the Economics Working Group to stop conversions was acted on in early June 2022. Shortly after, a conversion poll was put forward to the community that would decide to either re-open conversions immediately or to re-open them when it was safe to do so. Thankfully, the community voted in favour of keeping conversions paused.

Since then, we have been trying to come up with a solution to Haven’s tokenomics challenge.

The group now had an additional problem to solve: how to prevent a death spiral from happening with over 15 million xUSD waiting to be onshored and sold on the market, and at the same time enable conversions for everyone.

This brings us to the present day.

Haven 3.0 (Proposal)

The groundwork for this proposal was laid in our initial proposal, and it revolves around the brilliant idea of VBS. As we will see, VBS remains central to the tokenomics proposed here.

With help from developers and community feedback, we have come up with a model that we believe will provide the necessary protection against high inflation, with a much more controlled mint & burn process that will allow for a more organic growth of the protocol and a more balanced system between inflation and deflation.

Vault Backed Shoring (VBS)

By now, the term VBS will be familiar to most, but it is worth reminding ourselves of the key facts before we delve into its application.

VBS key facts:

To Onshore or Offshore, one has to have a given amount of unlocked XHV in the vault.
We call this Collateral.
For Offshores, we use the amount of XHV that needs converting to work out the collateral, irrespective of the price of XHV.
For Onshores, we use the dollar value of XHV to work out the collateral, based on the MA/Spot price of XHV.
VBS will only be added to shoring functions (XHV <-> xUSD).
Some community members suggested having VBS implemented on other volatile offshore assets such as xBTC, xAU and xAG.
If it proves successful, we will look at the possibility of extending VBS across other assets.

Proposal changes

The idea of VBS hasn’t changed since our initial proposal, but the process by which it is applied has been further developed and redefined, with some key differences.

Let us first remind ourselves of the main points from the initial proposal:

OFFSHORING

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

ONSHORING

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

When we started looking at the suggested collateral requirements and putting numbers through various scenarios and simulations, we realised that these were not nearly high enough, and quick inflation would be inevitable.

We also found that slippage fees wouldn’t just affect large conversions, but regular sized ones as well. While our protocol is relatively small, even moderate conversions can contribute to larger changes in the market cap ratio, which would penalise regular users with very high fees, in excess of 50% in some cases.

As much as we’d like to see fees burnt, it would seem unfair to do so to users who support the protocol and have no intention of causing harm. High fees would also limit the number of users who would be able to use the system. When the protocol has grown sufficiently, we will be revising the fee structure again.

Therefore, we are proposing that instead of slippage fees, we increase the amount of collateral relative to the size of the amount being shored. This means that no one would lose their tokens while at the same time it would prevent large shores to cause quick and damaging inflation.

The main changes since the initial proposal are:

We are dropping fees for slippage, mcap and spread ratios, and only keeping the standard conversions fees.
We are introducing a variable and dynamic VBS for offshores and onshores, with a minimum VBS of 1, but no maximum. The level of VBS will depend on the state of the protocol.
For offshores, slippage fees are replaced by an increase in VBS.
Shoring cap per block (see details later in the report).
We are setting a minimum amount of XHV that can be onshored or offshored. This will be 1 XHV.

Tokenomics application

From a high level perspective, we have four main areas that will govern the implementation of the new tokenomics.

These are:

VBS
The amount of collateral required to perform a conversion will depend on many factors such as conversion type (Onshore or Offshore), amount being shored, amount of unlocked XHV/xUSD in the vault, price of XHV, market cap ratio, spread ratio and slippage.

VBS is the most complex part of our tokenomics and the next chapters will explain in detail how VBS is calculated and applied.
Lock times
Given the state the protocol is in right now, we should not consider short lock times at this time.
Therefore, we are proposing a 21 day lock time for offshores and onshores.

Lock times will be applied to the funds being converted and the corresponding collateral.
Conversion Fees
Conversion fees will have a fixed rate.
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.
Conversion shoring cap per block
It will be necessary to cap the amount of XHV being shored in a single block.
The reason for doing this is so that large conversions cannot be split into smaller ones in order to avoid slippage. Splitting large conversions would also avoid a possible increase in the mcap or spread ratios before the next block, which would give the shorer a better VBS value than intended by the system.

The cap will be dynamic and it will depend on the market cap of XHV. The calculation for this will be shown in a later chapter.

A possible drawback for introducing such a limit will be if too many people try to shore funds all at once, which would exceed the total allowable shore amount. This means that certain users will have their transactions rejected by the daemon.

The solution would be to keep trying (waiting for the next block) until the transaction goes through.
This would usually happen when there is a sudden change in the market or the price of XHV, and many try to shore their funds at the same time.

Collateral

If you’re not familiar with the initial proposal and the concept of collateral, it can easily be explained with a few examples.

Offshore

If you want to offshore 10 XHV and the VBS is set to 1:1, you will need 10 XHV as collateral, which means you need to have at least 20 (unlocked) XHV in the vault in order to offshore 10 XHV.

If the VBS is 2:1, you will need twice as much XHV as collateral, i.e. 20 XHV in order to offshore 10 XHV, so 30 XHV in total.

Onshore

Assuming a collateral of 1:1, if you want to onshore 100 xUSD and the price of XHV is $0.50, you need to have at least 200 (unlocked) XHV in the vault.
That’s because 100 xUSD ÷ 0.5 = 200 XHV (the amount of XHV you want to onshore).

With a collateral of 2:1, you need to have double the amount, i.e. 400 (unlocked) XHV using the above example.

The total collateral needed for conversions will depend on the current state of the protocol and the shoring type used. There are four such shoring types in the proposed VBS model.

Specific amount of XHV a user wants to offshore.
Maximum amount of XHV that can be offshored.
Specific amount of xUSD a user wants to onshore.
Maximum amount of xUSD that can be onshored.

Each of the above shoring types will have a different formula, therefore calculated in a different way.
Working out the maximum offshore and onshore amounts is more complicated because of the introduction of slippage and exponentiation in the VBS calculations.

There isn’t a single formula that can work out the exact value for the maximum amount that can be offshored or onshored based on the amount of unlocked XHV available in a vault, so we have to resort to other methods in order to work out an approximation of the collateral needed. This approximation can be defined to a certain level of accuracy, the level of which will depend on the process used for the calculation.

Being able to work out the maximum amount that can be shored means that it might finally be possible to include a “Max” button for shoring functions. Before you fall off your chair, this will need to be confirmed by our developers. We will update this section once we have more information.

VBS basics

In order to understand how the main shoring functions are calculated, we need to define the basic, underlying formulas used within these function.

XHV market cap

XHV Mcap = XHV Market Cap
XHV Supply = XHV Circulating Supply
XHV Price = Current price of XHV inside the vault

NOTE: The price of XHV used to calculate the market cap would be the same as that used in Haven 2.2, meaning you get the worst of the two prices, which ensures that price cannot be manipulated easily.

Going Offshore, we use the lower of the spot or MA price.
Going Onshore, we use the higher of the spot or MA price.

Market cap ratio

Mcap Ratio = Market cap ratio
xAssetsMcap = Dollar value of the Total Offshore Assets market cap (includes xUSD, xBTC, xAU, etc.)
XHV Mcap = XHV market cap, which was calculated in the preceding formula

A ratio of 0.1 or less is considered to be good because the XHV market cap is at least 10 time larger than the xAssets market cap, which means there is plenty of collateral to cover all the xAssets.

Our current market cap ratio is somewhere between 1.3 and 1.5 depending on price of XHV, which is very bad, and will only be considered good again when the price of XHV exceeds $4.

Spread ratio

The ℤab-Klein theorem

SpreadRatio = A measure of the “distance” between XHV market cap and xAssets market cap.
McapRatio = Market Cap Ratio (see above for the formula)

Note: When the Spread Ratio goes negative, it will be set to zero, and it will no longer be relevant because at that point the market cap ratio is going to be used to work out a value for the VBS.

Market Cap Ratio VBS calculation

The value of VBS is function of the market cap ratio, and we are going to use exponentiation functions to derive the value.

In order to make this fair (for when the state of the protocol is good) and to be protective at the same time when the state of the protocol is considered bad, we’re going to use two separate functions to cover two ranges of market cap ratio without suffering from rapid exponentiation.

When the market cap ratio is below 0.9, the following formula will be used to work out the VBS:

When the market cap ratio is at 0.9 or above, the formula for the VBS will be:

Mcap VBS = The value for the Market Cap Ratio VBS
McapRatio = Market Cap Ratio (as defined earlier)
MR multiplier = Mcap Ratio Multiplier, a value used to get the desired VBS

The Market Cap Ratio Multiplier is a number that will bring the VBS value within a desired range for a given market cap ratio. The multiplier we have chosen is 40, because it provides a good continuation of the preceding VBS values after the ratio climbs over 0.9.

The exponentiation of VBS will prevent a death spiral scenario, where a perpetual decline in price could lead to an onshore -> sell event, driving the price even lower.

The table below is showing the calculated VBS values for a wide range of market cap ratios.
As stated previously, the minimum VBS is set to 1, but there is no maximum.

Chart showing how VBS grows with a rise in mcap ratio

Spread Ratio VBS calculation

The spread ratio only applies to Onshores.

To remind ourselves, the spread ratio is the measure of distance between the Total Offshore Assets market cap and XHV market cap.

As people start to onshore and the price of XHV rises, the spread between xAssetsMcap and XHVMcap widens more quickly, which incentivizes more onshores, thereby inflating the supply. This needs to be controlled with a higher collateral.

The VBS calculation for the spread ratio has been updated recently after some valid points were raised in our discord channel (see announcement).

The latest formula for the Spread VBS ensures that values are now in a strictly ascending manner, and also more protective towards an unhealthier state of the protocol.

The formula for the Spread Ratio VBS is:

Spread VBS = Spread Ratio VBS value
Spread Ratio = Spread Ratio, a measure of distance between XHV and xAssets market caps
SR multiplier = Spread Ratio multiplier, a value used to get the desired VBS

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.

Note: The Spread Ratio cannot go above 1 or below 0.

Slippage VBS calculation

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 different 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.

Once the Spread VBS is calculated, it will be added to the Initial VBS, which would give us an overall value for the collateral.

Therefore,
Total VBS = (Mcap or Spread) VBS + Slippage VBS

Offshore Slippage formula

The formula for the Offshore slippage VBS is:

Slippage VBS = VBS for Offshore Slippage
Mcap Ratio Increase = A measure between initial mcap ratio and post-offshore mcap ratio
Slippage Multiplier = Slippage Multiplier, a value used to get the desired VBS

Here we will be using two different multipliers to get the desired level of VBS.

If, after a given amount of offshore, the resulting protocol is in a good state, numerically defined as having a market cap ratio of 0.1 or lower, the multiplier will be set to 3, and if the post-offshore market cap ratio is above 0.1, the multiplier will be set to 10.

Putting this into practice, if the Mcap Ratio is at 0.1 and a large conversion would increase the ratio to 0.12, that’s an increase of 20%, or 0.2 in decimal format.

Therefore, Slippage VBS = SQRT(0.2) * SlippageMultiplier

Using an example to see how this affects the VBS, let’s assume the price of XHV is $10, this would make the current mcap ratio equal to 0.067.

According to the table posted above, the offshore VBS at that ratio would be around 1.3.
If you were to offshore 200k XHV at a price of $10, it would increase the Mcap Ratio to 0.072. This corresponds to an increase of 7.5%, which, according to the table below would add an additional VBS of 0.82, making the total VBS equal to 2.12.

The table below shows various levels of Mcap Ratio increases using the low and high VBS multipliers we have defined earlier.

Onshore Slippage formula

The formula for the Onshore slippage VBS is:

Slippage VBS = VBS for Onshore Slippage
SpreadRatio Increase = A measure between initial spread ratio and post-onshore spread ratio
Slippage Multiplier = Slippage Multiplier, a value used to get the desired Slippage VBS

The slippage multiplier is the same as that for offshores, 3 or 10, depending on the state of the protocol.

It’s worth noting that the Onshore slippage will mostly be small. The reason for this is that during onshores, we derive the initial VBS from either the Mcap Ratio or the Spread Ratio, whichever is worse. Due to the higher VBS value, less can be onshored, so the spread ratio is not going to very significant.

Offshore functions

Now that we have described the basic functions, we can start defining the main shoring functions.

A collateral of 1:1 means that the amount of XHV being shored will require an additional amount of unlocked XHV equal to the shoring amount available in the vault.

When working out the VBS collateral, we will be using decimal values, so a 1:1 collateral will be represented as 1 in decimal format.

For a collateral of 2:1, we will need twice the amount of unlocked XHV as that being shored, which is 2 in decimal format.

Specific Offshore function

The Specific Offshore function calculates the amount of unlocked XHV a user needs in order to offshore a specific amount of XHV.

For example, if you want to offshore 100 XHV and the VBS is equal to 3, you will need to have an additional 300 unlocked XHV in the vault, 100 XHV for the offshore and 300 XHV as collateral.

In its most simplified form, the formula to work out the collateral needed to offshore a specific amount is:

Collateral = Amount of unlocked XHV (does not include the amount of XHV being offshored)
XHV = Amount of XHV to be offshored
VBS = This is the sum of the Initial VBS and the Slippage VBS, expressed as a decimal value

To visualise how VBS is calculated, we’re going to expand the function into its individual constituents.

Max Offshore function

The formula for working out the maximum amount of XHV that can be offshored is:

Max Offshore XHV = Maximum amount of XHV that can be offshored
Unlocked XHV = Total amount of unlocked XHV in the vault
VBS = decimal value of the collateral, which is made up of the mcap VBS plus the slippage VBS

If it wasn’t for slippage, we could use the formula directly to work out the maximum amount of XHV one can offshore.

Let’s look at an example to check if this is true.
If you have 300 unlocked XHV in the vault and the VBS = 2, then the max offshore amount, using our formula, is:

Max Offshore Amount = Unlocked XHV / (VBS + 1) = 300 / (2+1) = 100 XHV (max amount you can offshore)

Now let’s do the reverse and use the Specific Offshore function to see if the amount of collateral we need for 100 XHV with a VBS of 2 is going to be 300.

Collateral = XHV Amount * VBS = 100 * 2 = 200 XHV
Total unlocked funds required = XHV Amount + Collateral = 100 + 200 = 300 XHV

This proves that both functions are the same, only rearranged to work out different values.
So what’s the issue with working out the max amount when we introduce slippage?

The issue is that we’re using exponentiation (the Square Root) to work out the VBS for the slippage (see Slippage VBS Calculation). The more unlocked XHV you have in the vault and the lower the Mcap Ratio, the less accurate the function becomes.

When the max offshore amount is large and the mcap ratio is small, the increase in the mcap ratio due to the slippage is large, which will give a higher Slippage VBS value. When this is added to the initial VBS, it will produce a higher overall VBS, which means that max offshore amount will falsely present the user with a lower amount they can offshore (due to requiring more collateral).

This wouldn’t be fair, or correct, since if they used that same amount in our Specific Offshore function, the amount of collateral they needed would be lower, because the slippage itself would be lower and hence the overall VBS. This means they could actually offshore more XHV than the Max Offshore function is telling them.

The way this is solved is programmatically, by using the initial value derived from the Max Offshore function and then finding an approximate max offshore value, which is closer to the available collateral. This approximation can be defined to a certain degree of accuracy, but depending on what process developers adopt, the accuracy could range from a fraction of a percentage to a few percent, in order to work out the actual offshore amount.

We’re now going to expand the Max Offshore function, similar to how it was done for the Specific Onshore function.

Here, McapRatio is the simplified expression for (xAssets Market Cap / XHV Market Cap).

Onshore functions

The onshore functions are more complex to calculate because we are using the Spread Ratio and because we have two sets of currencies we need to work with, XHV and xUSD.

Specific Onshore function

The simplified formula to work out the collateral needed to onshore a specific amount of xUSD can be expressed as:

Collateral = Amount of unlocked XHV required as collateral
xUSD = The amount of xUSD being onshored
XHV Price = Current price of XHV inside the vault
VBS = This is the sum of the Initial VBS and the Slippage VBS, both requiring slightly more complex calculations than for the offshore part

Example

Let’s look at an example using realistic values for our current state of the protocol.

XHV circulating supply = 28,596,340
XHV Price (1st October 2022) = $0.41
xAssets market cap ≈ 15,800,000 (estimate figure)
Onshore amount = 1000 xUSD

Using the above, we get a market cap ratio of 1.3476, and since the ratio is above 0.9, we use the second formula from the Market Cap Ratio VBS calculation to calculate the VBS:

VBS = SQRT(mcap ratio) * MR Multiplier = SQRT(1.3476) * 40 = 46.43

Now we can use the Specific Onshore formula to calculate the collateral.

Collateral = (1000 / 0.41) * 46.43 = 113,244 XHV (amount of unlocked XHV required as Collateral), and the amount of XHV you can onshore is 1000 / 0.41 = 2439 XHV

That’s a lot of collateral for a small amount of onshore, but we are in a bad state and the high VBS will provide the level of protection necessary to avoid inflation.

This example doesn’t take into account any slippage, but for the small amount being converted, the slippage will be small anyway.

Expanding the VBS in our function gives us:

Initial VBS

As with offshores, the Initial VBS is the value calculated at the current state of the market, before the conversion, and the Slippage VBS is the value representing the state of the market after the amount being onshored.

In most cases (Onshores only), the Slippage VBS will only be a fraction of the Initial VBS, since the Initial VBS will always use the worst out of two values: the Market Cap Ratio VBS or the Spread Ratio VBS.

To calculate the Initial VBS, we must first calculate the Mcap and Spread VBS values.
Using the formulas defined in sections Market Cap VBS and Spread VBS, we have:

Using a simple IF statement, we can derive the Initial VBS by taking the highest of the two values.

Slippage VBS

The Spread Ratio increase can be expressed as:

Plugging this into our main function and expanding it, gives us the Specific Offshore function:

Collateral = Amount of unlocked XHV required as collateral
xUSD = Amount of xUSD to be onshored
XHV Price = Current price of XHV inside the vault

Max Onshore function

As stated previously, this function is harder to calculate for three reasons:

Introduction of Spread Ratio.
Working with two currencies, XHV and xUSD.
When trying to work out the maximum amount of xUSD that we can onshore, we have to consider both, the amounts of unlocked xUSD and XHV in the vault and the corresponding VBS.

The simplified formula for working out the maximum amount of xUSD that can be onshored is:

Max Onshore xUSD = Maximum amount of xUSD the can be onshored
Unlocked XHV = The amount of unlocked XHV
VBS = decimal value of the collateral, which is made up of the Mcap or Spread VBS plus slippage VBS.
XHV Price = Current price of XHV inside the vault

Just like the Max Offshore function, without slippage we could use the Max Onshore function directly to work out the maximum onshore value.

For example, if the price of XHV = $0.50, the amount of unlocked XHV = 100 and VBS = 10, then:

Max Onshore = (100 / 10) * 0.5 = 5 (maximum amount of xUSD that can be onshored)

Doing the reverse, we can use the Specific Onshore formula to work out the amount of collateral needed when trying to onshore 5 xUSD.

Collateral = (xUSD / XHV Price) * VBS = (5 / 0.5) * 10 = 100 (amount of XHV required as collateral)

Slippage introduces the same uncertainty in the Max Onshore function as through the Max Offshore function. However, the uncertainty is greatly reduced since the VBS for onshores will always be higher than for offshores, and so will the increase in the Spread Ratio. This means that the initial value derived by the max function will be very close to the actual value.

We will use the same technique in the code as for offshores to approximate the max onshore value to a high degree of accuracy.

Expanding the formula, we get:

And using our Spread Ratio defined earlier:

Below is the expanded Max Onshore function. The Initial VBS in the function is derived in the same way as we have shown in the Specific Onshore Function section.

Shoring cap per block

It will be necessary to set a cap for the amount of XHV being shored in a single block.

The reason for this is that a whale could potentially avoid slippage by splitting a large conversion into many smaller ones and adding them into the same block.

This process would also avoid being penalised for increasing the market cap or the spread ratio.

To work out the cap, once again we will be using the Square Root function, the XHV market cap and a multiplier to get the desired value.

The formula to work out the cap is:

XHV Cap = the maximum amount of XHV that can be converted in a single block, irrespective of VBS or number of transactions inside a block
XHV MCap = market cap of XHV (supply * price)
Cap Multiplier = a number that will get the desired level of block cap

The suggested multiplier for the block cap is 2500.

The table below shows the relationship between XHV market cap and the cap limit.

Fees

Conversion fees

Proposed conversion fees are 1.5% per conversion, for Offshores and Onshores.

We will be revising fees regularly to ensure that we only charge the amount that is necessary to sustain our protocol.

Slippage fees

In our initial proposal, we suggested fees for slippage, which have been dropped in favour of increasing the collateral.

However, as Haven’s treasury is not looking good, we are proposing the following changes to our xAssets conversion fees.

xAssets Conversion fees

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.

Shoring processes

The process flows for each shoring type shown below have been created in order to visualise how conversions will work once VBS is implemented.

Offshore process flow

OA = Offshore Amount
BC = Block Cap
TAXHV = Total Amount of XHV required for offshore (amount of XHV to be offshored + collateral).
TUXHV = Total Unlocked XHV available in the vault.
NOTE: The minimum amount of XHV that can be offshored is 1 XHV.

Onshore process flow

OA = Onshore Amount
BC = Block Cap
MR = Market Cap Ratio
SR = Spread Ratio
TAXHV = Total Amount of XHV required as collateral.
TUXHV = Total Unlocked XHV available in the vault.
NOTE: The minimum amount of XHV that can be onshored is 1 XHV.

VBS Simulations

VBS is a new concept, and we don’t have any historical data to which we can refer to. Its value, the collateral, can be influenced by many factors, some of which are listed below:

Overall market conditions
XHV Price
XHV Supply
xAssets Market cap
State of the protocol
Sentiment, which determines how users will interact with the protocol
Usage of the shoring functions
Level of adoption

While we cannot create a simulation to back test any historical data, we can create simulations based on a number of realistic scenarios to see how our proposed model behaves in certain conditions.

We have therefore written a program to the specifications outlined in this proposal, and we have created a number of simulations to give you an idea how our shoring functions are going to work with VBS.

Each simulation consists of a series of Onshores or Offshores, or a combination of the two, with the first row being the starting point and the state of the protocol, followed by subsequent shore events, the values of which are cumulative to the previous shore. Each of those shores (rows) represent a 21 day lock time and we are assuming that each one will shore the maximum amount possible.

The predefined parameters that we’ve been using in our program are those that have been defined earlier in the proposal. They are:

Minimum VBS = 1
Minimum Shore amount = 1 XHV
Block Cap multiplier = 2500
Market Cap Ratio Multiplier = 40
Spread Ratio Multiplier = 15
Slippage Multiplier in a good state (when mcap ratio < 0.1) = 3
Slippage Multiplier in a bad state (when mcap ratio >= 0.1) = 10
21 days lock time between each shore event

Simulation 1

This is probably the most important and realistic simulation.

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.

Simulation 2

This simulation is much more hypothetical, and it’s taking us back to the 2nd April 2022, just before the xUSD whale converted his 2 million XHV into 16 million xUSD.

At that time, the market cap ratio was very good and the price of XHV was over $7. This is when you’d expect users to offshore.

Let’s see how much our whale could have offshored and onshored with VBS in place.

It looks like our whale wouldn’t have been able to inflate his bag during all that time, which indicates that you cannot game the system by pumping XHV for a short time, only to dump it again to profit from by using the shoring functions.

Of course, this is assuming price would have fallen this low in the first place.

It’s impossible to say how price would have behaved without the massive sell pressure that it was exposed to in reality.

Simulation 3

In this simulation we’re going to see what happens if the price of XHV is being driven down more and more in order to create a type of death spiral in order to try and inflate the supply as much as possible.

As the price goes lower, the market cap ratio gets worse, and so does the VBS, exponentially.

Once VBS rises above 100, it’s virtually impossible to onshore any significant amount of XHV, and it’s not possible to inflate the system by way of a death spiral.

VBS Simulator

One of Haven’s Discord community members has developed an online VBS Simulator based on the current proposal.

This allows anyone to see how VBS works, and calculating the amount of collateral required depending on certain market conditions and unlocked funds.

You can use this simulator to verify the collateral during the testing phase and once Haven 3.0 has been released.

Please note that the simulator is not taking into account transaction and conversion fees, and you need to know which price to enter in the simulator, Spot or MA.

More information on which price is used during a conversion can be found here:
https://havenprotocol.org/knowledge/conversion-rates/

There might also be slight variations in the VBS/Collateral due to differences in coding, since we are approximating values when performing Max functions.

The simulator has three main sections:

Market Conditions (XHV price, XHV supply, xAssets Market cap)
Vault Conditions (Unlocked XHV, Unlocked xUSD)
Shoring Conditions (Max Onshore, Specific Onshore, Max Offshore, Specific Offshore)

Fill in all required fields and click on the “Add simulation to table” button. This will create a row of your inputs and the calculated values for the VBS and collateral.

You can add to this table as many times as you want by running different simulations, and you have the option to export the results to CSV. Link to the VBS Simulator:
https://vbs-simulator.streamlit.app/

In Summary

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

Generic shoring measures

21 day unlock 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.