Stablecoin liquidity pool

[lastperson]

The idea is to extend LiquidityPool with support of multiple assets for borrowing. Technically any other asset can be borrowed as long as it is available in the pool, as long as we allow to withdraw profit only when deposited funds are fully covered.

Simple use case: user wants to get USDT so solver does borrowAndSwap, exchanges 100 USDC to USDT, then later 102 USDT is returned to the pool. At this time we are 100 USDC short. Now we need a way to convert those 102 USDT to USDC to break even and calculate profit. So we convert 102 USDT to USDC, and have 2 USDC as profit. Same could be applied to any other asset (it is just easier with stablecoins, but it is up to the MPC to decide which assets to let borrow/repay).

Implementation details

If we only allow profits withdrawal (in any tokens), from stable pool, when USDC.balanceOf(this) >= Deposited, then all will be good. So just need to add the swapping function. OR borrowAndSwap could be used to swap other stables to USDC, we can even ask solvers to do this.

so minimally we can convert USDC pool to a universal pool by 2 changes:

1. Allow borrowing any token that sits in the pool.
2. Deny withdraw profits if USDC.balanceOf(this) < Deposited.
   Adding the swap (or modifying repay for that) is just a potential UX improvement.

Testing details

Acceptance Criteria

QA Details

[MakMuftic]

@mpetrunic @MakMuftic leave any open questions/ideas

[alexmmueller]

@MakMuftic A current fill via Stash+Aave seems to incur 450k in gas. Do we have feeling for how much gas it would cost if we access dedicated liq in the pool, not needing Aave roundtrip? CC @GregTheGreek

[GregTheGreek]

One thing I've been spending too much time on is how to be hyper competitive on gas (obviously a burden using aave).

Average fillRelay on across is like 100k gas (~$0.008)

Average fill via Stash is 400-450k gas ($0.08)

There a couple potential solutions to drawing it down without needing to do explicit isolated pools, one that I've been constantly coming back to is from the Balancer (the AMM) design. They also use AAVE as an underlying supply pool, but what they do is stash funds (see what I did there lol) in these "buffer" pools that they can hot swap in/out with. Now obviously this would mean we can only borrow the underlying asset (eg: USDC).

What we could do with the pools as suggested in this issue, is actually consider this a queue, where people optimistically to get priority access to being the next LPs in the hub.

This would allow us to incentive them with some kickbacks but also allow us to draw down the total cost of borrowing from aave constantly.

It's like a "queue buffer". So adding a bit of extra logic that allows the hub to draw from this automatically when we raise a cap. But allows us to constantly borrow from it which should draw down our overall gas costs to slightly above a vanilla .transfer. We would need to benchmark a POC of this to verify the gas savings are even worth it though. I'm happy to run some foundry tests to simulate that :)