Minimize or Eliminate reliance on DEX swap for LP to function

Ideas
#1

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.

Summary
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

Swap less

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.

1 Like
#2

I’ve come around to this idea at this point!

I think this was a good experiment but ultimately proved dangerous due to some subtle misconceptions about gas limits. Reducing the amount of reliance on something as complex as a DEX is probably the right move, and your point about liquidity migration is definitely valid (if, for example, liquidity migrates to a new popular exchange).

Ultimately a liquidity pool designed around Scaling Liquity’s Stability Pool. A central component of Liquity is the… | by Rick Pardoe | Liquity | Medium feels like the best move to me. There are a few benefits to doing this:

  • No limit to how large of liquidations the pool can handle, you can literally just add the missing liquidity and liquidate immediately and it’ll work every time
  • Having XTZ swapped slowly over time organically is likely better for the peg than one big movement that gets arbed by one robot
  • The Liquidity Pool will have unclaimed XTZ from liquidations that can be delegated for baking rewards, and adding XTZ to the protocol’s treasury would open up some neat possibilities.

It will take time to develop, but I think it’s a great way to ultimately preserve the vision for the pool (the democratic fulfillment and reward of a critical function in the protocol) while reducing a lot of the complexity and danger involved.

2 Likes
#3

Thanks for cleanly presenting some options. Much easier to consider ideas seeing them laid out in an organized way.

#4

This is the way. I like how the current liquidity pool is denominated in kusd but I think the advantages of no swap outweigh plus some of that xtz will be sold for kusd anyhow.

#5

A good choice is to use swapless option - as current liquidity pool KUSD/TEZ is way too small to support KUSD liquidation. The protocol shall take a page out of Terra ANC - Anchor protocol, where anyone can bid for a collateral at any discount and the bidder with the lowest discount will get the collateral - TEZ, and the bid will decide to sell or hold. The bid can use USDC or KUSD or other large liquidity stable coin for bidding.

#6

Yeah I think a good path forward is to eventually have swapless liquidity pool. A bidding system is more involved and would require pretty significant time to develop. Plus I believe that current liquidity would have to be migrated to a new oven contract, but I could be wrong about that (@keefertaylor would know better).