RFC-000-002: MultiVariable Fee Control Proposal

Requests For Comment | RFC
1

Name: MultiVariable Fee (MVF) Proposal
Category: Governance
Status: Draft

Scope: To create a control system for the fees RenVM (and accompanying UI, to enable dark node operators to visualize and vote on current pricing of fees) intends to charge its customers, and being able to control these fees based on: Crypto Asset being bridged, size of the transaction, direction (burn/mint), there could also be variable rates for each chain (fee income designed to maximize based on the demand of network throughput on-chain). MultiVariable Fee Control System for DN operators could also determine preferences of OFT claiming and 1:1 swapping for DN Income.

Objective: With the goal to maximize market penetration and network income. I foresee that there is an opportunity we should get ahead of. The reality of dealing with crypto business is still in the early days, there is a large variety of new blockchain industries that are creating value and yield in todayā€™s DEFI boom, but who knows where the next innovation for growth might be or which chain. Having a Multi Variable Fee Control System would enable DN operators to vote, visualize network traffic, and maximize income, or maximize incentives to further growth.

Current Fee System
RenVM has established three fees (Minting / Burning, Continuous, Underlying). As of this RFC, the current price level is 0.1% Mint / 0.1% Burn), 0 Continuous, Underlying is passed on to customer, non-discounted). There have been no votes on whether or not these fees are set at an appropriate level, as we are still on RenVM SubZero - Epoch 4.

Details
renBTC, renBCH, renZEC, should each have their own current fee system rate controls/voting panel. Each can adjust their mint by 0.1% up or down lower limiting at 0. The ability for the RenVM network to capture more market share and maximize income lies in the ability to control fees and compete with the future competition, crypto market inflows of capital have been volatile historically, the system and governance needs to be able to increase additional income when the volume is growing at a growing rate, and if growth slows adjust those rates lower to capture more market share by lowering fees to incentive business.

Example:

ETH
renBTC - 0.1% Mint | 0.2% Burn | .008% Continuous | Underlying discount 0%
renBCH - 0.4% Mint | 0.4% Burn | 0% Continuous | Underlying discount 0%
renZEC - 0.2% Mint | 0.2% Burn | 0% Continuous | Underlying discount 0%

DOT
renBTC - 0.6% Mint | 0.6% Burn | .008% Continuous | Underlying discount 0%
renBCH - 0.4% Mint | 0.4% Burn | .008% Continuous | Underlying discount 0%
renZEC - 0.2% Mint | 0.2% Burn | .008% Continuous | Underlying discount 0%

Size Discounts Rate (whale business is the best business)
10 BTC | 0.4% - standard rate
100 BTC | 0.38%
1,000 BTC | 0.36%
10,000 BTC | 0.2%
100,000 BTC | 0.1%

What is Needed
Developer Time, UI Designer Time, Update to CLI, DN Update, Voting Approval

4 Likes
2

These fees are incorrect. Correct fee is .1% etc.

3

@Christael Thank you for your comment. To clarify presented in the RFC are hypothetical examples to show how we could charge different rates for each bridged crypto asset and even different rates for different chains once the multi-chain is launched. Having flexibility in the rate we charge will allow RenVM to be competitive and flexible when we need to be and even help certain new layer 1 chains incentivize customers to bring their wrapped tokens over to their network.

This brings another interesting point up, perhaps there is something to be said about layer 1 teams offering split-rate fees to DN holders to lower the rate their customers would otherwise have to pay to bridge their assets to their chain. Under this concept, the team would pay all DN holders a commission or sort of compensation so that their customers do not have to pay as much.

4

Thank you for your proposal and the effort you put in.

A general note:
Iā€™m in favor of keeping fees low and aim for an increase of volume instead. We should always think long term.

Back to the actual proposal:
Can you elaborate how the voting will work?
Will it be a repeating vote - like vote upfront for each epoch?
If not, how is a vote initialized?
What is needed to pass a vote? Participation rate, majority
Is a vote a combination of all the parameters and we can just pick between several proposals or do you imagine to have a vote for each parameter?

I have some concerns:

  • Customers (REN bridge users) need stability. We shouldnā€™t change the fees very often.
  • Will DN users frequently check their nodes to participate if there is no incentive to vote? I imagine most of the users will just set up the DN and will not actively check about it as time passes (months, years, ā€¦)
5

@XTC0r

Voting
I think voting on fees comes down to breaking down a couple of important factors for DN operators to consider, (volume, duration, size of transfer). I believe our global goal from these votes would be to secure our network by maintaining an adequate DN Bond, at the moment we are very under bonded, it is okay since we are still in the protective hands of the Greycore, but eventually the training wheels will come off and we will need to protect the network by properly incentivizing DN owners with attractive yields.

Voting I should be a recurring epoch item and be initiated by Ren holders, I think that it should list specific options perhaps 5 choices for each parameter (lower .05%, raise .05%, 0 change, raise .1% lower .1%) and let people vote by setting their fee levels accordingly based on the 5 choices, those 5 choices can be managed by Greycore, Ren team, DN community voting, number of ways to address that. I think the majority should win, there just needs to be a way to make sure that only REN holders are voting, and the governance is not affected by outside forces.

Additional Concerns
I believe as long as the UI clearly shows customers of the Bridge the fee amount, and they have to accept it if fees fluctuate with the market that would be an acceptable solution to that concern.

I think by having a vote each epoch, it incentivizes DN operators to check in on their nodes which is a good thing, makes sure they are operating, makes sure they are claiming fees, and doing what they need to do to keep the network secure. If they do not vote, I think that is okay, the people who care more vote and end up having more influence on the network.

6

Chistael is correct. ā€˜As of this RFC, the current price level is .01% Mint / .01% Burnā€™. Both values should be .1%.

7

@Steve , @Christael, ah you all are both correct, for some reason it will not let me go back in and edit that, but it you all are correct in the historical section it was a typo.

8

I like the idea of algorithmically based fees.

As for the variables considered by the algorithm:

  • Asset being bridged :+1:
  • Direction (burn/mint) :+1:
  • Size of transaction :-1: (I am concerned this could be gamed)
  • Chain :-1: (I do not see the value since we already consider the asset being bridged)

I suggest replacing ā€œSize of transactionā€ with something based on overall volume for the specific asset. Something like what @loong described in Fee increase one day maybe?

I imagine the algorithm would include constants. Darknodes should be able to vote on adjusting any constants that are part of the algorithm.

1 Like
9

I am not sure where it could be ā€œgamedā€, but security is extremely important and this is important that people are not spoofing the system or taking advantage of lower rates than they should be charged. In my opinion, if someone is willing to bring 1000BTC+ I believe they should be incentivized to work with us rather than the competition, and the ability to lower the rate for these customers I think is a control lever worth managing as a network.

As for Chain Variable Rates, I think some chains will prove to have better yield and more interesting DEFI opportunities as well more traffic than others, the proposal for fee control is just a way of recognizing this reality and offering DN the ability to control fees based on ā€œdestinationā€.

Greatly appreciate your thoughts and consideration!

10

I think adding this to the backlog of functionality would be interesting, but maybe deprioritized until there is an explicit need. To me it sounds like it could potentially be a bit complex to implement (have to consider front end and back end changes that would need to be made)

I like the idea and believe it holds merit. I think we wait to see what the multi chain activity looks like

11

Yeah, I agree it might take some work, but does create a lot of value for DN holders, and I think as for timing, it is not as important as bringing on more chains but is something that we should knock out before we are totally decentralized, as it would be strange to have some DN on a multi-variable pricing strategy and others not.

12

@loong Any thoughts on this RFC?

13

Thank you for putting this proposal together. I would prefer though reviewing it again once we understand the type of volume RenVM handles when it is in full mode as well as the dynamics of the businesses using the platform.

1 Like
14

@Maggie Thank you for your feedback, no matter how much volume the DN is able to process, I believe having as many control levers available for our community to manage helps us compete with existing and future asset bridges. Implementing this sometime before we enter MainNet One, would be the objective.

15

While I agree with the sentiment to give more levers to the community and Dark Node holders, I think we should be very careful with automatically changing feeā€™s based on votes.

There are a lot more things to consider than merely increasing DN revenue.

For example when increasing the burn fee we should be careful with the expectations that our users and integrators have at the time that they mint their assets. If they have to pay a (significantly) higher fee when burning back than they anticipated at the time of minting this could create a sour experience when using our product.

I feel more for a dynamically adjusted fee as proposed by Loong. Users will know the feeā€™s could change within a certain range based on a known algorithm instead of at the whim of a community vote.

Changes to the algorithm that determines the fees can follow the regular RFC/RIP process so there is an opportunity for all opinions to be heard.

1 Like
16

Although a dynamically adjusted fee proposal hasnā€™t been fully RFCā€™d, I think that having a system that establishes the multiple variable fee control would be the first step towards this higher goal. Once all the various options have been established, and we collect data on how best to maximize returns, then we would be able to automate it, I think one step helps lead to the next.

As I have seen dynamic pricing in the wild it reminds me the most of how UBER operates during peak hours. The price rises when leaving a concert since everyone is trying to leave, and people who are most willing to pay will. This helps maximize revenue but needs data to really learn the limits, so it is great we are exploring that now.

2 Likes
17

Love this idea and think this is ultimately where we should be going. Would love to see more data from manual adjustments and the impact on net fees, volumes etc.

But think dynamic fees should be our ultimate destination.

1 Like
18

@akinsawyerr Thank you, it is the first step, but an important step in the path towards a more dynamic and automated system. Control is key, and if our goal is security, profitability, and flexibility this is an important addition to the network.