RIP-000-002: Increase mint fee to 0.3% on November 16th (start of Epoch 6)

Ren Improvement Proposals | RIP
1

edit: changed from a RFC-000-009 to an RIP-000-002 after rough consensus voted in the affirmative

Name: Increase mint fee to 0.3% on November 16th (start of Epoch 6)

Category: Protocol

Status: Draft - Rejected

Scope: Motion to increase the minting fee to 0.3% and monitor impact. If passed, allow users 7 days to enter their renBTC position at the current 0.2% fee. Measure data after fee change and determine best next step at that point.

Overview

This RIP proposes increasing the minting fee for all assets to 0.3% after 12 days from (Nov. 4) submission of this RIP.

Potential outcomes/next steps after the implementation of raising mint fees:

  • If raising the minting fee to 0.3% has had no impact on total income (or somehow it has had a positive impact), then the new RIP will propose raising the minting fees to 0.4%. If raising the minting fee to 0.3% has had a negative impact on total income, then the new RIP will propose lowering the minting fees back to 0.2%. The new RIP will be the point at which everyone can voice their opinion about the impact (whether it has been positive or negative for income).
  • Leave minting fees at 0.3%.

Details

Reasons for:

  • Setting a higher minting fee now allows us to strengthen the lever of lowering minting fees in the future

  • Similar to our recent mint fee increase, a change of mint fee from 0.2% to 0.3% may curtail smaller transactions and further lower value minted and make RenVm even more secure

  • Increasing the minting fee will increase minting revenue by 50% and will 1) subsequently, increase earning potential and 2) theoretically, increase $REN token value by incentivizing more darknode registrations

  • Increasing the minting fee to 0.3% will put REN more inline with Uniswap at 0.3%, and Coinlist wBTC at 0.25%

  • RenVM currently has more flexibility to further raise minting fees now before additional major integrations at which point, we would have to more greatly consider impact to partners

  • Many hypothesized that 0.1% to 0.2% mint fee would have little to no impact on volume, and as we can see from the large 1,500 BTC mints, there is indeed proof users are still using RenVM at high volumes even with the change in fee

Reasons against and counterarguments:

  • Overshooting, dropping mint volume too fast vs burn volume and reducing TVL too quickly (while unlikely still a possibility)

Conclusion:

The initial discussion on the first increase from 0.1% to 0.2% fees raised the possibility of further increases if no volume impacts were observed. Its been a few weeks and volumes have held steady

Its a good time for another increase to bring the TVL closer in line with the TVB. This increase should have the effect of raising the TVB while reducing the TVL. So it could be a win/win/win scenario: Increase TVB / Reduce TVL / Increase Fees

We have a market leading if not superior product with lower fees compared to peers. Fee generation and market share gains are not mutually exclusive.

No fees to darknodes will catastrophically impair the security of renVM, nodes will go offline if they don’t earn competitive fees. Experimenting with the price to understand the price elasticity is important.

It will give us real data and help us find the right equilibrium between fees, volume, and security.

Least we forget we need to have enough darknodes and a high enough value of $REN to fully decentralize.

Rough Consensus Vote
  • In Support
  • Against

0 voters

5 Likes
2

May I ask a few dumb questions.

Why not increase the burning fee to 0.2% to match the minting fee? Just from a marketing perspective to potential users of REN VM, wouldn’t it appear more palatable / reasonable to market the network utilization as “20 bps in and 20 bps out” vs. “30 bps in and 10 bps out”? And, aren’t the user and darknode operator just concerned about the “total” fees? Perhaps there’s something structural that I’m missing, that you’re trying to accomplish.

Also, why isn’t there a continuous fee right now? Take a borrowing app where the user is looking to borrow funds for a year, and instead of providing a personal guarantee on the loan, they’d rather put up their Bitcoin as collateral for that period. In that case, I presume they would be charged the continuous fee for the year (in addition to the minting fee at the start and the burning fee at the end). Note, I’m assuming these types of transactions are happening, but, maybe they’re not.

Thanks

2 Likes
3

In response to your continuous fee question, a continuous fee would mean forever changing the 1:1 peg of renBTC to BTC. I went into detail about this here:

1 Like
4

As you might guess from my submission of RFC 7, I share similar sentiments from a fee marketing perspective and also believe that, ultimately, 0.2% would be closer to a burn equilibrium price from a price elasticity perspective. The community has loudly and clearly shown opposition to this idea I pushed (which is fine).

The prevailing counter arguments from the opposing party is that 1. We should aim to control as many variables for data collection of mint fee changes and 2. We’re aiming to reduce total value locked of RenVM. By increasing mint fees, we’d theoretically reduce new mints which should help being RenVM TVL to TVB closer to equilibrium.

The argument I made with RFC 7 was that we should strive to increase burn fees closer to price equilibrium as it would likely increase revenues and thus Ren token price and ultimately TVB… in addition, it would incentivize new operators to bond additional Ren. This approach would have been in favor of business pricing strategy at the expense of clean isolated data. My counter to this was that the data would have been more accurate with both levers closer to equilibrium.

Hope this answers your questions @zbone1.

———

In regards to this RFC, I lean towards supporting it and will return to post in this thread with quantitative findings with data from the dune dashboard. With this data, I will give my own definitive response.

1 Like
5

Alright, to begin articulating my position on this RFC, I’d like to reference @loong’s RIP 1. He stated that Total Income is the measurement to monitor - not volume.

With this context, please see my short and sweet data analysis below.

image
image344×664 7.93 KB

Based on the data I’ve pulled from @jontom’s dune analytics dashboard, it appears the 16 day period before the mint fee change from 0.1% to 0.2% had 5,296 renBTC minted while after the fee change we had 4,277 renBTC minted. This represents a ~20% decline in volume. However, because the rate of revenue doubled, our overall RenVM revenue actually increased from 5.3 BTC to 8.6 BTC from minting activities alone.

As Loong’s RIP that was accepted with overwhelming majority specified that we measure based on RenVM revenue, I am in support of this RFC and actually push that it should be changed to a RIP per the guidance in Loong’s RIP. It appears we are healthily reducing minting volume while also increasing revenue. This decrease in minting volume helps secure RenVM because we currently have too high of a TVL, and subsequently, the increase in revenue should theoretically increase Ren token value and ultimately TVB.

For the folks that believe it is too early for a 2nd increase, please consider that this proposal would also have the same dynamics as Loong’s RIP. It would be for experimentation purposes to better identify the price elasticity of RenVM, and it can easily be voted to be reverted back to 0.2% or 0.25% if 0.3% proves to be too high of a fee. Let’s explore this price elasticity together.

Disclaimer: My opinion is in support, but if the Ren team has material, non-public information to be against this, I’m more than happy to adjust my position.

3 Likes
6

I am in favor of raising the minting fee to 0.25%. I don’t understand why we have to jump by 50% or 100% every time.

Why can’t we take small steps? I believe 0.3% is too high and can lead to lower volume and small users being put off which is not what we are trying to achieve in the long term.

My opinion is to keep the minting fee at 0.2% for another epoch and then test 0.25% starting from the following. For the ones running Darknodes, let us not focus on short term gains but rather long term growth. I prefer to sacrifice a few $ now if it leads to a lot more growth in the future.

4 Likes
7

I think we can also safely assume that we were being nevertheless in a minting downtrend so from that 20% minting decrease for simplicity we can say that half of that is attributed to the fee change ?

1 Like
8

The reason for another 0.1% jump is that we don’t know where the equilibrium mint fee is yet. We do know the the demand is strongly inelastic, meaning changes in price have relatively small impacts on mints. Let’s assume the 20% drop in minting volume was due to the change in fee alone. We know that a 0.1% increase caused a relatively small drop in mints (20%) and large gain in revenue. Meaning that the change in price has less affect on the mints.

If the demand is inelastic we can safely use more granular adjustments until we see larger changes in minting demand. Once we overshoot or get close to equilibrium then we can add fine adjustment eg 0.05% etc.

Finding the right mint fee supports the whole network in a virtuous cycle;

fees up --> DN’s up --> secures network --> greater decentralisation --> minting up

We are incentivised to find equilibrium faster. Coarse to fine adjustments would achieve that more efficiently and therefore better for RenVM

2 Likes
9

I am in support of this Mint raise, we have seen total epoch mints come down for the last two epochs in a row, it could be due to lack of exciting yields in DEFI, it could be due to our fee changes, we wont be able to confirm this until we keep pushing it until we can quantify the effect of fee changes.

I would further propose, if we wanted to increase the speed of raising fees, we could also consider 14 days of 0.3% and 14 days of 0.4%. In theory there should be a limit to which customers are unwilling to bridge their BTC using our platform, the sooner we understand where those limits are the closer we are to understanding the market.

I think if we care about increasing the value of DNs in addition to lower TVL, then we would also raise the Burn Fees, but that case has been squashed.

Further, I would go on to say when BSC and other chains come online, we should also consider starting them a 0.2% as opposed to 0.1%

2 Likes
10

I agree with the idea of 14 day raises till we get close to an equilibrium, where any further increase would negatively impact volumes, and reduce overall fees . Good to learn as much as we can about fee boundaries before the flood gates of integrations open.

The economic viability of darknodes has a direct impact of the security of the network. The current fees are very reasonable when one considers the value that renVM creates.

2 Likes
11

I think a 10 BPS increase would overshoot what people are comfortable paying, although that information would be useful in itself. With a 5 BPS increase there is less risk of overshooting while at the same time collecting more useful data, so I’d be more supportive of that.

2 Likes
12

I think discovering that this is overshooting is ok. If it is, then we take a small step back. If we confirm that a 5 BPS raise is something that users are comfortable with, how will we know if that is the maximum they are comfortable with? Sooner or later boundaries will have to be tested and I think it’s better to do it now.

3 Likes
13

I am also in favour of this fee increase, with the justification of gathering more data and to encourage less minting and more burning in the system. We are after all trying to either lower the TVL or increase the price of the REN token.

I do believe with these fee increases, an absolute maximum should be set and thoroughly communicated so that the user of RenVM knows that these fees will change but not beyond a certain value (could this be hardcoded in?).

This is more relevant for the burn fee, as it gives assurance that the protocol won’t ‘trap’ someone in by having a low mint and burn fee when creating RenBTC for example but then increasing the burn fee to extract as much value when they redeem BTC.

2 Likes
14

It seems the 0.2% fee bump worked splendidly. We originally set out to try out increasing it unless it lowered amount pulled in. The service Ren provides is best in class and that deserves a proper fee structure. It would be nice to have a competitive fee structure like ethereum gas but i think RenVM may be too “powerful” for that speed wise where virtually it could push every tx for 1 gas and bidding would never occur. I am interested in the shifting fee scale as well Defi Frog mentioned, but until then i think increasing mint or burn, not both imo, is a good route.

2 Likes
15

The impact of a fee increase is already very difficult to see with all the noise of yield farming. I think we have to make bold moves if we want to be able to see effects.

By the way, we are already making smaller steps. We started with 100% increase and now it’s only 50%…

I am in favor of the proposal.

2 Likes
16

No. If the product was just renbtc or renbch, renzec, renfil , etc. Then OK.
But it isn’t.
Ren is a backend. At least that will generate the most volume, volume == $$$$.
If you squeeze all the profit out of an integration they will not do it.
The argument has been made that we need to reduce the ratio of renbtc to ren for security purposes by raising fees.
That make no sense. Kill off the project with increasingly expensive fees for security reasons.
The correct path is to increase volume. With integrations and additional products. This will increase the volume of renbtc etc, increase the fees earned and increase the value of ren. Thereby reducing the ratio of renbtc to ren

BTW, I am getting tired of having to address new “Lets jack up the fees” proposals every few days.
It is getting old.

3 Likes
17

I fully support the proposal.

Its been already almost six months of RenVM operating completely slick and flawless with a tremendous user experience.

We processed more than $1.6 billion already which is a big success and it grows everyday. This is a huge responsibility and such responsibility costs.

We must appreciate our product. It is common knowledge that a quality service has its price and in the world of business this is normal. Our product is made for big things and our goal is big users / players who will do big transactions. For such users, the number one priority is for their transaction to safely come from point A to B. The price of the fee they will pay for that transaction is a side issue to them.

Recently, we have witnessed various failures in the security of other projects that have resulted in the loss of funds. I think that for those who have lost those funds, the least problem is the transaction fee.

Also, let’s just look at our token which is listed on all the major exchange offices. Let’s look at the integrations that are coming. Let’s see how our team and our leaders are valued in their field.

It all came not overnight, but through years of hard and dedicated work. Now when we finally have a product that works perfectly together with a great team and community, I feel we have all the conditions to support this proposal.

This is nothing arrogant and aggressive, but completely justified.

3 Likes
18

In favor - my reasoning as follows:

First of all it is important to be clear on what is absolutely necessary for a project like this to succeed.

  • Centralized approach long term is out of the question.
  • Security is critical, without security, trust (centralization) will be the fallback.

We know the consensus mechanism is intact as long as not more than 1/3 of the network has not been compromised with malicious behaviour. In other words, if TVL is higher than the cost to control 1/3 of all ren nodes then there IS an incentive to compromise the network.

I hear many scream “adoption first, fee adjustment later” which sounds shortsighted as the most exponential growth will only come when DEcentralized, trustless, secure interoperability is achieved.

Right now roughly $42mill is locked in nodes which is ridiculously low in comparison to the TVL. There is no security if it was decentralized right now. I therefore agree that the only important metric is fees earned, even if it means lower volume and TVL. (I know I am over-simplifying since greycore will be an added layer of security later on as well)

Some argue that it can be solved at a later stage AFTER we have achieved higher volume with more integrations and whatnot. I find it hard to believe the people who bring big volume buy that argument. Core/essential issues are always easier to face in early stages simply cause less value is at stake. This discussion would be much more heated if nodes were worth 7 figures. We have seen quite a few contentious decisions in the crypto space throughout the years, let’s learn from that.

As to the argument “volume == $$$”, you cannot disregard fee percentage (volume*fee = income $$$), being clear on terminology and the math behind it is very important for a constructive discussion.

For the argument “if fees are too high people will use wBTC instead” I also disagree, wBTC is a completely different project, the real value is in a trustless decentralized network, BTC is living proof of that. It’s like comparing Uniswap with Coinbase, different value propositions even if within same field.

I also get the impression many assume it is as simple as user A mints and user A burns same renBTC which is incorrect in many cases. To clarify, as volumes of DeFi grows many are only providing liquidity by minting renBTC. Whatever fees they pay for the mint they will ensure profit by adding that premium when selling their renBTC. Many will not mint as it is easier to to just sell another coin on e.g. Uniswap for renBTC. The easier it is to exit a system (e.g. burn renBTC) the more confidence there is that there are no strings attached to participate in that system.

Am also in favor of a 5bps increase if that feels more comfortable for people but to me that’s just an emotional response and I suggest 10 bps, even 20 bps. It is easier to lower at a later stage than to increase.

To wrap this up, I don’t believe in decision making rooted in fear, we all know what Ren is going to deliver, decisions should be taken with confidence and clear vision of long term goals.
How is that final product achieved as fast as possible? All this DeFi hype, chasing volumes, fear of losing adoption and whatnot is just the peripheral view that gets more attention due to emotions, understandibly so as many of us have quite a bit at stake in the project.

3 Likes
19

Can you please elaborate? The integrator does not earn anything on RenVM volume. They add their own fees. As does the chain (eg. GASo on ETH). How do we squeeze any of that by adjusting our fees?!

There ist value in bringing BTC to ETH. As long as it is higher than fees, RenVM will be used. We still need to find out where the sweet spot for maximum fee earnings is.

I believe that 0.2% fees have absolutely no impact on the decision of minting renBTC at the moment. 0 I might be wrong, but we need to test it.

By the way, I like the idea of an self-regulating, everchanging fee. Similar to GAS (on ETH or in real life). But first we need to find the parameters to calculate it.

1 Like
20

I personally am not especially in favor of raising tx fees either, eventhough pragmatically i support it until a better solution. For me the logic comes down to we are compensating for not wanting to use continuous fee by raising tx fees, which will make those people minting and burning feel slightly used perhaps like they are paying all the fees where perhaps those requiring the custody service are also using the business but dont pay.