Symmetric Rebase Upgrade Proposal

Ampleforth Governance
1

I’m glad we are having discussions around the sigmoid function, because there are clearly a lot to talk about here and I don’t think we settled on a solution as a community. I’m going to walk through why I think the current rebase function is imbalanced, and the sigmoid will be too. I will also propose a new function for rebase based on the properties I think we as a community want. Notably, given some changes in market cap we do not want to favor expansion or contraction. That is my designing premise for this rebase function, and when I thought about this and I realized why the history of AMPL has spent more time in contraction than expansion. First lets talk about the problem.

Since February 28, 2019, Ampl market cap has grown from about $10m in market cap to about $120m as of writing, so we have a >10x net growth in market cap. Now lets take a look at the number of rebases in each category (from ampltools.com)
image

48% of all rebases have been negative, and only 30% have been positive. That means we have had over 50% more negative rebases than positive rebases Yet the supply has increased over 10x during that time… I think this is strange and hints at a big problem with how we rebase. Lets dig in.

Linear function was used to make no assumptions about how supply changes should change, but in fact there was a hidden assumption. Now a linear function is the simplest function and easiest to understand. Looking at a graph, it looks symmetrical , but for this use case it is not . This is because while price can go above 100% price target, the price can never go below 100% of the price target. This creates a lopsided supply adjustment curve, and during periods of supply shocks, whether increasing or decreasing, the supply changes are lopsided towards growth.

Lets take an example, price of AMPL goes to +50% price target, that represents a 50% market cap gain, and results in a 5% first daily rebase. The flips side is -50%, and that results in a 50% market cap loss, and the supply contracts 5%. This seems symmetrical and one might think time in growth and decay on average should be about the same. Now what if we go +100% price target, to about 2$? This means that the supply changes 10%, trying to quickly respond to the change in demand. Now what if we need to correct back down to the previous market cap? Well, the price cant go to 0 for a 10% negative rebase, what gives?

There’s something deeper here, and that if the supply increases 10%, that corresponds to a 100% increase in market cap at the price target, and that means if we want to correct back down to previous market cap, we only need to reduce the market cap by 50%. Therefore it would make more mathematical sense to have this match, the rate of change of supply should be proportionally the same to what it would take to return the previous market cap after expansion . So if the supply increases 50%, the rate of change of supply expansion should match the rate of supply contraction if the market cap decreases 33%. NOTE this is exactly how fixed supply market caps change! 50% increase in price requires a 33% decrease to return to previous market cap . The difference with AMPL is we have rate of change of supply to add to the equation, but that rate of change should be proportionally similar to how the marketcap changes in standard tokens if we really do not want to make assumptions about how the supply should change.

I took this principle and tried to formulate it, and here are my conclusions:

Lets assume x = VWAP / target like @Naguib mentioned in his proposal. So for a 50% price increase from target, that results in a value of 3/2. To return to the market cap before the price increase, e.g, target * supply, we need the price to decrease 33%, or multiplied by a scale factor of 2/3. So therefore ideally this function would have the following property:

F(x) = F(x^(-1)) for 0 < x < inf

x can never go to 0, because VWAP is a price. Alright lets plug this bad boy into wolfram alpha

image
image819×371 22.7 KB

Boom there we go thanks Wolfram. So the function that holds this property is |log(x)|. Now lets multiply that by a linear constant a. And then we have:

x = VWAP / Target
F(x) = a * | log(x) |

Now as a community we have to decide that is the appropriate value for a, this basically represents the speed at which our rebase will happen. Perhaps we can choose it based on what minimizes the difference form our existing rebase function? But this is math and modeling that I would have to dig into a bit more.

Before I close up, lets take a look at the graph:

image

So as expected, when there is no need for a rebase (x → 1) | log(x) | is 0. As the price gets closer and closer to 0, the rebase factor goes up very quickly to account for the much smaller market cap. What happens as price increases to very high levels? There is no cap on the supply expansion! The rate of expansion goes up proportionally with market cap, so as the price increases it takes relatively more of an increase to affect the rebase factor, fixing a critical flaw with the current rebase function design.

I think this good because:

  1. Governanced Minimized There is only one parameter we need to tune, a. (Correction… two, see below)
  2. Symmetrical with Market Cap Expansions in supply in response to market cap change happen at the same rate up or down, unlike our current function
  3. Still Simple in Design Its following one core property, rate of change up should match rate of change down relative to market cap. Harder to calculate in your head, but relatively easy to understand why it was chosen.

Thoughts? And please give some recommendations for initializing the parameter a if you are inclined to do so.

UPDATE:

I figured out the full formulation to make F(x) return a scale factor that can be multiplied by supply, e.g:

S’ = S * F(x)

Where S is current supply and S’ is rebased supply.

F(x) =max(b, 1 + a * log (x) )

So I lied, there is an additional parameter b that represents the contraction cap. Hopefully we never get there, but that represents as the price gets so ridiculously low what is the maximum we should be able to contract, since going to 0 or below makes absolutely no sense. I went back to my boy Wolfram:

image

With a = 0.3 and b = 0.5

UPDATE 2: Removed the sign / absolute value functions from the final formula because they cancel each other out

UPDATE 3: @G-Yes95 had a good suggestion for a expansion cap, which makes sense since we have a contraction cap. We can add a expansion cap c that is symmetrical to contraction cap b by taking the reciprocal, because if you multiply something by b, you can undo that change by multiplying it by b^(-1).

b^(-1) = c

This is based on our original note that we are designing this formula to shrink at the same rate that we grow. So for example if b = 0.7, our expansion cap would be 1.4285.

F(x) = min( max( b, 1 + a * log(x) ), b^(-1) )

For a = 0.3, b = 0.7

image

Alternatively we could cap it based on what price we want it to stop influencing the supply adjustment curve. This would mean if b = 0.7, c = 1.3 since the rate of change of supply (in this case it is 0.3) is set to be equal to its inverse. In this example:

F(z) = b = 0.7, z = 0.367879, F(z^(-1)) = c = 1.3

In my opinion either have good arguments for them, but I’m not sure which one is more optimal.

5 Likes
2

This is pretty interesting. Love seeing creative stuff like this. So it looks like you’re proposing an rebase that’s assymetric (wrt price).? I have a few questions if you don’t mind:

  1. Someone correct me if i’m wrong, because I wasn’t around at the time => but it sounds like symmetry is something the Team has “thought about deeply” dating back to late 2018, and specifically decided against it. This isn’t meant to be a criticism, I’m just curious what is different here? It’s possible they didn’t look at it the way you have here.

image
image543×618 30.2 KB

  1. How is this expected to affect bond/tranche holders? If the underlying supply of the collateral can be reduced to 10% or even less of the original on any given day, would that make ampl-bonds/ tranches/ an ampl-backed stable unfeasible?

  2. It seems like this idea was generated on the premise that the existing rebase has a “negative effect” on the community on the other thread. I don’t disagree, although i’d caution that we should remember what Ampl was designed to be and what it’s good at. It’s an asset that can achieve (relative) price stability without any collateral or a lender of last resort. Modifying the protocol under the premise of make existing holders happy seems like it’d be a conflict with what the protocol was designed to be (a stable unit of account).

Either way, I applaud the effort, would be interested in seeing the responses.

3

Okay I realize we might be conflating two forms of symmetry here.

The AMPL protocol is symmetric in that it rebases all wallets proportionally (I think thats what they are referring too, and it seems like they are happy with the symmetry).

The type of symmetry I’m referring to is with respect to market cap changes. I’m not sure what you mean by asymmetric with respect to price? It all depends on how you look at it. Most of the time when we think about AMPL changing it value it has to do with how price affects the overall marketcap. And my point here is that we should contract at the same rate as we expand. But maybe im missing something?

4

@G-Yes95 I’m thinking about symmetry like this:

The rate at which we scale up or down should be proportional with market cap. Therefore, if we go up 50% in price, the rate of expansion should be the same as if we go down 33%. For a standard token, If price goes down 33%, say from $1 to $0.66, then the next day up 50%, to $1, that market cap change net 0 change for a fixed supply token. I think we should make sure the velocity of changes to supply match. So if one day the token price of AMPL is 33% below target, that should be the same rate of contraction as a 50% increase would be to expansion. If the token price was half the price target, then that rate of contraction would be the same rate of expansion for the token price doubling.

AMPL adds time to the equation of supply, and we should make sure we give the same amount of time to expansion and contraction just like how price affects market cap in fixed market cap tokens. The difference for fixed cap coins is the market cap change is not propagated into the supply. I think AMPL should propagate the price information into supply at the same rate up or down as price affects marketcap, so we do not favor more time in contraction or expansion.

I dont think tranches are affected if we set the parameters correctly. b = 0.1 is not realistic, its just an example. I was playing around with some numbers and something that resembles the linear function for the positive range is an a value of around 0.3 which means if we set b to 0.5 the only way it would get there is if AMPL traded at around 0.2. We could set the cap to something more conservative though, maybe 0.75? That would make the point at which if AMPL trades lower it doesn’t affect supply contraction to be around 0.4. Thats still in the “likely never going to get there” territory.

Here is the graph:

image

5

Sorry im doing these individually, but I realized I wanted to say something about this.

I first had the realization that the rebase function was imbalanced. Then I shortly realized after that this is why we spend much more time in contraction then expansion. And then later I realized psychologically that takes a toll on the community, because you are dealing with a greater proportion of time in contraction than expansion. So this idea was not generated just to try to help the community, it was created because I think we should strive to create ideal money that is more symmetrical with how it expands and contracts

6

My comments were before you had the cap in there for the negative rebase. Now that you have that in there, it’s basically the same as what Ganesh proposed for alternative 2. Aala shared this in the discord so I’m sure the team has considered this.

image
image1400×1050 111 KB

My understanding of why the team proposed sigmoid is the cap on positive rebase.

Right now with your log function is monotonically increasing, meaning that when demand comes in from short-term speculators => price rises => larger rebase => price rises more. It becomes a positive feedback loop (until someone sells a lot). The strategy behind sigmoid is to disincentivize short term speculative actors from driving the price that high to begin with. This is done by capping the positive rebase. I.e. would you pay $2 for an Ampl that will rebase the same as if you paid $1.5 for it? Likely not.

So my next question would be why not have a positive rebase cap too?

If you try to add a positive rebase cap to your function, it becomes pretty visually comparable in some ways to sigmoid at that point (with the right params). It’s basically because a ^ (log (x) ) = x. Also the transition from the slope to the cap is continuous with signmoid vs with your log function it would be abrupt/discontinuous which would may lead to volatility at extremities.

image
image1830×727 68.5 KB

7

Good thoughts. I am in favor of adding a positive rebase cap, because without it the formula is not symmetric and we have broken the original design principle. I also agree that having a cap limits speculation to the extremes, and is one of the reasons I liked the sigmoid idea. To keep it uniform I believe the positive rebase cap should be analogous to the negative rebase cap, so the expansion cap should be b^(-1). So in theory if there was a capped contraction, it could be undone with one capped expansion.

Maybe they have considered a log function? I’m curious to hear if they did and what the thinking was around it. That post looked like some good experimentation and musings but I think it would be ideal to build an argument for a rebase function from first principles.

8

Dropping these graphs for better visualization:

Symmetric Sigmoid Function:
(by @kbambridge)

879×305 30.5 KB

Symmetric Sigmoid vs Linear:
u = 0.1, l = -0.1, g = 3

800×800 68.3 KB

u = 0.11, l = -0.11, g = 4

800×800 69.4 KB

Symmetric Sigmoid vs Sigmoid Curve:
u = 0.1, l = -0.1, g = 3

800×800 68.2 KB

u = 0.11, l = -0.11, g = 4

800×800 68.2 KB

If you want to experiment around with the parameters, you can do it here by using the slide bars:
(Desktop recommended)

I’m still thinking about the implications of the symmetric properties, will comment later again.

3 Likes
9

It’s so great to see how the community has advanced its thinking in this area over the last year+.

@kbambridge I think you’ve definitely landed on the key concept around symmetry, in that symmetry in the rebase response curve graph doesn’t translate to symmetry of behavior of supply adjustments. And the historical data definitely supports this.

We’ve explored this idea also but came to a different implementation, actually. You can still see it if you do some code archaeology on the AIP-5 commit history. (See this version for instance)

At the time, the community didn’t seem very receptive to the class of “multiplicative symmetric” functions, because it meant by definition that negative rebases affect the supply “more”. (I.e. it looks steeper than the linear version). So this mirrored property was removed for the straight-up sigmoid version. I’m happy to see that now there’s a greater appetite for both more aggressive contractions around the origin and symmetry.

I like how “natural” the log function solution is… but I really do like the positive and negative asymptotes for security reasons. Can we get both symmetry and asymptotes? We can, if we break the rebase function into two parts then calculate the other part as a transform of the first.

So the positive rebase is the sigmoid, then the negative side is t(F(x)). This gives you the freedom to really have any function you’d like on one side, then simply compute the other based on that. I’d write more here, but the best description is probably in the old AIP draft itself, so I’d recommend referencing that.

Another, simpler way to get this symmetry is to approximate it by configuring that basic sigmoid function the right way. If we don’t need 100% exact symmetry, we can set the ceiling and growth factor how we want, then back into the floor so that it’s still basically close to a mirrored function. So we can still get “basic symmetry” with the simple sigmoid. This gives us symmetry, asymptotes, and simplicity (at the cost of some precision).

2 Likes
10

Ah okay I didn’t see the original AIP. Seems like you all already thought through this. I agree the transform is a nice way to parameterize it because of the flexibility. You can mathematically compose the two functions (natural log and sigmoid) to get a similar result I believe. But coding it in solidity you might have to do the former anyway.

I was also thinking about how much symmetric matters once you cap expansion and contraction, because where the differences are very noticeable are at the extreme expansions scenarios. So I’m tending to think that the solution of tweaking the sigmoid to be close to the symmetric version with logarithmic input is good enough.

11

Multiple groups coming to the same conclusions independently, does reinforce its promise though. Great minds think alike as they say.

So I’m tending to think that the solution of tweaking the sigmoid to be close to the symmetric version with logarithmic input is good enough.

Yeah that’s where I am mostly as well. We can still end up at the fully mirrored implementation at some point if it were determined that that amount of precision would be useful or necessary. A basically-configurable sigmoid can be a good way to step very close to a mirrored system while staying very general at the same time.

2 Likes