Swapping module

[kitanovicd]

We are currently always swapping by using predefined route. This leads to 2 very big inefficiencies:

• We are not swapping in the most optimal way which means that users are losing money on DEX fees and slippage
• We can not raise caps that easily because caps depend on liquidity in that one specific pool not on chain liquidity

In order to solve this we should develop better swapping module. This module should be developed in one of the two ways:

1. More centralized

• Swapping module should have integration with DEX aggregator (Paraswap, 1inch...)
• Before swapping rebalancer needs to fetch the best route and perform rebalance
• DAO should be able to whitelist rebalancers and they should be trusted parties

2. Less centralized

• We should have "liquidator network" that allows people to bid when rebalancing
• This means that people should be able to take borrowed asset and give collateral when rebalancing up
• People should be able to take the collateral asset and give us the debt asset so strategy can repay the debt
• This should not be done entirely in house but should have integration with third parties such as Accross

When developing this assignee should double check how will swapping work on deposit/withdraw/mint/redeem.

From Wes, some options for possible efficient/scalable swapping:

• Don't implement any swapping functionality in contracts. Have an open rebalance function, this function can be called by anyone. This would work like a liquidation, where bots can serve the swap by flash loaning from available chain liquidity. "liquidators"/"swappers" can provide token A from token B as part of a rebalance operation call

[kitanovicd]

After going through each proposed solution in ticket description I can say the following:

Out current implementation has a hardcoded path for swapping. Swapping is done sometimes when deposit/withdraw is done. This solution is good because user can deposit and withdraw very frequently without waiting for action to be proceeded (queue system). Also this is good because strategy strongly follows ERC-4626 standards and is in fact a real vault.

First proposed solution adds centralization to the protocol. Centralization comes from the fact that rebalancers need to be whitelisted and trusted. Also within this solution we still need to solve swapping while doing user actions (deposit, mint, withdraw, redeem). This can be solved in coupe ways:

1. Do the most optimal swap even on user actions. This means the following:

   • Break ERC-4626 standard and add more parameters to the functions
   • Fetch swapping route from BE
   • Put swapping parameters into functions

   This solution adds a lot of centralization to the protocol and also breaks ERC-4626 standard. Breaking a standard is a big deal in my opinion. One of the reasons why we decided to pool people together is to follow the industry standards and be easy to integrate. Here we are losing this big feature.

2. Queue actions

   • When user deposits small amounts that do not trigger looping then we proceed action like we are doing it right now
   • When user deposits bigger amounts that require “looping” then we queue them and let trusted parties calculate the most optimal route for them and execute action
   • This would add queue mechanism to our set of smart contracts similar to what Yearn has

3. Add extra functions for the most optimal route

   • We can keep hardcoded routes like we are doing it now
   • We can add extra functions that have swapping parameters that are fetched from BE or user can set them on their own if they want
   • This will swap only their debt not debt of other users
   • This will keep ERC-4626 standards but also add more functions to it and will keep protocol easy to integrate again but not always with the most optimal DEX cost

4. Develop system where trusted parties can change hardcoded route

   • We should develop bots that calculate best routes through some third party like in solution number 1
   • Route would still be hardcoded but more effective than swapping on one specific DEX pool like we are doing it right now
   • This solution will stay compatible with ERC-4626 standard
   • This solution will not be the most effective one but more effective than the one we currently have

   5. Liquidator network

      • This means that we will never leverage on user actions and that we will only keep deposits in smart contracts
      • We will implement mechanism where everybody will be able to borrow and take that assets for himself and give us collateral asset in order to achieve proper leverage
      • We would implement check so we can be sure that this action will not be malicious
      • Caller will in the background swap debt asset for collateral asset in the most effective way and give us collateral asset and take a little bit of reward for himself
      • This means that protocol will pay a little bit more compared to using the best DEX route but that is cost of decentralization
      • This solution would probably require queue system. Reason for this lays in the fact that user's action can trigger rebalance. Now if we allow user to withdraw his assets just like that then other users are paying liquidator to rebalance properly. This means that action cost goes on other users. This can be solved by adding action fee also.

[fredwes]

Additionally to minimize cost for a liquidator type approach we can use a service like API3 or similar to force actors to provide latest signed price update with their action

[kitanovicd]

I took a look at asynchronous vaults. I think this standards might work fine for users but will bring some problems for meta strategies. I think that meta strategies should be able to quickly go in and out because they have their own rebalancing logic. The only way we can make meta strategies quick is that we put liquidation logic inside meta strategy. This means that flash swap / liquidation logic is placed inside meta strategy. This approach may sound fine but this means that it will be more complex to build meta strategies. Good thing about initial idea is that anyone can come and create meta strategy. With this new approach it is a little bit harder to achieve since someone developing them needs to be liquidator also. Frequently going in and out of sub strategies is more likely to happen on meta strategies that are relying on volatile assets and for this reason I think queueing might not be a good choice.

[kitanovicd]

Important thing to note is the following:

For delta neutral strategies rebalance on meta strategy level will be triggered only when price of collateral token changes. This means that long strategy will have more equity and will need to rebalance up and short strategy to rebalance down. This means that withdrawal can be done from long strategy without looping. Withdrawal can be done by just withdrawing that excess of funds. In those cases I think request should not be queued and should not go through liquidator network. It should be immediately served.

[kitanovicd]

I think building swap/liquidator logic on meta strategy level is not good. I think all those things should lay in the core of the protocol and meta strategies should be builded on top of it.

[kitanovicd]

Also one solution that can make sense is the following:

• We keep queue and liquidators system
• In case no looping is required action can be done immediately without going through queue
• When developing meta strategies we can choose to use already existing liquidator network
• When developing meta strategies we can choose to build our own liquidator that is going to prioritize our meta strategies so they do not wait so much

I think this approach can be fine and will be very effective.