Demo: break spot price API to operate on BigDec #6371
Closed
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Closes: #XXX
What is the purpose of the change
This is the demo to decide on the best way of implementing a 36-decimal spot price query.
The suggestion in this PR is to avoid code duplication as much as possible and attempt to break
PoolI
andPoolModuleI
interfaces to operate on 36 decimals in a state-compatible way.In the querier, we can expose two APIs:
It is unclear to me whether it would be client-breaking if we were to start returning a 36 decimal string post-upgrade or not. As a result, we can end up duplicating the querier only
Note that there are probably state breaks present in this PR currently. However, I think that it would be possible to implement it in a state-compatible way incrementally:
PoolI
API, backport and testPoolModuleI
API, backport and testx/twap
issue separately (in the future). Accept that pools with spot spot price below 10^-18 will not have twap functioning on-chain.Pros
BigDec
Cons