-
Notifications
You must be signed in to change notification settings - Fork 607
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
refactor: state-compatible big decimal tick to sqrt price conversions #6317
Conversation
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.
Nice work. Had a question about monotonicity across the MinInitialized tick boundary (see comment)
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
// Tick corresponding to the at launch min spot price of 10^-12. | ||
MinInitializedTick, MaxTick int64 = -108000000, 342000000 |
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.
Any thoughts on calling these LegacyMinInitializedTick
and LegacyMaxTick
?
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.
tickIndex: types.MinCurrentTickV2, | ||
expectedPrice: types.MinSpotPriceV2, | ||
}, | ||
"tickIndex is MinInitializedTick + 1 ULP": { |
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.
just out of curiosity, what does ULP here stand for?
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.
Unit in the last place https://en.wikipedia.org/wiki/Unit_in_the_last_place
Also, as discussed in previous PRs, please share results of testing state compatibility after all big dec conversion PRs have been merged |
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, nice work. Had a minor concern around spot price similarity between min initialized and min current ticks, but I believe it's safe so approving and leaving that comment as a clarifying question.
// Given BigDec's precision of 36, that cannot be supported. | ||
// The fact that MinInitializedTickV2 and MinCurrentTickV2 translate to the same | ||
// price is acceptable since MinCurrentTickV2 cannot be initialized. | ||
if tickIndex == types.MinInitializedTickV2 || tickIndex == types.MinCurrentTickV2 { |
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.
Hmm this feels like a generally risky thing to do, but just to confirm that it's safe as is, the claim is that one would never be able to create a position on MinCurrentTickV2
and so it's okay if this returns the same price as MinInitializedTickV2
?
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.
Yes, MinCurrentTickV2
can only be reached if all liquidity is drained when swapping zero for one.
However, it does not contain any liquidity itself. Before the swap can begin, we must first cross MinInitializedTickV2
and kick in liquidity into the bucket.
Therefore, the price translation of MinCurrentTickV2
does not play any significant role here
…#6317) * refactor: state-compatible big decimal tick to sqrt price conversions * updates and clean ups * lint (cherry picked from commit 8ac3efb) # Conflicts: # tests/e2e/e2e_cl_test.go # x/concentrated-liquidity/math/math_test.go # x/concentrated-liquidity/math/tick.go # x/concentrated-liquidity/math/tick_test.go # x/concentrated-liquidity/query.go # x/concentrated-liquidity/types/constants.go
… (backport #6317) (#6346) * updates * lint * update fuzz * go mod for osmomath and go work sync --------- Co-authored-by: Roman <[email protected]>
Closes: #6046
What is the purpose of the change
This PR finalizes
BigDec
tick to sqrt price conversion infrastructure, making all relevant CLmath
functions to be ready to support the new extended [10^-30, 10^-12) price range at the lower end.It maintains backwards compatibility with
v19.x
and earlier release lines by returning an error here:osmosis/x/concentrated-liquidity/math/tick.go
Lines 257 to 267 in b335df5
This would make swap or LP logic error consistently with
v19.x
and earlier releases if the current tick / spot price falls under the original minimum.The linked check is to be removed in a subsequent PR.
Testing and Verifying
Drive By Changes
TickToSqrtPrice
that was unused anywhereNotes
Documentation and Release Note
Unreleased
section ofCHANGELOG.md
?Where is the change documented?
x/{module}/README.md
)