RFC-000-003: Adjustment of mint/burn fee %s

I am not sure I agree here. When I think of doing business as a service provider to me the most important thing is customer service. Which to me means that the customer gets what they pay for. Like you said here, they mint and then burn and the only difference will be the fee due to proper arbitrage regardless of the ratio of quantity renbtc to btc. Our job isn’t to persuade people its pegged; it is pegged!

I think the confusion will come if you purchase 1 wBTC At $10,900 and then trade that for 1 renBTC which is priced at $10,800 (due to continuous fee). I see two consequences:

  1. psychological perception that renBTC is of lesser value not just monetarily but somehow indicative of Ren (negative halo effect)
  2. potential confusion by less informed traders. Imagine if an arbitrager thought this was an opportunity and restored the peg 1:1:1 with wBTC and BTC. Then average uninformed consumers would also trade at this price and ultimately receive less BTC because of the continuous fees.

As @hellomoon54321 mentioned, I agree that it opens Ren up to potential poor user experience and greater unnecessary complexity.

Instead of opting for continuous fees, we should consider how to incentivize the increase of mint/burn velocity. I see 2 clear potential areas we can and will grow in this:

  1. wBTC.cafe to increase renBTC mint/burn
  2. burn/mint between chains as different ecosystems offer incentives for liquidity

In an ideal world, we would see yields spike between chains and have people shifting renBTC between these chains multiple times.

i imagine these beginner arbitragers would learn quickly after making that mistake once. My concern does not extend to the arbitrager/keeper.

The arbitrager is not our user.

i find it strange to think anyone who uses renbtc does more than: goes to 1inch to buy it or mint it. Uses it and burns when they are done. The peg through arbitrage will ensure they get the right amount regardless of renbtc quantity

It’s likely that any integration would show the btc value (not the renBTC value) to avoid any confusion. This is a UI issue that is easily solved.

1 Like

I am in favor in adjusting fees to assess how the market behaves, especially a small incremental value of 0.1% for the total fee being 0.2%.

However, I don’t believe changing the fees will really be reflective of how this will affect the usage of RenVM. As has been shown over the last few months with the yield farming craze, people are prepared to take out ridiculous %APY loans and insane risk in un-audited contracts to chase the latest craze. In addition, as long as the economics stack up people will continue to take out flash loans to arbitrage the different BTC prices using RenVM.

By changing the fee to 0.2% mint and keeping the burn at 0.1% there are benefits of doubling the income yield to DN holders as well as gathering data.

I am not in favor of continuous fees, purely for simplicity for the average user 1renBTC should always = 1BTC. Instead, in the future I would like to see the auto-adjustment of fees for each coin used by RenVM based off some mathematical expression for TVL and volume of each coin.

To continue discussion on this topic, I’d like to say for me the simplicity rule of thumb for the average user is: value in terms of btc of renbtc at acquisition must remain the same plus or minus some small arbitragable percentage. This to me has nothing to do with quantity in terms of renbtc quantity, but rather corresponding btc quantity, minus some fee. So the user knows he has 1 btc and the fee is 0.08btc per year, they hold 1 year and end with 0.92 btc. For this example, there really is no need for renbtc quantity as part of the thought process as far as an absolute rule goes, i.e. what matters is underlying corresponding btc quantity.

Thus i am still seeing no reason to save continuous fee as a last resort. I actually think it would be very beneficial sooner than later. For me i worry about bugs in the code whether it be simple and need fixed, such as wrong decimal place used by programmer; or many coins all using different continuous fee multipliers, and one mixes up; or an integration has an issue, although i see this as the least likely because the calculations are all done by renVM in real time

I did note devs said tx fees may also increase in which case it may seem like a lot. Note i didnt say any amount specifically for the continuous fee. It could really be an insignificant amount such as 0.25% per year, even if, for me the biggest point being, this means many people need to take the leap past the mental barrier that renbtc quantity is not the important number as the peg allows for redeemable wrappers back to the other pool as the most direct arbitragesque assurance one could get really.

Edit: one note is i do recognize the counter point that our competitors do not seem to be using a continuous fee. I may see this as slightly unsustainable in the long term but if it gets us a market edge that makes sense.

1 Like