As an SDK user, I need to check if routers have no fast liquidity (+aave) from a single endpoint

[alexwhte]

Problem As a user, I would like to know if fast liquidity is even available for my transfer (among all the routers providing liquidity on that chain). I would like to be able to have some kind of estimate that shows whether my transfer will likely be able to be fulfilled using fast liquidity, or it will probably have to use the slow liquidity route.

Ideas to solve this In nxtp v1 theres a UI option In amarok we should consider handling this gracefully for the user

Acceptance Criteria [ ] User does not have transfers go to routers we know are not working [ ] User has transfers automatically directed to routers that ARE working [ ] If NO working routers for selected asset/chains, user is made aware and temporarily unable to bridge

Other v1 options

[jakekidd]

If certain routers are not working we can direct users to one that is

For amarok v2:

• Auctions happen on the backend and are flexible, users don't "lock-in" their router on xcall like they do in v1, the router gets locked-in during the auction phase.
• There will be no preferred routers, since it's counter-principle to decentralization in general.

Improved problem statement would be: As a user, I would like to know if fast liquidity is even available for my transfer (among all the routers providing liquidity on that chain)

This problem has serious hidden complexity. While it's simple enough to basically sum all of that liquidity provided on a given destination chain in a given asset, it's very difficult to know what % of that liquidity is being actively provided by routers that are alive and running.

e.g. some % of routers could have network connectivity issues, actual power issues, could be taking a break from routing, etc.

[jakekidd]

So a complete solution would involve:

• Check to see how much liquidity is provided on chain X in asset Y (read subgraphs or on-chain state for this)
• Cross-reference this with each router's activity.
• Invoke a probability model to determine how much liquidity is likely available.

Probability model. Say: There is 100 tokens of asset Y available on chain X. There are 2 routers (A and B) providing liquidity on chain X in asset Y, each providing about 50% of the total (so 50 tokens each). Router A has done a lot of transfers recently but router B hasn't done a transfer in like 10 days. We might say that probabilistically there is likely only 50 tokens of available liquidity in asset Y on chain X.

If the user wants 10 tokens of asset Y on chain X, we could have a backend API that returns some % odds they will get fast liquidity fulfilled. Here, I'd say it's pretty close to 100%, right?

Well, unfortunately, gets a bit more complex... the user might submit their xcall for 10 tokens at the same time another user submits their xcall for 50 tokens. Router A fulfills the xcall for 50 tokens for the second user, and then can no longer provide 10 tokens for the first user, sad!

Basically, this is a lil project that will very simple for covering the vast majority of use cases where there is plenty of active liquidity, but require a good amount of research to get to a point of high accuracy for edge cases, like inactive/sleepy routers and asynchronous user xcalls racing for that last lil bit of liquidity.

The good news: the slow liquidity route is not bad. 30 mins? most users will be okay with this. It's just a matter of UX optimization to inform them upfront that their xcall has only a X% chance of getting fulfilled using fast liquidity - and if it doesn't, the call will take 30 mins.

[jakekidd]

More data we can feed into this probability model:

• sequencer: which routers are actively bidding? consider their liquidity "hot" or active
• what's the traffic like at this very moment for chain X / asset Y? If it's high, that's going to eat into the probability of getting fulfilled w fast liquidity

[alexwhte]

Can we do this already?

[rhlsthrm]

We already have this and the UI is already reading this AFAIK. Closing for now.