Skip to content

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

Open
wants to merge 46 commits into
base: v3-outline
Choose a base branch
from
Open

Add ReClamm Pool docs #261

wants to merge 46 commits into from

Conversation

EndymionJkb
Copy link
Contributor

@EndymionJkb EndymionJkb commented May 1, 2025

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.

Copy link

vercel bot commented May 1, 2025

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name Status Preview Comments Updated (UTC)
docs-v3 ✅ Ready (Inspect) Visit Preview 💬 Add feedback Jun 3, 2025 4:10pm

# Conflicts:
#	docs/integration-guides/aggregators/pool-maths-and-details.md
Copy link
Contributor

@joaobrunoah joaobrunoah left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Comment on lines +129 to +132
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}$
Copy link
Contributor

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.
Copy link
Contributor

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants