You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is an effort that is not as simple from the performance standpoint.
With split routes, to compute the optimal split we, essentially, do swap estimates in various proportions.
With most pool types, we have the algorithms reimplemented in the router so we compute estimates directly. However, for cw pools, we query the node so that smart contract provides this estimate.
This excessive node querying might lead to the node falling behind or just make the router extremely slow.
We will need to rethink how splits are done if we want to support cw pools.
The problem here is that it is impossible to know a stable perfect split. It keeps changing as liquidity changes and pools are added.
As a result, we keep recomputing it.
We do have various layers of caching to avoid excessive recomputation.
One possible solution is to add another one to compute optimal split proportion in the background and have a custom ttl for token pairs. For example, splits for tokens with higher liquidity need to be recomputed less frequently.
The refactor tracked in #111 should make this simpler
Acceptance Critera
Define a way to support CW pools in split routes
Implement
Test
The text was updated successfully, but these errors were encountered:
This is an effort that is not as simple from the performance standpoint.
With split routes, to compute the optimal split we, essentially, do swap estimates in various proportions.
With most pool types, we have the algorithms reimplemented in the router so we compute estimates directly. However, for cw pools, we query the node so that smart contract provides this estimate.
This excessive node querying might lead to the node falling behind or just make the router extremely slow.
We will need to rethink how splits are done if we want to support cw pools.
The problem here is that it is impossible to know a stable perfect split. It keeps changing as liquidity changes and pools are added.
As a result, we keep recomputing it.
We do have various layers of caching to avoid excessive recomputation.
One possible solution is to add another one to compute optimal split proportion in the background and have a custom ttl for token pairs. For example, splits for tokens with higher liquidity need to be recomputed less frequently.
The refactor tracked in #111 should make this simpler
Acceptance Critera
The text was updated successfully, but these errors were encountered: