Economics Working Group Update – Haven Protocol XHV

Introduction

Since its inception, Haven has come up against many challenges and obstacles that may have seemed insurmountable on first visit. However, through the collective will of the project contributors and a highly committed community we have overcome them and continue to build out many aspects of the project.

One of the more important of these challenges is the ongoing development of the tokenomics. It has been necessary to stress test the ongoing evolution of the model by going through a range of market cycles as well as market manipulation.

The development of the tokenomics was always intended to be an iterative process and with the recent crash of the Luna model (due in large part to factors that do not affect Haven), it has given the economics group the opportunity to look at that episode and to take learnings from this and their collective knowledge to help strengthen Haven’s model for the future.

The working group have been looking at a number of potential improvements in order to reduce the risk of excessive inflation within the system and are currently working on refining those before presenting a more detailed document for community discussion.

In the meantime we wanted to share some of the thoughts and topics of discussion that have been looked at by the working group.

Current Ideas

To reduce the potential of excessive inflation of XHV (the network’s backing currency) one solution being discussed is to implement “dynamic fees” that are directly related to the ratio of the marketcap for xUSD and XHV. The majority of those fees would then be burnt with 0.5% being maintained for the project treasury.

As the ratio of xUSD increases relative to XHV, conversion fees would increase proportionally to the change in ratio. The majority of these fees would then be permanently burnt (destroyed) reducing the inflationary effect of any conversion to XHV (onshore).

This can best be explained using a simple table to show the network state and the fees and burn that would be incurred when converting from xUSD to XHV. The fee levels are automatically adjusted depending on a ratio of xUSD to XHV and multiplied by a defined function to increase effect depending on economic system health.

This would help incentivise the network to return to a healthy state (i.e. a defined support level of MCAP ratio).

xUSD to XHV market cap ratio	Fees payable for onshore conversion	% of Fees burnt
LOW ⬇︎ ⬇︎ HIGH	LOW ⬇︎ ⬇︎ HIGH	99.5% of fees burnt regardless of network state

This can also be shown in a graph using the example ratio^2

Fee Capping

The min/max fees for xUSD > XHV conversions would be set within agreed upon parameters. This will serve two functions:

Minimum fee gives the project a level of funding from conversions as well as mining incentives.
Maximum fee makes the protocol usable at higher ratio levels but with a penalty for doing so.

The Infinite Liquidity Challenge

While the original idea of infinite liquidity for the in-vault conversions was considered a USP for Haven, it has proved to come with additional risks that allow larger holders to benefit disproportionally and cause system imbalances.

To counteract this, there is the possibility of introducing a slippage based fee for conversions. The working group are discussing options based on the change made to the MCAP ratio by any single transaction. The slippage fee would then take an average of the change expressed as a % and add that to the MCAP ratio fee as described above. This would create a compounding effect for those wishing to onshore large amounts in one go and therefore further incentivise the rebalancing of the system back to a support ratio level.

The decision on whether to introduce slippage based fees for both directions (on and offshore) has yet to be decided as it may introduce unintended consequences. This will be determined following further discussion and community input.

Next Steps

Following on from this update we would like to take on further community input and feedback while the group continues to refine the ideas and put forward a detailed proposal for potential tokenomics updates.

We will also be working alongside the core devs to look at implementation timescales and issues that may arise from the coding perspective.

This is being considered as a project priority but one that cannot be rushed so please do get involved in the community discussions if you have ideas to share. It will enable the working group to make better decisions for the future benefit of the project.