Skip to content
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

Merged
merged 4 commits into from
Aug 21, 2024
Merged

Add stableswap #115

merged 4 commits into from
Aug 21, 2024

Conversation

JanKuczma
Copy link
Contributor

This PR adds the StablePool contract and all necessary changes from the common-amm-stable-swap repository.

@JanKuczma JanKuczma requested a review from deuszx August 21, 2024 11:26
.ok_or(MathError::SubUnderflow(55))
}
} else {
Ok(self.future_amp_coef)
Copy link
Collaborator

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.

Copy link
Contributor Author

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_*?

Copy link
Collaborator

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.

Copy link
Contributor Author

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.

@JanKuczma JanKuczma merged commit b798f34 into main Aug 21, 2024
1 check passed
@JanKuczma JanKuczma deleted the add-stableswap branch August 21, 2024 15:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants