Discussions for dynamic fee algorithm

General
#1

I’ve been thinking about the algorithm for dynamic fees and how we might incorporate other factors besides volume. Perhaps a multi-variable equation that would weigh the different major equations based on major news and integrations. This major news weight factor might be tough to automate, but I’d love to get your thoughts.

Here’s the draft algorithm I’ve been tinkering with:

Dynamic fee = (x%)(rolling 7 days equation) + (1-x%)(APY equation)

  • Rolling 7 days equation = equation for changing fee based on past 7 day volume change. Low previous volume, increase fee; high previous volume, decrease fee
  • APY equation = APYs of destination dApps
    A. High apy = high mint fee would increase mint fee in correlation with APY available in dApps
    B. Low apy = high burn fee would increase burn fee as APYs drop
  • X% (the weight to an equation) changes with news and integrations
    A. If there’s new integrations, lower the x value which lowers weight to rolling 7 days
    B. If there’s nothing new, increase the x value which increases weight to rolling 7 days
  • The interval at which the Rolling 7 days, APY equation, and the X values are updated should also be discussed and aligned on

So for example, right now we’d have a lower x value and put greater weight to the low APYs currently in wider DeFi

Model output examples:

For mints:

  • If low previous volume with high APY, highest mint fees
  • If high previous volume with high APY, high mint fees

For burns:

  • If low previous volume and low APY, highest burn fees
  • If high previous volume and low APY, high burn fees

- All other scenarios, default fees

For those with some mathematics / economics chops, I’d love to hear some of your opinions. I haven’t translated the equations into numbers yet; I wanted to get thoughts on the logic first.

P.S. This isn’t meant to be discussions on THE algorithm - rather, I believe there is value in discussing multiple different models and eventually comparing them. This is only the first model I’m pushing to discuss at this point.

Cc: @chicobermuda @Alexander

Edit: with @jontom’s reference to another algo, I’ve realized I’m missing a time element to the algo. I’ve added a bullet regarding this above.

1 Like
RFC-000-007: Increase burning fee to 0.2% on November 16th (start of Epoch 6)
#2

An armchair economics argument against a variable fee structure is that it incentivizes protocol users to time the market: an actor A might have eternal friction to use the protocol because there exists a future path in which the fees are lower. It does not matter much what’s the probability of the fee decreasing, as long as it exists. That is, for a fully rational actor, it would mean that the best time to use Ren is when the fee is as low as possible or when it’s less than the rest of the market can provide. Do you really want a user of the protocol to make such a decision? This is one reason why Apple products are never on sale, because otherwise, now might not be the best time to buy an Apple product.

Mathematically, to formally define what is high or low APY is would assume you are able to quantify it. Can you quantify all available APY available in dApps? One could use an APY aggregator platform like yearn to decide such property, but then you are essentially using yearn as a price oracle. Similar definition problems arise about what constitutes a new integration and what does not, and what is the rationale for the fee to be based on 7 days rolling average. And then, you have the problem of deciding that under what circumstances if at all does there exist a possibility to change these variables.

So, from a quick thought, at least to my perspective, applying variability increases friction and uncertainties to the robustness of the system.

1 Like
#3

@jhv.st These are certainly appropriate risks to consider! I would debate that the risks you’ve outlined hold true for RenVM even today, as we’ve demonstrated through RIP1 that fees will change. The team has also already voiced that they have been considering a dynamic fee since inception (it’s in the white paper TMU).

I’m curious if you have thoughts on how we might best adapt the logic that I’ve posed to better address the risks you’ve raised. My position still stands that implementing an appropriate, automated, and dynamic fee algorithm to price RenVM is better than constant, weekly, epochly, or even quarterly RIPs to adjust fees - I personally and frankly don’t want to allocate a portion of the rest of my life voting on fee changes :stuck_out_tongue_winking_eye:.

1 Like
#4

Gotcha, I will reply back if I am able to gather my thoughts better. I don’t mean to demean your effort, but rather just outline that the question is a rather convex problem, which I think comes back to similar hard questions with Uniswap such as what is the expected return on investment for operating a dark node (in comparison within Uniswap being an LP).

1 Like
#5

No worries at all. I didn’t see your reply that way; I agree that it’s going to be tricky nailing down a good algo, but we have better input info with our joint efforts, which is why I posted this in the first place! :frog:

I’m looking forward to it - I’ve been thinking that perhaps considering additional equations past the 2 I’ve posed could help mitigate the risks you’ve outlined.

#6

If someone intends to use RenVM and decides to wait for an opportune moment when fees are low, they will still end up using it so the end result of use does not change (unless during the wait they stumble across a better solution). I feel having adjusted fees would be a net gain since the protocol would capitalize on market changes and always move toward a position of maximum benefit. When there are opportunities for profit, few will wait and risk losing the opportunity just to save a relatively small amount in transaction fees.