-
Notifications
You must be signed in to change notification settings - Fork 18
Add ReClamm Pool docs #261
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
base: v3-outline
Are you sure you want to change the base?
Conversation
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
# Conflicts: # docs/integration-guides/aggregators/pool-maths-and-details.md
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.
LGTM!
docs/concepts/explore-available-balancer-pools/reclamm-pool/reclamm-pool-math.md
Outdated
Show resolved
Hide resolved
2. If not, we calculate $\frac{R_a}{R_b}$ and compare with $\frac{V_a}{V_b}$. Since the virtual balances were calculated based on the real balances, these rates are the same near the center of the interval. | ||
1. If $\frac{R_a}{R_b} < \frac{V_a}{V_b}$, $centeredness = \frac{\frac{R_a}{R_b}}{\frac{V_a}{V_b}}=\frac{R_a V_b}{R_b V_a}$ | ||
|
||
2. Otherwise, $centeredness = \frac{\frac{R_b}{R_a}}{\frac{V_b}{V_a}}=\frac{R_b V_a}{R_a V_b}$ |
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.
In the contract, this logic is slightly different, we compare Ra Vb
with Rb Va
since these multiplication operations have more precision than the division. But, honestly, I think explaining like this is more intuitive, so I'd leave as is.
Anyway, maybe it's worth it putting a note than the contract implementation uses multiplications to be more precise? (Or, if the idea is to show only the logic, I'd leave as is)
|
||
$P_a = \frac{R_b + V_b}{R_a + V_a}$ | ||
|
||
We know the desired price *ratio* (max/min), and we see that these values can be derived by setting each real balance to 0. At the edges, one of the balances will be the maximum value, and the other will be 0. The "maximum balance" is really a placeholder needed for intermediate calculations (it will cancel out later), so we can assign it a convenient arbitrary value (e.g., 1000). Given the invariant and these price bounds, we can derive initial values for the virtual balances. |
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.
As mentioned above, the maximum balance is not just a placeholder, in the sense that it has a real meaning. But, in this paragraph it's clearer that the arbitrary value is the placeholder, and not the concept of a maximum value.
Adds ReClamm pool documentation, including a separate page for math, and a new section talking about concentrated liquidity in general to provide context and motivate them.
It's marked "Do not merge" because we are still making substantive changes. It's still good to review, as 95% will stay the same, but not yet in final form.
Also, it's missing API sections for 2-CLP and ReClamm, since I'm not sure where that comes from.