Edit: I'm changing this post to hopefully give clarity to other people new to the project who might be confused. I fundamentally misunderstood how the lag term was being applied in the supply change calculations. I thought it was a moving average that depended on previous days prices. Instead it is a single factor that weights the supply change as if it were a 10-day moving average, *but only takes into account the single day*. In other words, it is simply a scalar to reduce the swings in supply. In my opinion it would be really helpful to add a description of the calculation and the current lag to the dashboard. Even looking at the dashboard didn't really help to fix my confusion.
Per the whitepaper:
"Each day, the protocol recomputes the supply target based on the latest price difference, and executes as though the targeted change will occur uniformly over the next k days without any memory of the previous day’s supply change."
Okay, I'm probably just confused. Hopefully you can set me straight. In the whitepaper
New supply = (Oracle $ - target price)*Old supply/Target
This formula describes what's been happening in the rebases, but it doesn't behave correctly across a range of prices. Here is an example calculation for the last rebase using numbers similar to the examples from the Redbook.
Oracle price: ~$1.5
Old supply: 100M
New supply: **150M**
**50M** = (Oracle $ - target $)*Old supply/target $
And yet if we look at the last rebase:
Oracle price: ~$2.32
Old supply: 617M
New supply: **696M**
**696M** = (Oracle $ - target $)*Old supply/target $
So what the hell is going on? Looks like the price had been over $2 for the last month or so meaning the 10-day lag shouldn't be changing it that much? Shouldn't the rebase be closer to 2 than 1.1? What am I missing?
If you've never heard of Ampleforth, or if you have heard of Ampleforth but you're confused with why it exists and how it's different from other cryptocurrencies, then this article is for you. Amplefo...