Thanks to Brandon Iles for your help with this post.
We are excited to announce two important changes to the Ampleforth system. Following this update:
rebase_reaction_lagvalue will change from
- The daily rebase time will change from
This update will take place on:
1. Amples will be faster
Those of you who are familiar with the Ampleforth whitepaper and redbook already know that every day the protocol automatically adjusts supply in response to the previous day’s 24hr volume weighted average price. As a quick refresher, recall that:
If the price exchange rate differs from the price target by X%, the protocol automatically adjusts supply by (X/rebase_reaction_lag)%
rebase_reaction_lag is an adjustable hyperparameter that was initialized at the time of launch, and its value determines how sensitive the protocol’s supply policy is to changes in price.
• HIGH values make the protocol react SLOWLY to price• LOW values make the protocol react QUICKLY to price
At the time of launch we knew the system would need some amount of smoothing to prevent overcorrection, but having never seen an asset like the AMPL token in any live market — we simply needed to begin with a value that didn’t feel too high or too low.
Now that daily rebases have been executing smoothly and we’ve had the opportunity to observe the market’s response, it’s time to make an adjustment.
Although the current rate of supply response is fast by the standards of any central bank, it is excruciatingly slow by the standards of today’s fast moving cryptocurrency markets.
As a result, it takes far too long for the network to discover and achieve price-supply equilibria. So we’re going to speed things up. Specifically, we are updating the
rebase_reaction_lag value from
2. Rebase will occur at a new time
Additionally, we’ll be changing the daily rebase time from
8PM UTC to
2AM UTC. The aim here is to help decentralize the oracle.
Most data providers aggregate 24hr average prices from midnight-to-midnight. By aligning our operations to this same schedule, we increase the number of aggregators that can be utilized by our oracle system.
This unlocks more providers without requiring integration work to support rolling-window averages.
Sequence of events:
- The last rebase at the old time will occur on
Tue Oct 29th at 8PM UTC
30 hourswill pass
- The first rebase at the new time will occur on
Thu Oct 31st at 2AM UTC
Thanks for tuning in,
Evan Kuo — Ampleforth (co-founder)