This thread is to discuss what path would be the most reasonable to follow to lower reliance on third-party DEX liquidation, and/or whether it is worth it to do so at all (technically and feasibly).
I think the DEX swaps for liquidations are a bottleneck in the protocol. I would like to consider ways that we can minimize or eliminate the swap from Kolibri Liquidity Pool functionality.
Issues with using DEX:
1. Cannot liquidate ovens larger than DEX maximum 2. Rely on DEX functionality, continuity, code correctness 3. More avenues to manipulate (DEX LP, DEX Price) 4. If Kolibri protocol grows more than DEX LP, new sources must be found and consistently updated
Benefits of using DEX:
1. Keep Liquidity Pool denominated in kUSD at all times (easier to understand, single-asset) 2. Current functionality already exists (other protocol features can be worked on)
Possible ways to minimize or eliminate
1. allow users to choose to not swap asset 2. swap only a certain portion of liquidated asset
Don’t swap at all
1. do not swap and let user withdraw liquidated portion of XTZ 2. do not swap if oven is over a certain size (but still liquidate) 3. do not swap if DEX price is different from oracle price 4. a separate no-swap pool that users could move to when a large oven is liquidatable
These are just a few of my ideas. If you post additions I will edit and add them. I do not know what is technically the best or most feasible. I do think we should work to move away from reliance on a DEX - especially because it is attached to the core functionality of the protocol.