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

refactor: state-compatible big decimal tick to sqrt price conversions #6317

Merged
merged 3 commits into from
Sep 8, 2023

Conversation

p0mvn
Copy link
Member

@p0mvn p0mvn commented Sep 5, 2023

Closes: #6046

What is the purpose of the change

This PR finalizes BigDec tick to sqrt price conversion infrastructure, making all relevant CL math 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:

// TODO: remove this check. It is present to maintain backwards state-compatibility with
// v19.x and earlier major releases of Osmosis.
// Once https://github.com/osmosis-labs/osmosis/issues/5726 is fully complete,
// this should be removed.
//
// Backwards state-compatibility is maintained by having the swap and LP logic error
// here in case the price/tick falls below the origina minimum tick bounds that are
// consistent with v19.x and earlier release lines.
if tick < types.MinCurrentTick {
return 0, types.TickIndexMinimumError{MinTick: types.MinCurrentTick}
}

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

  • Covered by existing tests
  • For each changed function, added unit tests at the new price range and the edges.

Drive By Changes

  • Removed obsolete price return from TickToSqrtPrice that was unused anywhere

Notes

  • "V2" notation for min tick and min spot price is temporary and is to be replaced to be the canonical upon epic completion

Documentation and Release Note

  • Does this pull request introduce a new feature or user-facing behavior changes?
  • Changelog entry added to Unreleased section of CHANGELOG.md?

Where is the change documented?

  • Specification (x/{module}/README.md)
  • Osmosis documentation site
  • Code comments?
  • N/A

@p0mvn p0mvn added V:state/compatible/backport State machine compatible PR, should be backported A:backport/v18.x backport patches to v18.x branch A:backport/v19.x backport patches to v19.x branch and removed C:x/concentrated-liquidity labels Sep 5, 2023
Copy link
Contributor

@AlpinYukseloglu AlpinYukseloglu left a 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)

x/concentrated-liquidity/math/tick.go Show resolved Hide resolved
Copy link
Member

@mattverse mattverse 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 +12 to 13
// Tick corresponding to the at launch min spot price of 10^-12.
MinInitializedTick, MaxTick int64 = -108000000, 342000000
Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

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

This naming is temporary and will be changed on completion. Ref: #6318

I like the suggestion and will track in #6318

For now, would prefer to keep it as is to avoid causing conflicts for the PR sequence

x/concentrated-liquidity/types/constants.go Show resolved Hide resolved
tickIndex: types.MinCurrentTickV2,
expectedPrice: types.MinSpotPriceV2,
},
"tickIndex is MinInitializedTick + 1 ULP": {
Copy link
Member

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?

Copy link
Member Author

Choose a reason for hiding this comment

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

x/concentrated-liquidity/math/tick_test.go Show resolved Hide resolved
@mattverse
Copy link
Member

Also, as discussed in previous PRs, please share results of testing state compatibility after all big dec conversion PRs have been merged

Copy link
Contributor

@AlpinYukseloglu AlpinYukseloglu left a 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.

x/concentrated-liquidity/math/tick.go Show resolved Hide resolved
// 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 {
Copy link
Contributor

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?

Copy link
Member Author

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

@p0mvn p0mvn removed the A:backport/v18.x backport patches to v18.x branch label Sep 8, 2023
@p0mvn p0mvn merged commit 8ac3efb into main Sep 8, 2023
@p0mvn p0mvn deleted the roman/state-compat-tick-to-price branch September 8, 2023 15:43
mergify bot pushed a commit that referenced this pull request Sep 8, 2023
…#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
p0mvn added a commit that referenced this pull request Sep 9, 2023
… (backport #6317) (#6346)

* updates

* lint

* update fuzz

* go mod for osmomath and go work sync

---------

Co-authored-by: Roman <[email protected]>
@github-actions github-actions bot mentioned this pull request Apr 15, 2024
@github-actions github-actions bot mentioned this pull request May 1, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A:backport/v19.x backport patches to v19.x branch C:x/concentrated-liquidity V:state/compatible/backport State machine compatible PR, should be backported
Projects
None yet
Development

Successfully merging this pull request may close these issues.

refactor: tick conversion infrastructure and precompute logic to support [10^-30, 10^38] price range
3 participants