Auto Liquidating Ovens

[glcohen]

Liquidation is a key piece of functionality, critical to maintaining the price peg of kUSD and solvency of Kolbiri as a project. Today, liquidation is a manual process and one that is very much first come first serve.

This is not necessarily a problem, but there is an incentive for the technically savvy to capitalize on liquidation opportunities by writing bots or other automation. Could the protocol instead be adapted to strengthen the Kolibri DAO instead of benefitting opportunistic and savvy liquidators?

I’d like to propose a concept of auto-liquidation which in essence means a governance update to remove manual liquidation and to add functionality to automatically liquidate ovens that become insolvent. I break the problem into three distinct components: liquidation signals, liquidating, and distribution.

Liqudiation Signals
To know that an oven is liquidatable, today, Kolibri relies on the Harbinger oracle. As we saw this past week, it is not 100% reliable. A pre-requisite of this proposal may be to have a more robust oracle, independent of the happenings of any centralized company (Coinbase). On the other hand, if the oracle is good enough for Kolibri, it is likely good enough for auto-liquidation – we may be able to decouple this concern.

Liquidating
To liquidate an oven we need to pay for transactions. Since the DAO does not have keys, it can’t pay for transactions. I lack the Tezos technical sophistication to solve this issue, though I could imagine the DAO voting to create a multi-sig wallet that is able to execute these transactions…maybe there’s a more pragmatic approach.

After the key issue is solved there’s the question of how do we pay for these transactions? As a requirement for auto-liquidation I’d like to say that liquidation needs to be self-sustaining. This means, the transaction cost for liquidation should never be able to exceed the liquidation bounty as this creates an exploit to bankrupt the DAO. During liquidation, the funds retrieved are returned to the DAO, which covers the transaction costs of the liquidation operations. This brings us to…

Distribution
Ok, so now we have a new revenue stream to the DAO for ovens that are able to be auto-liquidated, what next? The DAO could choose to build up supply and potentially lower stability fees as a result, or instead pay dividends to DAO members.

Open to any and all questions, comments, and technical input for those who’ve spent more time understanding the Tezos protocol than I.

[fitblip]

Hey @glcohen, apologies for the delay in getting back to you. Thanks for your forum post and your idea!

Could the protocol instead be adapted to strengthen the Kolibri DAO instead of benefitting opportunistic and savvy liquidators?

Just so you’re aware, a recent proposal passed/ratified by the DAO makes the Kolibri Liquidity Pool the primary liquidator for the protocol, so all one needs to do to get liquidation upside is lock kUSD into the pool (which will then be used to liquidate ovens, passing the collateral, minus a 10% fee for the initiator, back to the pool). So in that vein I wouldn’t say it’s only savvy people who can benefit from liquidations, though it absolutely was until fairly recently.

I’d like to propose a concept of auto-liquidation which in essence means a governance update to remove manual liquidation and to add functionality to automatically liquidate ovens that become insolvent. I break the problem into three distinct components: liquidation signals, liquidating, and distribution.

I do like this idea though, having oven liquidations be a fully automated/handled problem would be a very cool thing to have.

Liqudiation Signals
To know that an oven is liquidatable, today, Kolibri relies on the Harbinger oracle. As we saw this past week, it is not 100% reliable. A pre-requisite of this proposal may be to have a more robust oracle, independent of the happenings of any centralized company (Coinbase). On the other hand, if the oracle is good enough for Kolibri, it is likely good enough for auto-liquidation – we may be able to decouple this concern.

One challenge not outlined here is that ovens are currently self-custodial in that each oven is mechanically separate (some defi protocols have ‘vaults’ as an abstraction with one single contract that everyone’s funds are in), with no central point to easily determine if an oven becomes liquidatable. We run indexers to be able to produce things like the “All Ovens” tab, so this is definitely a bit of a challenge to overcome even today.

If we instead move to a more centralized model where it was one master contract and “ovens” are just an abstraction within there, it’d be a much easier thing to build this in. I believe newer DeFi protocols like Liquity do this for this exact reason.

Agreed on the oracle robustness, but we’re discussing ideas on this post for improving things (though a formal KIP is probably warranted) Oracle Outage Retro 11-10-2021

Liquidating
To liquidate an oven we need to pay for transactions. Since the DAO does not have keys, it can’t pay for transactions. I lack the Tezos technical sophistication to solve this issue, though I could imagine the DAO voting to create a multi-sig wallet that is able to execute these transactions…maybe there’s a more pragmatic approach.

After the key issue is solved there’s the question of how do we pay for these transactions? As a requirement for auto-liquidation I’d like to say that liquidation needs to be self-sustaining. This means, the transaction cost for liquidation should never be able to exceed the liquidation bounty as this creates an exploit to bankrupt the DAO. During liquidation, the funds retrieved are returned to the DAO, which covers the transaction costs of the liquidation operations.

If we moved to a more centralized model, it’d be possible to actually check for any liquidations as part of normal operations on-chain, or specific operations like the oracle being updated. At that point the posters pay slightly more, and if we also reward them with a portion of the collateral then it can offset the costs (as you can see on Signal request: Compensate Community Members for Contributions, oracle posters aren’t exactly cheap in the long run!).

The protocol also technically has some XTZ on its books already, it just needs claimed from the Qupiuswap kUSD farm, though having some XTZ owned by the protocol is only half the solution. The other problem is that there needs to be a smart contract invocation of some kind to have liquidations happen (which is why I suggest piggybacking on oracle updates somehow).

Distribution
Ok, so now we have a new revenue stream to the DAO for ovens that are able to be auto-liquidated, what next? The DAO could choose to build up supply and potentially lower stability fees as a result, or instead pay dividends to DAO members.

Today there’s no fees accrued by the protocol as part of the liquidation process - the entire thing is passed on to the liquidation initiator and the existing liquidity pool. I think the idea of capturing fees and passing them along to DAO holders is definitely something that’s mechanically possible though.

[glcohen]

Thanks for the detailed reply @fitblip.

I noticed the LP liquidations after submitting my proposal. I think a proper amendment to my post would be to have LP liquidations be automated.

We run indexers to be able to produce things like the “All Ovens” tab, so this is definitely a bit of a challenge to overcome even today.

I was wondering how these values were calculated today. The indexers do seem another trusted part of the system - is there any oversight by the DAO? If so, and they are trusted in a similar manner to Harbinger or the web hosting, for example, then perhaps the indexer’s signals are sufficient to run auto-liquidation.

I can see the complexity of having all ovens in a single contract. I’m curious how other DeFi protocols mitigate storage/gas fees for contracts that grow so large. If it’s a solvable problem, then perhaps best suited for Kolibri v2 (I’ve seen that mentioned elsewhere). The thought of using oracle updates as an event trigger to check for liquidation events is interesting, I like that!

Today there’s no fees accrued by the protocol as part of the liquidation process - the entire thing is passed on to the liquidation initiator and the existing liquidity pool. I think the idea of capturing fees and passing them along to DAO holders is definitely something that’s mechanically possible though.

Yeah, I suppose this could be an added incentive to participating in the Liquidity Pool or being a DAO token holder.

[fitblip]

Thanks for inquiring!

I was wondering how these values were calculated today. The indexers do seem another trusted part of the system - is there any oversight by the DAO? If so, and they are trusted in a similar manner to Harbinger or the web hosting, for example, then perhaps the indexer’s signals are sufficient to run auto-liquidation.

Yeah as of right now this is something we’re running to feed the frontend and is closed source (though there’s nothing really stopping us from open sourcing it, which I’ll do shortly), but I’m currently working on a DipDup indexer that will replace all that infrastructure and then also be configurable in the frontend like the node selector functionality.

There’s nothing to govern in terms of the DAO, but once the DipDup indexer is live/open source anyone can run their own indexer (and point the frontend to it, with hover labs running one as a public good). Eventually as a pipedream I’d like this to dovetail into a Kolibri OS which is a self-contained tezos node, indexer, and packaged frontends so 100% of the infrastructure to run Kolibri can be self-hosted easily.

I can see the complexity of having all ovens in a single contract. I’m curious how other DeFi protocols mitigate storage/gas fees for contracts that grow so large. If it’s a solvable problem, then perhaps best suited for Kolibri v2 (I’ve seen that mentioned elsewhere). The thought of using oracle updates as an event trigger to check for liquidation events is interesting, I like that!

A single contract would actually significantly simplify things IMO. It’d be necessary to centralize the ovens in order for something like oracle updates checking and auto-liquidating, but I think @keefertaylor is much better to weigh in here since he’s checked out prior art across the industry.

EDIT: Open sourced here! https://github.com/Hover-Labs/kolibri-indexer-v1