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.

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.