-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add stableswap #115
Add stableswap #115
Conversation
.ok_or(MathError::SubUnderflow(55)) | ||
} | ||
} else { | ||
Ok(self.future_amp_coef) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Wouldn't it be OK to return self.init_amp_coef
as well? We modify it in the { }
above, if we're still ramping up/down. It just seems weird to return "future" as the target.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If there was ramping, there's a difference between the init_amp_coef
and the future_amp_coef
. Over the ramping period the init_amp_coef +/- amp_delta
gets closer to the future_amp_coef
as current_time
increases. When the ramping is over it should return the future_amp_coef
because future_time <= current_time
(the else {...}
block).
Maybe we can reconsider the naming: rename future_*
to target_*
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I didn't notice we don't return from the first block.
When the ramping is over, isn't it the case that init_amp_coef
and future_amp_coef
will be equal?
Also, while the ramping lasts, this method will return future value of Amp coef – is that correct? Imagine ramping is spread across 1000 blocks, so every block the A increases by 1/1000 (a a_delta
) . We'd return the A_init + 1000 * a_delta
here though.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When the ramping is over, isn't it the case that init_amp_coef and future_amp_coef will be equal?
Only if the ramping was stopped with stop_ramp_amp_coef(...)
which sets both init_amp_coef
and future_amp_coef
to the value computed for the current time (block).
Also, while the ramping lasts, this method will return future value of Amp coef – is that correct?
When it lasts (current_time < future_time) it will return init_amp_coef +/- amp_delta
.
The value of init_amp_coef
does not change after the ramping ends because is not necessary since we know that after the ramping ends the value of the A
should be equal to the future_amp_coef
Imagine ramping is spread across 1000 blocks, so every block the A increases by 1/1000 (a a_delta) . We'd return the A_init + 1000 * a_delta here though.
Something like that. Let's assume that A = 11, the current_block = 50 and we want to ramp it to 100 when we reach 1000 block. The values are set to:
- init_amp_coef = 11
- init_time = 50
- future_amp_coef = 100
- future_time = 1000
At a given block N
where N
< future_time, we can compute A like this:
A = init_amp_coef + (future_amp_coef - init_amp_coef) * (N
- init_time) / (future_time - init_time) rounded down
E.g. N
= 500: 11 + (100 - 11) * (500 - 50) / (1000 - 50) = ~53,16 = 53
If N
is greater than future_time we should return the future_amp_coef
.
Because we can't handle floats we can't tell by how much A will change every block (using integers) but we are able to tell what the value of A should be at a given block and that's how the value of A is computed in the ramping period.
This PR adds the
StablePool
contract and all necessary changes from the common-amm-stable-swap repository.