Fix Moola routing issues

[BriungRi]

Some pairs have really bad routes and thus, very bad sliippage. Investigate why and include a fix

[BriungRi]

A simple case is going from mcUSD -> MOO. For 1000 mcUSD, I get recommended mcUSD -> CELO -> UBE -> MOO. It should probably be mcUSD -> CELO -> mCELO -> MOO.

[aaronmgdr]

as i look this seems to be caused by the router only going thru moola router for tokens on the edges (in or out).

this is particuarly an issue with MOO which is pooled with mCELO -- and hence requires mCELO -- CELO to route thru Moola but the router does not try do swap-swap-moola-swap only moola-swaps-swap-swap-moola. (hope that makes sense)

[aaronmgdr]

trying to understand this more. right now what im thinking is that as i wrote on the ticket it will only use moola router for the ends and not in the middle. After looking around the code right now my thought is A) all moola pairs should be included in the allPairs array, B) the Pair class gets a new attribute that says whether this is an Ubeswap pair or a Moola Pair. and then C) that is used when doing the actuall trading. such that Ubswap handles (ceth--mcusd---CELO) moola handles CELO-MCELO and then Ubeswap handles the MCELO-MOO trade.

I have no idea if this is possible smart contract wise but if the inverse is possible it seems like it would be.

[gnardini]

x-posting what I wrote on Moola's discord:

HI! I noticed that there are some issues with the liquidity to buy or sell MOO and mCELO with anything other than CELO on Ubeswap. The issue is that the Moola conversions (like CELO <-> mCELO) can only happen either first or last in the routing, not in the middle of the swap chain since those aren't Ubeswap pools but another contract. So if a user has cUSD and wants MOO (or viceversa) they can't use the CELO <-> mCELO pair so the routing ends up using CELO <-> MOO which has only $2,847 of liquidity so even a 100 cUSD swap causes 7% price impact.

I think a couple potential solutions are to incentivize MOO-CELO instead of MOO-mCELO or to incentivize mCELO-CELO in addition to the current MOO-mCELO so that it can be used in the middle of a routing between tokens.

The smart contract change to split the path in the middle is technically possible but complex so we should look into fixing this with better pool incentives for the short term.

[aaronmgdr]

"when i looked the tricky part (not counting any changes to the actual smart contracts) seemed like it would be for each potential route seeing if converting to mToken improve the route, but maybe instead it could be written to check if a token's highest pair was with an mToken and then assume moola routing there. not sure.

[aaronmgdr]

hmm Look at integrating https://opencelo.gitbook.io/minima/ as a solution to improve routing

[diwu1989]

why does it need to be on-chain vs off-chain? I don't get the benefit of pushing this computation to on-chain, it's just unnecessary load & latency on Forno.

Unless i'm missing something, a pure offline JS implementation is preferable.