RIP-000-009: Fee strategy during Greycore transition and other features

Ren Improvement Proposals | RIP
1

Name: Fee strategy during Greycore transition and other features
Category: Fees
Status: Final - Accepted - Implemented
Scope: Increase minting fees and lower burning fees temporarily during feature rollouts to mitigate risk

Overview

The Greycore launch has been kicked off (https://medium.com/renproject/renvm-greycore-on-testnet-31747cc183c5), marking a monumental step in RenVM’s progress towards decentralization. This marks a very exciting time, but also new era, one where special care must be taken as new members begin to power the core parts of RenVM. At the same time, we are seeing the TVL in RenVM reach all time highs (https://mainnet.renproject.io/).

Because of these achievements, the Ren project has never been in a better place in terms of progress. But we are also seeing a worrying trend in general in the crypto space, where hacks and exploits are at an all time high as well (https://www.rekt.news/).

A core part of the RenVM security model is its ability to regulate TVL against TVB by adjusting minting and burning fees. Given the upcoming release of multiple novel features, the recent focus of hackers on interoperability solutions, and the expected increase to TVL, we believe the responsible course of action is to increase minting fees and decrease burning fees. This should be done asymmetrically such that fees increase overall. This is in accordance with the RenVM security model and is expected to have two impacts: (1) a reduction in TVL, and (b) an increase in TVB (caused by an overall increase in fees, which has downstream effects on TVB).

It is important to not only mitigate risk during a time when novel high-impact features are being rolled out, but also to demonstrate the ability of RenVM to regulate TVL and TVB as expected.

The Ren core team believes it is imperative to implement these changes now, for the duration of the Greycore transition, not only to secure long-term success by minimizing the risks and consequences of an unforeseen attack, but also not to put too much risk on the shoulders of the new Greycore members.

Details

How would the fee changes interact with upcoming host to host capability?

With the upcoming deployment of host to host capability for RenVM, there will be a new type of transaction possible, which are burnAndMint transactions (e.g. burn renBTC on Arbitrum and mint renBTC on Ethereum). We have the ability to freely set this fee independent of the fees for mints or burns. burnAndMint transactions are not considered by this proposal, i.e. they can remain at 0.15%. This can be so because burnAndMint transactions do not change RenVM’s TVL. A nice side-effect of launching host to host in parallel to the proposed fee changes, is that volume can increase without a change in TVL (at the same fee structure as before), which should have positive downstream effects on TVB.

Minting ETH/SOL/ERC-20/BEP-20 assets etc. on a new chain are mint transactions and increase TVL, and they would be subject to this proposal on the other hand, until it makes sense circling back on fee setting in the future.

Fee parameters

We initially suggest these possible fee levels, in any combination:

Mint fees:

  • 0.20%
  • 0.30%
  • 0.40%

Burn fees:

  • 0%
  • 0.05%
  • 0.10%

In the vote itself, all 6 options will be available, and you as a DNO with voting power can distribute your voting power freely among all options, meaning you can split your vote between one minting fee option and one burning fee option, or any other combination. The final results after everyone has voted will be the weighted sum of the votes for the mint category separately, and likewise for the burn fee category. So if the voting power between mint_20 and mint_40 is equal, the results will be a minting fee of 0.3%, regardless of how the voting power for the burn category were distributed.

Next steps

  1. Vote through this link: :arrow_right: Snapshot :arrow_left:
  2. The results will be implemented by the Ren core team
13 Likes
2

TL;DR I support this RIP and would love to see maximum minting fees and minimum burning fees. I hope that the community sees the importance of this for sustainable long term growth and votes accordingly.

I usually try not to comment too much on governance items, but I think this is very important, so I will. Growth of the project is the obvious concern with a proposal like this, so I want to address that concern immediately. I think it is flawed for two reasons:

  1. Growth as measured by TVL is not a good metric.

  2. Nothing kills growth more than poor security.

Growth as measured by TVL. This point has been belaboured quite a bit by various members of the community but is worth repeating. TVL is not a good metric for RenVM. The absolute perfect ideal for RenVM is $0 TVL and high (as high as you like) total volume transacted (TVT). RenVM earns fees when funds move, not for funds in holding. Funds in holding are a necessary evil to help drive TVT. But this point extends beyond TVT. RenVM is still a very new project and one that is yet to prove itself in all dimensions. Gathering data in the real world about how its economics work in practice is incredibly important for protocol design. Are fees a good way to adjust TVL relative to TVB and/or TVT? To a point, we can only know through testing. If we don’t see what we expect (lowered TVL and/or increased TVB), this hints to the core team that we should potentially be rethinking parts of the protocol design. Knowing you have the right protocol before fully decentralising is critical to sustainable long term growth, and that has never been more relevant than with the imminent rollout of the Greycore.

Security is important. More funds lost bad. Less funds lost good. This is probably not controversial (I would hope). With the rollout of various security fixes, host-to-host transactions, and the Greycore, there is a higher chance than ever before that something could go wrong. The system is at its most complex and at its least controlled. Many projects even put hard caps on how much TVL can exist during these “proving periods”. The team has of course out every effort into auditing, reviewing, and testing the code base. But security is a wholistic practice and part of it is mitigating risk. In this context, we do not have an exact target TVL in mind but less is almost always better and for so many reasons. Even liveliness downtimes (as recently seen on Solana and Arbitrum) have a larger impact when more funds are stuck as a result. Funds don’t have to be lost for high TVL to be of concern w.r.t. to a secure stable and always-on network. Once the rollout is complete and the system is battle-tested and inevitable bugs fixed, we can re-adjust fees as necessary.

Finally, if there are specific assets on specific chains where we want to see growth, we can still lower fees for those use-cases. This RIP concerns the system as a whole so we can make context-specific adjustments as needed. Similar to this, it is worth noting that if RenVM is dramatically stunted by this adjustment of fees, we can always adjust them back! But the inverse is not true. We cannot reclaim lost funds from safety failure or lost opportunity costs from liveliness failures.

20 Likes
3

If there was ever a time to raise fees (even slightly) by increasing mint and reducing burn - it’s now!

APY’s, once again, are either huge or just big enough for people to be greedy and not care either about 0.2%, 0.3% or 0.4%.

And from all these new chains popping up I’m seeing the biggest demand for bridging stable coins and other assets, than there ever was, even from crypto beginners. With host to host we’re bound to get that piece of the pie, there are simply no alternatives that are on Ren’s level.

So yeah, I think 0.4% mint fee and 0% burn fee makes the most sense. Let’s ride the rest of this mania and see what comes of it! <3

2 Likes
4

I fully support this proposal to raise the fees!

The upcoming volume over the next 12 months will be significant and we as a community need to be prepared to manage the volume across different chains and incentivizing an arbitrage to burn fees by keeping the fee to burn below what the majority of people are able to swap renBTC for BTC for on any exchange seems to be a correct approach.

These increases will help us in many ways as fee increases have shown in the past:

  • It will create more revenue for the DN operators,
  • It will incentivize more operators to join the network which will help us secure the network,
  • More DN operators will help us decentralize proving to the ecosystem that we are the most robust and safest option.
  • This in turn will help us support larger levels of throughput across more nodes, which will inspire more devs to want to build using RenVM and the assets that we secure and can move across all the chains.

Fee Strategy
We missed out on a good amount of revenue by lowering the fees over the last 2 epochs and lost 34 DNs with another 16 due to leave this epoch as well. This result of less income, fewer node operators, and slowing the growth of operators goes against our global network objectives to grow and become more decentralized and more secure.

I am so glad to see this RIP, I was going to draft one myself at the end of this epoch pushing this exact agenda. I greatly appreciate the team’s foresight into fee management as we are about to enter the new year for RenVM and the volume and network opportunity is in front of us worth capturing.

2 Likes
5

I agree to increase mint fees to 0.4%
I agree to decrease burn fees to 0.1%

I believe that decreasing the burn fee to 0% will not make big changes in TVL because if the user would like to return his native asset, the required fees will not prevent his action since the 0.1% burn fee is still very low and this will help increase TVB as we need.

6

Some interesting points made here, thanks as always for your input everyone.

If reducing TVL is our long-term goal then I do support the initial proposal (and Loong’s insights on this).

Although a part of me does worry that we’re discouraging minting ever so slightly when we’re on the cusp of welcoming new volume into the network, especially with host<>host. I’m wondering if whether it would be a good idea to keep our fees as they are now - and let our new host<>host users familiarise themselves with using Ren, before addressing TVL and fees later once we’ve captured significant host-to-host volume?

As always I will respect and support the outcome :+1:

7 Likes
7

I was surprised seeing this proposal from @MaxRoszko so shortly after the push to get a uniform 15 bps across all chains and transaction types.

However, I can fully get behind the reasoning put forward, and emphasized by @loong. Especially seeing how the popularity of new chains (e.g. Solana, Arbitrum) has quickly pushed up our TVL to record highs. Moreover, the fact that with host-to-host we will have more avenues to bring in volume without increasing our TVL, funds locked inside RenVM will have more use (thus value) than before, which seems like a good moment to try and capitalize on funds moving in (by increasing fees on mints) while at the same time lowering fees on funds moving out to increase the TVL/TVB ratio for reasons mentioned in the proposal.

Therefore I support the highest mint and lowest burn fee put forward (40 and 0 bps respectively).

1 Like
8

Great RIP! This is a fascinating discussion and ultimately we need to accept that we’re making decisions based on imperfect data so we’ll never get it perfectly right.

The one thing I wanted to highlight was that even if we agree that TVL is a pretty poor yardstick, it is still used by many projects as an easy indicator of traction. I think something that massively hurt the project over the past 18 months is the TVL decreasing significantly which turned into quite lukewarm interest in being integrated by a number of projects. “Why should we be bother supporting wrapped tokens from ren as they only have X of TVL”. I think 0% burn fees will empty the TVL coffers very rapidly…

9

How do you guys see the ren bridge being utilized by people in a way that encourages transaction volume while discouraging holding REN assets? I have only ever minted REN assets to stake them on pools, which would directly increase long term TVL.

10

To ensure the long-term sustainability of RenVM we also support the fee change to (across all chains):
40 BPS Mint
0 BPS Burn

This is a shorter-term measure to provide a long-term benefit.

11

I will vote for the maximum fees suggested, recognizing that 50 basis points on a round-trip transaction of this nature is still a screaming bargain and there is really nowhere else to turn for similar functionality and security.

However I do object to

  1. A lack of discussion with DNOs preceding this RIP
  2. A lack of a “no change” option in the vote, which ensures that some change will indeed be made.

I am sure this is a popular RIP to pass, but in the future, the community should not just be asked what change to make, but also if it feels a change should be made at all.

6 Likes
12

I agree in the future an alert about a pre-discussion before a proposal is posted would be much better for DNOs. I haven’t posted much because there aren’t many chances to engage in discussion prior to voting.

My vote will be for high mint (at least ~4, should be higher total than current, lowering fees did not boost volume but decreased revenue/security) and 0 burn, for same reasons as Loong. We want fluidity and simplicity. Simplist marketing is just 1 fee.

Just to clarify before I pick a specific number, for H2H across multiple chains (say 3 hops) do they incur a mint/burn fee each time (3x fee)? How does BurnandMint work is it .15 x 2= .3 total or per hop? I’d like to similarly increase that fee as well while we’re at it—unless a significantly lower priced competitor emerges. We need to fund security, DN growth. Fee shopping is not as high a factor as we’ve been speculating and we’ve never gathered data on increasing fees so logically it’s the next area to test.

Lastly, do we have any data analysis from the first fee change to backup the claim that changing fees has ANY impact on TVL and TVB? What if it is totally inelastic? (As a consumer, if I need to bridge I will pay anything short of a Uniswap 2-3% slippage fees everyday…for whales, is there real data that small fee changes matter that highly? Or is this all conjecture?) How will we record/analyze the effects of this fee change for future decision making? Will a average users even know there is a burn fee? (It will be invisible through most third party apps…)

2 Likes
13

I believe that security is paramount and all should be done to try and minimise any risks.

However I just wanted to argue (as others have) against this notion that TVL bears no importance. If the TVL of Renbtc is low, then there is no incentive for AMMs to provide trading pairs with Renbtc. Without trading pairs, the renassets effectively become useless as you can’t trade out of them once transferred to a new chain.

TVL acts as a proxy for a token’s utility. The higher the TVL - the more places I will be able to use an asset normally.

Security is paramount as I’ve said, and I’m happy to make changes to help avoid hacks, but I fear that the team’s disregard for TVL may well hurt the project over the long time just as much as a hack in the early days may do. I think disincentivise TVL in the early days if we must, but please incentivise it at a later stage once improved security has been achieved.

5 Likes
14

I’m one of those who have been pretty vocal that TVL matters so I feel compelled to at least state my thinking. As Loong stated, funds in holding are a necessary evil and I understand why. TVLs do not bring revenue to RenVM, only TVT does. In the perfect world, RenBTC can be swapped directly to WBTC or any other native BTC representation on the L1 chains and renBTC is ephemeral, transient, disappears after the swap and not at all the asset that people keep to earn yields. BUT that is just not the case and we are dependent on RenBTC->WBTC Curve pools or whatever other native BTC pools on L1 chains to exist to support swaps. Only in the case that there is liquidity of renBTC in these pools (implies TVL growth) can RenVM support more TVT. So while we are not aiming for high TVL, it is an unavoidable proxy metric for network utility and growth. A high TVL means there is liquidity in the RenBTC pools that can support whales.

The second reason why I think TVL matters and this I know is not what the REN team believes in but my personal belief, the truly lasting defensible moat that Ren has is the brand of its currency. RenVM can be ahead in technology right now but as you can see with Chainlink’s announcement and all the other bridges that have come out recently and will come out in the future, technology is not a moat. Amazon’s tech is not the moat, Google’s tech is not the moat, Facebook’s tech is not the moat, these tech giants’ moat is their brand and user base. If you are just a technology enabler working in the background, somebody at some point can always build a better mousetrap and replace you and users can’t even tell the difference. I can swap the network gear that powers my website from Cisco to Jupiter and my users won’t care. But if I change the URL of my website, my users are gone. In the world of cryptocurrency, the currency brand and liquidity of which TVL is a proxy is the only true moat. Bitcoin, Dai and USDT cannot be supplanted because they’ve built up circulating supply in the crypto ecosystem which any competitor will be hard pressed to compete with. My wish for a high TVL for renBTC is out of selfishness that renBTC be the standard and REN’s future be secured!

But I understand as well that we can’t put the cart before the horse and we need better security before we can be aggressive and ambitious. Security is paramount. I’m in support of increasing the mint fee to try to lower TVL.

8 Likes
15

TVL speaks to the general liquidity of renBTC. High liquidity of renBTC means larger markets for it and more interest to be earned from lending it. More yield from lending renBTC improves desirability of holding wealth in renBTC.

Though I understand that the purpose of the protocol is to be transactional, if the security is there, I think you’ll need to accept that the VM will be locking up large quantities of bitcoin so that holders can more easily earn yield on their wealth through farming products that emerge on the various chains. If the team did not yet account for this, I suggest they do now. I see it as an inevitability…

3 Likes
16

I fully agree and support the proposal by the team. At this stage safety is paramount. Especially because our technology is new and unexplored, everything should revolve around precaution and a focus on stability and functionality. Earnings are irrelevant to me at the moment, I am here because I support the project in the long run and I want long-term sustainability.In the end, the team has the best insight into the state of technology and is most aware of all the possible outcomes. Precisely because the team has been transparent in everything from the very beginning and with a very friendly and loyal approach to community, I will not hesitate for a second to support the proposal.

17

To clarify, reducing TVL is not the long-term goal, the proposal only suggests a change for the duration of the Greycore transition, and where the fees should be revisited and changed when it’s appropriate to do so. Ultimately we want to be at a position where high TVL isn’t a concern, instead where its purpose is to help with liquidity, which supports more transactions at low slippage, which supports volume and is what RenVM sustains itself on.

2 Likes
18

To clarify here as well, this is a proposal from the whole of the Ren team, not me specifically.

19

I agree with this proposal and the considerations of everyone in terms of TVL/TVB and the necessity to put security above all. While we are assessing all possible routes, we may need to start considering activating the continuous fee. These fees are part of the design of RenVM from the very beginning and something that will surely increase TVB as more fees are perceived by DNO and will deter long holding on ren assets. We could start with really small fees and and maybe a monthly or quarterly frequency? I just want to let this out for consideration.

20

Continuous fees are a nightmare for integrations and for the UX of regular users, and is not something the team considers being a viable design anymore, but the team is completely open to other types of fee designs, as long as they do not break the 1:1 relationship.

3 Likes