Optimize GUSD Borrow Repay Pool

When repaying GUSD Borrow with WBTC or ETH, the slippage rate is nearly 13%.

This does not occur with DAI or USDC Borrow balances, however the extreme slippage occurs on every GUSD pair.

Per Discord support, it appears that it is utilizing a certain Uniswap pool for GUSD that is not optimal like Paraswap:

Example of the excessive slippage on AAVE:

Example of the swap on Paraswap:

Note: I was advised to recreate the swap using aTokens, and it appears to be the same, but the screen capture would not be accurate as prices for ETH have changed


The issue is that for repaywithcollateral uniswap v2 pools are utilized which are pretty much empty for some assets now.

In the past there have been multiple prs to unlist certain assets from repaywithcollateral - probably the same should be done with gusd.

Couldn’t we just switch to the optimal Paraswap pool?

That’s definitely something worth looking into - It’s not just switching an address though as currently this uses a onchain router, where paraswap relies on offchain routing.

Soon™ :shushing_face:

1 Like

Apologies but I’m not familiar with what you mentioned, or if your role is related to development.

Is this something users ‘stuck’ in GUSD borrows can depend on upgrading?

At this time it’s unclear how to proceed with funds and would require 8 separate smaller repayment transactions (gas :skull:) to ‘bypass’ the excessive slippage- nearly $15,000!

Currently repayWithCollateral is done trough uniswap v2 pools with a very naive onchain routing: protocol-v2/UniswapRepayAdapter.sol at master · aave/protocol-v2 · GitHub
essentially it’s checking which route on uniswap v2 pools is better assetA->assetB or assetA->WETH->assetB

There’s a pr-proposal for switching to paraswap instead (which will no longer do onchain routing, but use paraswap api) Paraswap Repay Adpter by sameepsi · Pull Request #222 · aave/protocol-v2 · GitHub

Hope that clarifies your question.

1 Like

I appreciate your explanation and I think it helps clarify.

Viewing the GitHub link, it looks like it is somewhat steadily being worked on.

Glad to see this resolution happened to be in progress already. Not sure on what timeframe we are looking at though- months, etc.