RFC-000-033: Establish Formal Fee Review Schedule

Requests For Comment | RFC
1

Name: Establish Formal Fee Review Schedule
Author(s): Bigbrotha (@bigbrotha)
Contributors: Various community participants (Discord)
Category: Governance, fees
Status: Draft
Scope: Establish formal fee review schedule so that community can discuss and approve fee changes at regular intervals rather than in an ad-hoc manner.

Overview

There are many discussions around minting/burning fees and at what level they should be set. We should expect these types of discussions to reoccur indefinitely as long as the current Ren business model exists. Especially since our fees can have significant impact on TVL, TVB, volume, adoption, etc, and these parameters are always changing. The current process for fee change requires a community member to review current fee structure, gather all relevant data and metrics, try to bring the community around the idea of changing fee structure based on their arguments, and initiate and manage RFC/RIP proposals for voting. It is ad-hoc and non-standard, places a heavy burden on community members (data gathering, analytics, RFC/RIP management, etc.), and makes our fee structure rather unpredictable to our partners and users. This proposal aims to introduce a formal, regular schedule for discussing and approving fee structure changes and standardise the process.

As the Ren ecosystem grows, we can expect to have larger user-base and partners who integrate our technology with their products and they will have reasonable expectations around our security, reliability, and cost. While it is important that we maintain our right to set fee structure, it is unreasonable to expect third-party partners and users to build long-term relationships with Ren ecosystem and just ‘trust’ that we will not change fees on them practically overnight to meet some short-tem goal. Since our users and partners are often not part of our governance discussions, they may not fully understand the reasoning behind our decisions. Having a formal process around fee setting can signal our partners and others not familiar with our internal processes that any fee change decision is data-driven, and predictable, rather than unorganised, and arbitrary.

The proposal calls for the introduction of a regular timetable for fee review sessions where the community reviews and approves any changes to the fee structure which will remain valid until the next fee review date. For example, if the fee review session is scheduled every three months, then any fee structure ratified by the community would be unchangeable for three months until the next fee review session (exceptions can be made for emergency security considerations as determined with Ren team). This provides stability and provides assurance to our users and partners that our fees will remain the same for a certain period.

The frequency of fee review sessions could be set as:
1. Monthly
2. Quarterly
3. Semi-annually
4. Annually

The frequency can be set high, and then decreased over time as the project matures and fee structures can be maintained for longer periods of time. Additionally, having regular intervals for fee structures review ensures that current fees reflect the community sentiment and latest analysis of relevant metrics, ensures ratified fee structures have some staying power, and provides a standard period to measure changes in key metrics as a result of fee changes.

As the fee review session is more operational in nature, we should consider moving the fee proposal/voting out of RIP process and into its own snapshot sub-thread.

Background

This RFC is inspired, in part, by RFC-000-002 and community discussions around DN fee setting system. There has been community interest around the idea of algorithmic fee control system. For these ideas to be implemented, I believe standardisation is the first step.

Out of 11 RIPs submitted for community consideration, 7 of them deal with fee change proposals, and we currently have others still in RFC stage. These types of discussions will likely continue in the future, each requiring a separate RIP each time. This is a burden on individual community members who must introduce and manage their proposals until implementation and it is unpredictable for our own and extended community unless they spend time going through our RFC/RIP workflows to see if any fee change may be coming.

At this point we do not have a formal schedule for when we should expect discussions around fee changes, when would approved fee structures go into effect, what list of metrics should be used to inform fee setting process, and how much fees are allowed to change per period. These features would be needed if we want to foster an image of stability around our cost for our users and partners. As it stands now, it is impossible for us to say with certainty what our fees are going to be next months. This creates a risk for any users and partners planning to rely on Ren for their token bridging needs.

Standardised list of metrics and limits around fee % volatility, while important future steps, are not in the scope of this proposal. This proposal only deals with the frequency of fee review discussion and voting.

Details

This proposal would have the following options for consideration:
1. ad-hoc (No change)
2. Monthly
3. Quarterly
4. Semi-annually
5. Annually

Requirements: Fee review sub-thread should be established to move fee changing discussion outside the RFC/RIP process. Arguments for increase/decreasing fees for the upcoming fee period can be made by community members at any time but no changes can be implemented until final Snapshot vote during the regularly scheduled fee review session. If voting quorum is not met or no consensus cannot be reached, then status-quo is maintained for the next period. At implementation date, 2 days after Snapshot vote, the ratified fees will become effective.

Exceptions: As this would be a governance rule and we should follow our own laws, there should not be any exceptions to the fee review schedule. However, there may be unforeseeable events that may require a change in fee structure for security concerns. It would be prudent to allow for such exceptions but only at discretion of Ren team.

Risks and Drawbacks: Since this proposal brings the topic of fees to the forefront at regular intervals, instead of stability, this system could have the opposite effect by allowing fees to be changed more easily and thus, more frequently than currently done. Another drawback is the reduction in flexibility for our community as we may not be able to react quickly to changing market conditions. I believe the fee volatility risk can be mitigated by introducing limits on how much fees can change per period (for example, +/- 0.1%) which can be introduced if this becomes a problem. The lower flexibility can be mitigated by setting shorter fee periods, i.e., one month, three months, until we feel comfortable with our fee structure. Additionally, we can consider trigger events based on TVL/TVB which would allow us to make changes to fee structure. These triggers should be set so that they are rare and significant enough to warrant such response.

Implementation

  1. This is my first time contributing, so please let me know your feedback and how I can improve my proposal
  2. If there is enough favourable community interest, then RIP will be created
  3. Vote on Snapshot
  4. Create Ren forum sub-thread for fee review discussions
  5. Schedule Snapshot vote at the agreed upon intervals
  6. Implement ratified fee changes only on implementation date
2 Likes
2

Interesting RFC, I agree very much with this part:

And the part I think is the biggest obstacle is:

Agree many (maybe too many) discussions have risen around the fees and frequent changes. I would like to believe this will occur less and less as the project matures and fees become more “sticky”.

1 Like
3

Thank you for the comment. I agree as well. I’d prefer to see a more stable, longer lasting fee structure and fewer discussion around changes but I think there will still be many discussions regardless since we are still adapting. If we are going to have these discussions any way, may still be worth putting structure and ground rules around it.

4

This is a well-intentioned RFC, the defi market is still in its early days so I think it is difficult to set a schedule or cyclical nature of the flow of capital into defi let alone on various chains which are in a constant incentive battle for TVL.

We have 13 epochs a year, but development cycles do not always fall on the quarter-end or a specific date. To me as the protocol improves its feature set, we should as we are doing now evaluate the competitive landscape, question our security and priorities, and set fees to a consistent level until the next upgrade. The goal would be to deliver returns that can be modeled and predicted by DNO and potential DNO, set an annual fee growth schedule that we can live with, and respect over longer periods of time. If that means lowering some fees now, but with an unwavering commitment to raising them later this might be acceptable.

By lowering the fees, and doing so randomly the community draws scrutiny from hedge fund capital and whales who are looking for proof of concept, top-line growth, product differentiation, and income.

If we can continue to prioritize security, yield opportunities, and a feature-rich product, we will earn our stripes and see more TVL. Remember we are still in beta, it is early days.

5

Great proposal, thanks for the write up @Bigbrotha!

Adding more structure to our fee mechanics is a great idea, and the risk of actually having more fee changes than we do now can easily be mitigated by decreasing the frequency through a proposal. As you say, this will likely be the case as the product matures anyways.

That being said, with the current proposals going on and the consideration of having temporary/introductory low fees for the next 3/6 months we should probably wait how that plays out before pulling the trigger on this and introducing the schedule. Which of course does not mean we cannot discuss and further this proposal in the meantime.

1 Like
6

Thank you for the comment! I fully agree with the goal of setting long term fee schedules and maintaining fees for both consistency and reliability. My worry at the moment is that there are no ‘ground rule’ on fee discussions and schedules. If a fee change proposal goes into effect in month 1, it is possible we might have another community member propose another fee change, also for good and valid reason, just 3 weeks later. I don’t think this has been an issue right now, but planning for future, it’s worth considering what ‘ground rules’ we should have around fee changes, especially the frequency of change. This would also serve to gauge the community’s appetite for these type of discussion (should they be occurring frequently, or just a few times a year?).

In your opinion then fees should be set and fixed until the next development release, rather than revisited at certain time interval?

1 Like
7

Thank you :slight_smile:

Yes, agreed. This is not an urgent issue we need to implement now. My goal is start the conversation around what kind of frequency we want to have for these discussion. For example, if a new fee structure goes into effect, how long should we expect them to be immutable until they are up for discussion? At the moment we don’t know.

If this is something the community is interested in implementing, we can already start talking about the details and how the mechanism should look like. Then when we are ready to put this into action we will already have a working version.

8

I agree that current fee setting is very ad-hoc and all over the place, and I’m sympathetic to standardizing the frequency. But I also think it might just be slightly too early to institute something like this. For instance we’ll soon have a completely new transaction type balled burn-and-mint where we haven’t done any experimentation on fees at all. And this transaction type and its fee interacts with the other fees in ways we don’t know yet. Standardizing the frequency now enforces a limitation that can turn disadvantageous.

It would be nice if we can get to a stage where this is algorithmically set, or if some service like Gauntlet could be hired to do economic modelling and help out in our decision-making, but again it’s probably too early to start this kind of thing.

1 Like