feat: allow indexers to know pool_id without a chain query#912
Merged
pr0n00gler merged 2 commits intomainfrom May 14, 2025
Merged
feat: allow indexers to know pool_id without a chain query#912pr0n00gler merged 2 commits intomainfrom
pr0n00gler merged 2 commits intomainfrom
Conversation
Collaborator
pr0n00gler
approved these changes
May 14, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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.
(this PR is a neutron branch version of #876)
Currently there is no way to determine a dex pool's properties (
TickIndexandFee) from every possible dex deposit and withdrawal without performing a chain query (eg.neutrond q dex show-pool-metadata 1).This is very inconvenient for indexers that are attempting to stream real-time data about user<>dex positions and user<>vault<>dex as they are being made, as the requirement to query the chain separately both complicates and slows down the process to stream the data.
The easiest fix is to add the pool ID to the deposit and withdrawal events. An alternative approach would be a separate "new pool" event that would need to be before the deposit or withdrawal, however this is less convenient. It is helpful that the pool ID is attached to the related deposits and withdrawals as it provides an easy way to calculate the running total shares of each pool (sum of
SharesMinted - SharesRemoved).