If you are able to donate and contribute to the Haven project, please click here. Thank you.
In January 2023, we saw the release of Haven 3.0 and introduction of VBS, a new concept in our tokenomics, which allowed conversions to be restarted after these were halted back in June 2022 due to an emerging death spiral. The heavy restrictions imposed through VBS, means that users need a lot of collateral in order to onshore even a small amount of xUSD. With no end in sight of the continued bear market and lack of demand in our protocol, VBS has been increasing steadily, making it ever harder to use the protocol.
Long lock times and high collateral requirements prevented xUSD from maintaining its peg on exchanges and this led to its decline over the past few months, reaching an average low of around $0.20 per xUSD at the time of writing (May 2023).
As stated previously, VBS was not designed to fix the peg of xUSD, but to safely enable conversions, which would allow the Economics Working Group (EWG) to work on improving the tokenomics with a specific focus on the peg.
This brings us to the latest release.
Haven 3.1 incorporates several updates to the protocol and tokenomics.
The tokenomics updates are intended to ease conversions by relaxing the VBS and reducing the lock times for Onshores and Offshores.
To compensate for making conversions easier, a new concept will be introduced.
This is covered in more detail below. Slippage is not to be confused with the “Slippage VBS” used in Haven 3.0 to calculate the VBS.
Let’s look at the main updates for this release.
Rebase to Monero v0.18
Haven is a fork of Monero and it’s important to keep up-to-date with the latest releases from Monero in order to maintain a high degree of security and functionality.
As part of the update, developers have gone through a process of simplifying the Haven codebase by removing superfluous code that was built up over time and is no longer needed, as well as improving efficiency and legibility of the code. This will make subsequent updates much easier to implement.
The rebase sets up the future development of the Haven codebase to be more accessible and allow existing Monero developers to potentially join the Haven dev team with little to no training due to familiarity of the code.
Fees through conversions are currently being paid in the source currency. For example, converting from xUSD to xBTC, fees will be paid in xUSD.
This presents an issue because the treasury has no way of using those fees to pay for running costs, and due to the current state of the market, nobody is offshoring, which would normally generate fees in XHV.
It has been agreed by both the EWG and the HOC (Haven Oversight Committee) that all conversion fees will be paid in XHV. This will ensure that the project has enough liquidity to pay for a multitude of liabilities (bills) that accrue each month. These include, but not limited to, cloud & oracle services, hosting, website, developer wages and funds for future marketing and design.
The community has voiced some concern over this due to a perceived increase in the supply of XHV. However, the overall supply of all assets would remain the same because fees will be taken from an existing asset, which is already in circulation. Converting fees to XHV will just make it easier and quicker for the treasury to use the funds.
This has the added advantage of incentivising miners to use our protocol as they would also receive transaction and conversion fees in XHV.
With introduction of Slippage, any fees generated in XHV will be offset by burning coins through slippage.
Onshore fees will be reduced from 1.5% to 0.5%.
We are lowering the fees on Testnet to get an idea if the treasury will receive enough funds at these levels in order to sustain the project.
Reducing fees will encourage protocol usage.
Offshore & Onshore Collateral lock times
The Offshore and Onshore lock times for the collateral amounts are being reduced from 21 days to 14 days.
Lowering the collateral lock time should increase demand and usage of our protocol.
Offshore & Onshore Converted Amount lock times
The Offshore and Onshore lock times for the converted amounts are being reduced from 21 days to 24 hours.
Unlocking the converted amount much sooner will allow arbing of xUSD on exchanges.
This will in turn encourage the peg of xUSD to rise.
Offshore & Onshore VBS
At the time of writing, the value of the VBS is 58, which means users need 58 times the amount of XHV as collateral, compared to the amount they intend to onshore. Although this stops the death spiral for which it was intended, it also stops the protocol from functioning properly. Without usage, it’s hard to see how the VBS can drop significantly and allow conversions to work again; it’s possible that the protocol could be stuck in a perpetual cycle of negative sentiment.
In this latest release, we have decided to lower the VBS to a maximum of 5 with a gradual decrease up to a minimum of 1 in line with a decreasing market cap ratio. This may be changed throughout the course of the testnet, depending on the results and feedback.
For the new VBS calculation, we’re going to use a simple formula for both, Onshores and Offshore:
The table below shows the VBS values for a range of Market Cap ratios:
If slippage works as intended, it’s quite possible that we will eventually remove VBS altogether, or at least reduce it to a maximum of 1. We will have to wait and see how the protocol evolves over time once the new tokenomics have been released on mainnet.
Remove the block cap
The block cap is specific to Offshores and Onshores in Haven 3.0. By introducing slippage, this restriction is no longer needed since we encourage large conversions, which would burn coins through slippage.
Slippage is not a new idea and has been discussed by the team and community over the years. The Delta burn, which is a type of slippage, has been proposed in the past, but voted against by the community.
Haven is not large enough to cope with infinite liquidity inside the vault, whilst liquidity on exchanges remains something to be desired. By softening the VBS, we need something that will counter this, and burning coins through slippage is a good alternative.
The model we are looking to implement is related to pool ratios, where each asset’s circulating supply represents a pool. We are trying to synthetically mimic a Dex by using (among other things) the ratios of the assets’s circulating supplies that are being converted and the size of conversion to create a realistic slippage value, which would be burned during conversion. This should create a system that will be closer to natural behaviour, and through burning what previously would have been a false/easy win, would now prevent gaming the system.
By using ratios of asset pools and conversion amounts, slippage becomes very dynamic in favour of smaller conversions and high for large ones.
Slippage rates would be individual for each transaction based on:
- Relative depths of each pool involved.
- Ratio of overall xAssets to XHV (same as the mcap ratio used in working out the VBS).
- Size of TX relative to pool depths of source and destination assets.
- Source Pool Multiplier – this is a value which determines the strength of the Source Slippage.
The multiplier is a function of the mcap ratio. See formula below.
- Destination Pool Multiplier – this is a value which determines the strength of the Destination Slippage.
The multiplier will be set to the mcap ratio, with a minimum of 1.
So the formula would become: MAX(1,McapRatio)
Source Pool Multiplier formula
The Source Multiplier is using an exponential function, similar to VBS, with a minimum value of 5.
The table below shows the Multiplier values for a range of Market Cap ratios:
Let’s look at an Onshore example to see how the calculation is applied based on the current price and circulating supplies of all Haven assets taken on 14th May 2023.
XHV onshore price = $0.3079
XHV circulating supply = 29,445,005
XHV market cap = 29,445,005 x $0.3079 = $9,066,117
xUSD circulating supply = 14,786,792
Total xAssets market cap = $16,306,188
Mcap Ratio = 16,306,188 ÷ 9,066,117 = 1.8 (rounded)
Source Pool multiplier = SQRT(1.8 ^ 1.2) * 20 = 28.48 (rounded)
Destination Pool multiplier = MAX(1,McapRatio) = 1.8
Onshore amount = 100,000 xUSD
ConvertAmount is the asset amount being converted.
SourceSupply is the circulating supply of the asset being converted, in this case xUSD.
SourceMultiplier is the Source Pool Multiplier worked out in the Initial Values section.
ConvertAmount is the asset amount being converted.
AssetPrice is the price of the asset being converted, so for xUSD it’s $1.
DestinationAssetMcap is the market cap of the asset being converted to, XHV market cap = 9,066,117
DestinationMultiplier is the Destination Pool Multiplier worked out in the Initial Values section.
TotalSlippage = SourceSlippage + DestinationSlippage = 21.09%
So the total amount of slippage in this example is 21.09%, or 21,090 xUSD that would be burned, and 78,910 xUSD that would be converted to XHV, minus conversion fees.
Here are a few more onshore examples using different amounts:
Onshore amount = 10,000 xUSD
Total slippage = 2.11%
Onshore amount = 50,000 xUSD
Total slippage = 10.55%
Onshore amount = 500,000 xUSD
Total slippage = 100%
The code will not be audited externally, because conversion fee changes are trivial and don’t expose any additional attack vectors; the numbers are all plaintext already, and the slippage code is also calculable and verifiable from the plaintext data.
To recap, the Haven 3.1 testnet will incorporate the following changes:
- Rebase to Monero v0.18.
- All fees for conversion TXs to be paid in XHV.
- Onshore fees reduced from 1.5% to 0.5% (Testnet only).
- Collateral lock time reduced from 21 days to 14 days.
- Onshore/Offshore converted amount lock time reduced from 21 days to 24 hours.
- Onshore/Offshore VBS unified, with a range between 1 and 5, depending on the Mcap Ratio.
- Removal of the Block Cap for Onshore/Offshore conversions.
- Introduction of Slippage, which will burn coins relative to pool ratios, mcap ratio and size of transaction.
Please note that all values, formulas and functions for VBS, lock times and Slippage are subject to change during the Testnet and before mainnet.
This will depend on test results gathered and feedback from the community.