Price-filtered, sorted pools query

[jonator]

Background

We implemented a pools filter query for v23 (#3324), however it's somewhat naive in that it expects an exhaustive list of min liquidity amounts to be used to filter each respective pool. This forces frontend teams to maintain a list of min amounts that they'd like to use to filter, which may change as liquidity shifts. We get the performance benefits of less pools, but now must maintain more frontend config.

Suggested Design

Update the new ../filtered_pools query to accept a singe min amount, as well as a sorting key (i.e. liquidity). Perhaps the query could maintain a cache of token prices, and we could admit that this cache is only periodically updated with new prices as filtering pools is a non-critical use of token prices and the prices of major assets shouldn't shift much in within the cache lifetime.

Acceptance Criteria

The query...

1. Accepts a single arbitrary coin amount, and uses that amount to filter pool TVL that is at least the same price as the provided amount.
2. Accepts a preference to sort by liquidity, thus preventing this sorting work from being done on client side.

[stackman27]

@mattverse are you looking into this? if not i can take this issue

[mattverse]

@stackman27 yeah! Feel free to take the issue!

[ValarDragon]

The front-end does need to maintain at least the list of denoms it wants, right? (Since its the case that the front-end is going to have trim pools with assets not in in its assetlist)

I suggest we notice that all main front-end pools have as a component:

• osmo
• atom
• usdc

So we first-pass just expect the front-end to provide min-liquidity in those three assets. (And the filter returns pools with sufficient liquidity in that asset AND all assets in front-end provided assetlist filter)
In a second pass, we can actually get the atom and USDC amounts based off of the osmo price, using the pool specified in whitelisted_fee_token registry.

[stackman27]

@ValarDragon does that mean the prices for assetlist will be calculated in the frontend or should we still expose query for this?

[hieuvubk]

Is anyone working on this?

[jonator]

I believe we've decided against this for now. Mainly for performance reasons, we'll need to use indexing services instead of processing data directly on the node.