RFC-000-031: Setting the initial BurnAndMint fee

Requests For Comment | RFC
1

Name: Setting the initial BurnAndMint fee
Author: Sabobi
Contributors: Maximilian Roszko
Category: Fees
Status: Draft
Scope: With the launch of H2H there will be a new transaction type called BurnAndMint. This is separate from the current Mint transaction and Burn transaction types with possibility of its own separate fee. This RFC is intended to gauge community sentiment around what fee to set and proceed to RIP/voting where Ren team can get a clear direction on what the community has decided as we are closing up to the final stages of H2H release.

Overview

BurnAndMint is a new transaction type being released to Ren mainnet. How is this different from the current Burn transaction and Mint transaction types? With BurnAndMint, a user is going from the same wrapped renXYZ asset to the same renXYZ asset on another chain (e.g. a user going from renBTC on Ethereum to renBTC on Solana). This could previously only be achieved by burning the renBTC to native BTC, and then minting new renBTC on the other chain. That is one extra step and it forces you to pay extra BTC transaction fees which can be costly. With BurnAndMint, there are no underlying BTC transfers, everything is managed within the state of RenVM.

As renBTC has good liquidity already there is a good possibility volume on renBTC movement between various chains and layers grow rapidly with appropriate fees set.

BurnAndMint also cover new cases with the release of H2H, where for instance you could go from renUSDC on Solana to renUSDC on Arbitrum. (Note that if you are going from renUSDC from some chain back to Ethereum, that would only be a burn since you get native USDC back).

Given that this is a new transaction type and can have a different fee from the other transaction types, the community should determine what a good initial fee should be for it, taking into account different use cases and how the fee can influence volume and adoption.

Background

We have previously made changes to fees with contentious discussions regarding the effectiveness. It’s a very complex problem to know how to set fees optimally because it’s not only determined by users’ tolerance for fees, it’s affected by use cases, Ren integrations, current market conditions, current active liquidity mining schemes we could not have predicted beforehand, and so on.

It’s not only a question about volume (usage) but also the rewards, which can go up with a higher fee even if the volume goes down.

On top of that darknode operators care not only about the next epoch rewards, they care about rewards in the future as well. Future rewards are affected by growth, and growth is affected by current fees. And having the highest possible fees currently can have a negative effect on growth as it could price out potential use cases one could build currently that can have volume through Ren in the future.

The most recent fee change was done to influence TVL such that it didn’t increase too much during the Greycore transition, which is a sensitive period from a security perspective where it is prudent not to have too much at stake until decentralization and security is achieved, and this development stage is still ongoing.

As BurnAndMint transactions do not influence TVL (it’s only moving a renXYZ asset that is already custodied by Ren), the TVL concerns that influenced the mint/burn fee do not apply to the BurnAndMint fee, at least not directly.

Details

The BurnAndMint fee could reasonably be somewhere between the fees we’ve used for the burn fee and the mint fee (0.07% and 0.36% respectively). It makes sense to do a sentiment check before we make a RIP with votes, and to determine whether the vote should be weighted sum, winner takes all, quadratic voting or any other voting structure.

Implementation

  • Community to determine the reasonable fee ranges that would be voted on
  • Vote
  • Ren Core team will implement the results when the BurnAndMint is released to mainnet (or if it is already live on mainnet, change the fee to what the community decided after the proposal and voting is complete)
5 Likes
2

In the short term, I’d like to see Ren take some market share back from some of the other bridges, so I think the BurnAndMint fee should be low, even as low as the burn fee.

We also don’t know yet what kinds of apps might pop up utilizing BurnAndMint, and low fees would incentivize experimentation for use cases that may require frequent movement from chain to chain.

5 Likes
3

Thanks for the clean write up Sabobi.

I’m personaly in favor to keep the burnAndMint fee in the low range of you proposition (0.07-0.36%).
The current market conditions combined with a decreasing usage of Ren in general lead me to think that we must keep the fees as low as possible, while still bringing enough value for DNOs.
I’m thinking something between 0.1% and 0.15% (I would vote for 0.1% or even lower).

The burnAndMint brings a disruptive usecase for Ren, with an ocean of potential new integrators.
Lets keep this cheap to build a strong and crowded userbase.

6 Likes
4

Many thanks for the write up Sabobi :+1:

I too agree with the sentiments expressed so far. I think for H2H we should start off as competitive as possible, with the option to increase/tweak fees in the future based on performance/measurable data etc.

I do think the existing RenBridge mint fee is too high, and that the burn fee is too low. I understand the reasons for this given the team’s concerns over TVL - but now and then I would come across comments on social media of people saying the minting fee was too high etc. These are the users we want to keep and attract; not repel.

I think we are too early as a project (and in development) to be charging ‘premium’ fees for our services - and given the community’s concerns over how crowded the interop space is becoming - it makes sense to be as competitive as possible.

We can compete in terms of security, robustness, reliability, and dependability etc. So we should compete on the fee front as well.

For me personally, a major metric of success for H2H would be the volume of transactions generated by Ren - not just fees for DNOs etc.

H2H is a good opportunity to prioritise total TXs > TVL.

4 Likes
5

Just speaking as a community member here, I think we can try to be more growth and competitive focused, and combine with promoting/marketing these paths a bit more aggressively, to bring up volume across chains.

For BTC, it’s always being moved between chains for new farms and balancing Curve BTC pools and arbitrage, and this is where Ren shines above all bridges already and can grab even more of that potential routing volume through our burnAndMint feature.

For stablecoins, especially for paths that don’t involve Ethereum (like Solana to Polygon, Fantom to BSC etc.), those kinds of stablecoin transfers will primarily also be burnAndMint, and here we have tons of competitors to keep in mind. To describe how most of our stablecoin volume would be burnAndMints:

Example. User has USDC on Solana and want to move it to Polygon

  • Swap USDC to renUSDC in a stableswap pool on Solana
  • burnAndMint renUSDC from Solana to Polygon
  • Swap renUSDC to USDC in a stableswap pool Polygon

BurnAndMint does not require any liquidity, so that step is taken care of. Swapping in the stableswap pools a user is paying 0.04% each time though if through something like Curve (small fee but it’s taken twice here), so assuming we can work up liquidity in those stableswap pools so the slippage is minimal, we’re at a minimum already at a fee of 0.08% for routing stablecoins. Just as an example, if we set burnAndMint at 0.10% fee, then the final fee is 0.18% plus some gas costs and some slippage, maybe round that up to 0.20%. What do our competitors charge? 0.20% is likely pretty competitive so we could gain some volume if things heat up and we build up a reputation, but if the burnAndMint fee was 0.25%, then the final fee is more towards 0.35% which gets towards the pretty expensive end, and here we don’t have the luxury of being the only bridge anymore.

What’s cool with burnAndMint is that we can even do routes that are not same asset to same asset paths, and still do it through burnAndMint:

Example. A user has USDT on Arbitrum and wants to move it to MIM on Fantom

  • Swap USDT to renUSDT in a stableswap pool on Arbitrum
  • burnAndMint renUSDT from Arbitrum to Fantom
  • Swap renUSDT to USDT in a stableswap pool on Fantom
  • Swap USDT to MIM in a stableswap pool on Fantom

Here we are looking at 0.12% DEX fee minimum that is regardless of the burnAndMint fee (because 3 separate Curve trades if we use Curve as the example here), and slippage+gas.

I’ve not done the analysis of all of the stablecoin bridging volume between all chains combined and what all the competitors charge, but the volume is likely somewhere in the range of hundreds of millions of $ being moved across chains everyday if not billions of $, and it’s fully possible to grab a big chunk of that with great UX, competitive fees, and ‘brand awareness’.

7 Likes
6

Thank you for putting this important RFC.

I also support low fees in order to push for adoption and market share and as @MaxRoszko commented in his response, a small change can have a big impact depending on the use case. Given the arguments in Max comment, I am now more inclined for a fee between 0.07 and 0.1

@Sabobi sorry if I missed it but how long is the RFC open for comment for?

2 Likes
7

Thank you for putting together this RFC. I do think that we could set a precedent if fees are too low. I like @MaxRoszko post, the way is being analyzed. The fee must be low enough to capture users but too low is leaving money in the table and push as well other bridges to lower their fees. We need to understand the type of users would Ren bring to set the right strategy. Seems a fee in the order of 0.1 probably the right direction, just following Max’s post.

8

Great write up Sabobi, it’s good to see this formalised as a community RFC.

I agree with the general sentiment here that fees should be kept as low as possible to start taking market share from competitors (of which there are now many popping up). Max has done a great job of highlighting this, showing how if we set the fee low (0.10% or below) there is a chance that we can achieve this.

I would support a low fee of 0.08 initially for BurnAndMint, then adjust after. I am even open to going lower than this initially.

1 Like
9

great post sabobi !!! Excellent . I agree with a low rate for b & m, I also think that the mint rate is very high and the burn rate is very low as BlockchainBard commented. nothing more to add I wait for the rip and the vote. thanks max for clarifying some things too …

1 Like
10

Thanks for putting this together @Sabobi!

I too agree with the general sentiment in here, 10 bps is very reasonable to me, though I could definitely go as low as 5 bps.

As for the structure of the RIP vote, I think it makes sense to go with a ranked-choice vote. I dislike a weighted sum vote because we end up with a weird number (e.g. 7 or 36 bps) but more importantly it allows the fee strategy to be pulled away from the consensus strategy. Ultimately when you are talking fees you are talking about the strategy that you employ, e.g. low 5 bps fee to incentivize use and gain market share versus high 40 bps fee to extract rent from price inelastic usage. If you have an 80/20 split between these two options, the low fee strategy clearly has majority consensus, but you end up with 12 bps which might be sub-optimal for both fee strategies.

For this particular vote it might be less of a concern when the sentiment polling already suggests we will go for a “low fee strategy” and the final options will be something along the lines of 5/10/15 bps. However, I’d still argue that it makes most sense to rank the preferences and end up with a bespoke option that has highest consensus preference.

That being said, both parameters (options and strategy) could be determined through a forum poll.

As always, interested to hear other opinions on the above.

6 Likes
11

Sorry I totally missed that part :sweat_smile:
Ideally not too long, hoping we will see a good amount of comments this week and then we can move on to RIP and voting sometime next week if community agrees.

12

I agree with this

this, so much this

Yea agree was thinking of doing that for the RIP if ya’ll agree

2 Likes
13

I would like to suggest setting the BurnAndMint fee as low as 0.01 (1bps). Some points on my thoughts:

  • Even wanted to set zero fee but important to have small amount to remove spam/ddos type of attacks.

  • With the recent success of frog nation movement and their bootstrapping of MIM it would be interesting to see if we could achieve similar case for many assets. Especially renBTC that already has good liquidity. Just imagine the marketing advantage we will have by being able to say “move BTC (as renBTC) between any chain for close to zero (0.01) fee!”

  • Integrators will be able to build and integrate with Ren with more motivation as they can set fees according to their standards (since Ren fees will be so low it could be considered negligible)

  • Arb bots can go wild between low fee chains/layers such as Polygon, Arbitrum, Solana and quite frankly even the more expensive chains.

  • Very high volume can even with 0.01 fee turn out to generate quite nice rewards for DNO depending on how high volume gets. Ren moving billions per day could turn into nice revenue despite the negligible fee.

Strongest counter argument I see is “but are we not leaving potential profit on the table?” which is a valid point, I got some thoughts on that as well:

  • There has been quite a bit of controversy around fees in past, this would be a completely new approach where we in some sense ignore fees and completely focus on GROWTH. Lets get that TVT through the roof :slight_smile: fRen nation can learn from Frog nation hehe

  • It’s important to keep in mind that we still have the regular high fees when people move from native chains to host chains such as native BTC → renBTC. As volume grows with BurnAndMint this will also spur more native assets being moved to host chains and indirectly spur the higher fees as well.

  • Another important reminder is that we will have many assets soon, numerous ERC20, SPL etc tokens that will have the regular mint/burn fees when they leave or come back to their native chains.

Just to give an example if fees are set at 0.01 for BurnAndMint; renUSDC can be moved between Polygon and Arbitrum for a fee of 0.01 creating very good opportunity for projects like Curve to create crosschain pools of assets such as USDC with very low fees despite there being 3 steps in background (USDC to renUSDC on Polygon Curve → then renUSD move to Arbitrum for 0.01 fee → then renUSDC to USDC on Arbitrum Curve)

This will allow native to native movements between chains/layers with very low fees and competitive advantage to other bridges where people are able to move native assets instead of worrying about wrapped assets.

When volume of those kind of pools increase the demand of renUSDC will increase (as it provides liquidity in the background) and indirectly increase the minting of USDC to renUSD from Ethereum to other chains, and those mints will still be 0.36% which increases revenue for DNO.

What I’m trying to point out is that even if BurnAndMint fee is ridiculously low it will still benefit DNO as it indirectly increases the other transaction types with higher fees as well as higher volumes.

2 Likes
14

Agree! I have heard over and over again how “nobody has heard of or talks about Ren”. Well let’s change that and get everyone talking about how great this project is.

Keep mint fees where they are at, or where they need to be to get the needed liquidity at all pools while still creating income for nodes.

We want pools set up, we want them to be used, we want a well worn trail through defi-land between all points Ren. We need to have low fees to attract attention and new users so they become aware of our option.

15

0.01 seems extreme, while I support your
train of thought.

We need numbers… how much volume would we expect? What is our competition doing?

Should we see this as bootstrapping period?

16

Just thinking broadly here, I have not seen many projects fail to take off because of issues of price sensitivity. Of course when ETH transactions started trending into triple digit territory, price sensitivity became a massive issue for Ethereum. However, transactional fees measured in five or 10 bips will likely only be meaningful to those running arb bots or extremely large transaction volumes.

And then it really comes down to competition. We should be thinking in terms of what are all the alternatives to BurnAndMint, and look at a matrix of total transaction costs among a variety of trajectories. You then think about the convenience factor, is it more or less convenient than the alternatives? I’m guessing more by a margin. But maybe not if serious money is on the line and it’s just code executing trades anyway. But for manual users it will be way more convenient.

I think ultimately we want to be priced to attract users from competitive platforms and strategies, but only just. We don’t want to starve the nodes because that node income is how we attract new community members and pay for community development. It also gets more difficult to raise prices when you’ve got a whole bunch of platforms who launched on your protocol, who were happy to gobble up margin the protocol could have enjoyed, and who then have to tell their many users prices are going up.

I don’t have the figures at this point, but I think we ought to strive for fair pricing rather than screaming bargain pricing. With the free wheeling liquidity we all see in the space, i seriously doubt there will be any meaningful difference for most users between five basis points or 15. But we don’t want to pigeon hole ourselves into being too cheap to grow a community and then see platforms come in, buy governance, and make it difficult to raise prices later.

So I say, let’s work out a fair pricing model and compete on function first, and price second.

1 Like
17

.05-.07 seems like sweet spot. Definitely cheaper than any competition, but also maximizing profits for DNO.

18

Having low fees can also help these apps build user bases as well, even if it’s temporary. What we are trying to do is having an “introductory offer” to raise awareness and excitement. If VarenX gets a bunch of new users, and we raise fees later, they have still benefited. If arb bots use us, we also benefit from showing high volume statistics which are great marketing tools. I don’t think raising fees later is bad, it’s like Twitter and Facebook sneaking in ads after they have gained a foothold.
H2H is a big deal and it would be great to do as much as possible to start it out with a bang.

19

wouldn’t this kinda make running a node almost pointless?

20

Yesterday, Anyswap made 200M$ in volume, generating 150k$ in fees (0.075%)
Today, Anyswap made 260M$ in volume, generating 115k$ in fees (0.045%)
If anyone is familiar with how anyswap fee works, I’d be glad to read it.

Here is a table with different fee strategies/number of nodes, to estimate the protocol earnings, assuming a daily volume of 200M$:

revenues
revenues1660×214 82.5 KB

In our princing strategy, I think it’s important to list what a user is paying for while using Ren, because this could differ from competition (level of security, smart contract capabilities, level of decentralization etc.). In that sense, I think we should go agressive, but I agree with @Liberty, we shouldn’t bargain ourselves either.

That being said, 0.01% seems very low, an agressive strategy, with decent darknode earnings would hang more around 0.05% - 0.07% in my view. When I mean decent darknode earnings, I mean enough to attract new DNOs, community members, and REN holders, that’s pretty hard to estimate though.

Happy to read thoughts about this.

1 Like