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

Chore: Flip Dex Price Logic #NTRN-355 #624

Merged
merged 26 commits into from
Oct 15, 2024
Merged

Conversation

jcompagni10
Copy link
Contributor

Issue
https://hadronlabs.atlassian.net/browse/NTRN-355?atlOrigin=eyJpIjoiYTI0ODY0YTRhNzdhNDQ1NWFlODZhNzE0N2E0ZDk2MmYiLCJwIjoiaiJ9

Currently the dex stores prices as 1.0001^-TickIndex
This has been a persistent confusion for builders and integrators and also introduces unnecessary loss of precision. We can safely flip prices the other way without changing functionality

@jcompagni10 jcompagni10 marked this pull request as ready for review July 31, 2024 23:58
Copy link
Collaborator

Choose a reason for hiding this comment

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

Hm, could you clarify why do you change a code for the previous migration?

I don't think we are supposed to change old migrations

Copy link
Contributor Author

Choose a reason for hiding this comment

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

MustCalcPrice fn has been inverted so to achieve the same migration we must flip the sign. The output of the migration should be the same

Copy link
Contributor

Choose a reason for hiding this comment

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

I think the question was - do we get the same migration output in 2 cases

  1. Our case. User migrates 3 -> 4 (old one) (neutron v4.2.1) and then 4 -> 5. 3 -> old 4 -> 5
  2. Imported dex module to third parthy project. User migrates 3 vesrion -> 5 version (current one). 3 -> new 4 -> 5

I dont think it's safe in terms compatibility to modify already released migrations

Copy link
Collaborator

Choose a reason for hiding this comment

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

Yes, that's exactly what i meant

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't think it's an issue. You can see that the tests are unchanged. So the migrations still produce the same output. @swelf19 @pr0n00gler

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, seems you are right. No changes in output. Dont see any problems with a migration now.

@jcompagni10
Copy link
Contributor Author

@pr0n00gler
Copy link
Collaborator

Unit tests don't work, please fix it

x/dex/keeper/limit_order_tranche.go Show resolved Hide resolved
proto/neutron/dex/pool_reserves.proto Show resolved Hide resolved
Copy link
Contributor

Choose a reason for hiding this comment

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

I think the question was - do we get the same migration output in 2 cases

  1. Our case. User migrates 3 -> 4 (old one) (neutron v4.2.1) and then 4 -> 5. 3 -> old 4 -> 5
  2. Imported dex module to third parthy project. User migrates 3 vesrion -> 5 version (current one). 3 -> new 4 -> 5

I dont think it's safe in terms compatibility to modify already released migrations

@jcompagni10
Copy link
Contributor Author

jcompagni10 commented Sep 3, 2024

@pr0n00gler pr0n00gler marked this pull request as draft September 10, 2024 14:04
@jcompagni10 jcompagni10 marked this pull request as ready for review September 19, 2024 22:17
@jcompagni10
Copy link
Contributor Author

@jcompagni10
Copy link
Contributor Author

jcompagni10 commented Sep 19, 2024

I'm assuming this:

I think the question was - do we get the same migration output in 2 cases
Our case. User migrates 3 -> 4 (old one) (neutron v4.2.1) and then 4 -> 5. 3 -> old 4 -> 5
Imported dex module to third parthy project. User migrates 3 vesrion -> 5 version (current one). 3 -> new 4 -> 5

Was resolved by the comment above @swelf19, please correct me if not

@jcompagni10
Copy link
Contributor Author

@@ -56,7 +56,7 @@ func (k Keeper) Swap(
// but due to rounding and inaccuracy of fixed decimal math, it is possible
Copy link
Contributor

Choose a reason for hiding this comment

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

Should update the comment on ln55

swelf19
swelf19 previously approved these changes Oct 8, 2024
Copy link
Contributor

@swelf19 swelf19 left a comment

Choose a reason for hiding this comment

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

Pls resolve conflicts

@@ -96,7 +96,7 @@ func CalcTickIndexFromPrice(price math_utils.PrecDec) (int64, error) {
return 0, ErrPriceOutsideRange
}

if price.GT(math_utils.OnePrecDec()) {
if price.LT(math_utils.OnePrecDec()) {
Copy link
Contributor

Choose a reason for hiding this comment

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

As far as i understand you need to update comment at line 100 -> >=1

Copy link
Contributor

Choose a reason for hiding this comment

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

Yes, seems you are right. No changes in output. Dont see any problems with a migration now.

@jcompagni10
Copy link
Contributor Author

@pr0n00gler pr0n00gler merged commit 081c5aa into main Oct 15, 2024
7 checks passed
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.

4 participants