Liquidations 2.0: Technical Summary

[yaronvel]

Regarding the incentives to liquidators, working on keeper bots in the past, and currently working on a project that aims to solve the incentive problem for liquidators (including over makerdao), my view is that without giving a quantifiable incentives, liquidators will only build simple liquidation systems, that will work only if market conditions are convenient. We already work with few keepers and you can read their thoughts here.
We guide them on the makerdao integration, and from the feedback we get, they would never have spend that effort without any soft guarantee on a potential profit.
Without having keepers building non trivial systems, you end up with a stop-loss order mechanism, where liquidations are just being dumped on the market. Which is better than nothing, but does not give rise to a strong backstop.

A problem with blockchain protocols that quantifiable incentives will end up going to the miners, and this is a serious issue and the project i work on tries to prevents it. So I cannot think of a simple change in the dog implementation to solve it.

[Kurt_Barry]

This is one of the last pieces being hammered out, but the high-level is that yes, we’ll need to replace the End. We should have more information within a couple days.

[yaronvel]

If it is not too late, would you consider one of the following requests:

1. having a getChop(bytes32 ilk) in the dog and/or end contracts. Or even better, in some persistent contract that the dao will regularly maintain.
2. have the address of the end contract in some persistent contract.
3. Or more practically have ways to identify contracts in a trust-less way. E.g., the dog function will have isDog() boolean that returns true. And then projects that integrate could assume that if contract X returns true for isDog AND vat.wards(X) == 1, then this is the dog contract.

Regarding the planned change, would appreciate a spoiler on whether the new end will have a dog() function.
Our strategy to fetch chop would be:

1. if a contract X has cat() function and vat.wards(x)==1, then return X.cat().ilks().chop.
2. else, if a contract X has dog() then return it with dog.

[Kurt_Barry]

To the point about trustless identification of contracts: there’s an on-chain contract registry in the works, probably coming out within a few weeks (cc @BrianMcMakerDAO). As for chop, I guess the difficulty is that since it’s a struct member, it’s not necessarily so straightforward to read it without knowing exactly the code? I don’t think it hurts anything to have a getChop (preferably on the liquidation contract), so we can add that.

I’d say with very high probability the new End will have a dog() function. The only way I see it not having that is if we decide to re-use the Cat name (current thinking is that since the new liquidator contract is somewhat specialized to the new auctions, it should have a different name to avoid confusion). There should be a PR for this within the next 2 weeks.

[amyjung]

Call is happening now: [Agenda/Discussion] LIQ-2.0 Stakeholder Discussion - Wednesday, October 14, 2020 17:00:00 UTC

[yaronvel]

pinging to ask if there is more info about that.
Also @BrianMcMakerDAO if there is new info/timelines for the registry.

[Kurt_Barry]

Not quite yet; @wil is working on it.

[niemerg]

Is there anywhere to follow along with developments for this? Changing the End contract would mean that Yield Protocol would not be able to shutdown in the event of an Emergency Shutdown.

[Kurt_Barry]

I’d say that at the moment, following the forums probably is the best way. There’s a lot of noise here though, so if you depend on the Maker protocol in a big way, it’s probably prudent to get in touch with someone involved w/development directly and explain exactly what your dependency is, what things you’d ideally like to see, etc. I think a lesson here is that for future upgrades we should make the design public sooner and overcommunicate potentially breaking changes. We may also need to think about using upgradability patterns that preserve addresses, although I don’t know that we could ever promise complete ABI immutability.

[cmooney]

The smart contracts team has added a new section to the technical summary entitled UPDATE: liquidation Incentive Mechanism. I’ve included the text here for further review and discussion:

UPDATE: Liquidation Incentive Mechanism

After discussion in the above section (“An Open Question”), it was decided that an incentive mechanism should be added for liquidators. The final chosen form for the incentive was, on a per-collateral type basis, a constant amount of DAI plus an amount of DAI that scales linearly with the amount of debt associated with the liquidation. Either contribution can be set to zero. The reasoning behind these choices is as follows:

• The reward is set per-collateral to give maximum flexibility to include not just per-collateral risk parameters like mat (collateralization ratio) and chop (liquidation penalty) in its setting, but also to allow for unique market conditions that might only apply to one or a few collateral types.
• The component of the reward that increases linearly with the total Vault debt is intended to be used to reward liquidators for reducing risk to the system, as risk itself scales with the size of undercollateralized Vaults—a Vault that is twice as big as another represents twice the risk of bad debt accrual. Or viewed another way, liquidating two vaults of size X represents the same risk reduction as liquidating one Vault of size 2X—thus the reward to a liquidator ought to be similar. Further, the system can afford to pay more for larger liquidations, because the liquidation penalty is also proportional to the amount of debt outstanding for a given Vault.
• The constant component of the reward can be used to cover gas costs (which are per-Vault for liquidators) or to allow MKR holders to effectively pay Keepers to clear small Vaults that would otherwise not be attractive for liquidation.

These parameters must be set extremely carefully, lest it be possible to exploit the system by “farming” liquidation rewards (e.g. creating Vaults with the intention of liquidating them and profiting from the too-high rewards). Generally, the liquidation reward should remain less than the liquidation penalty by some margin of safety, at least to ensure the system is not accruing a deficit from liquidations. Liquidators should also be made aware of this feature, lest they be unable to extract the DAI they are awarded due to liquidating via a custom contract.

[g_dip]

I’m having a bit of trouble following. Could you give an example of a hypothetical liquidation?

[swakya]

I’m confused, liquidation penalty is a % so isn’t the linear component of the reward easily made safe? And you’re opening yourself up for farming with the fixed component, for not much gain: if a vault is not worth it it’s not worth it, no? (And gas costs are just the usual costs of doing stuff on the chain).

[Kurt_Barry]

The linear component is generally safe if kept well below chop, yes.

The constant component might be useful e.g. if for some reason the protocol ends up with a lot of dusty Vaults and wants to incentivize Keepers to clean them up–otherwise these accrue fees that look like surplus but aren’t, and if not dealt with could threaten the backing of DAI. It could also be useful to respond to increasing gas prices–gas cost to liquidate is independent of Vault size, so it would be inefficient for the protocol to increase the percent-wise component in response–this would overpay for liquidations of large Vaults (and might underpay for ones that are too small). So long as dust and chop are considered in setting the constant component, farming can be avoided here, too.

Either component can just be set to zero if not needed. Governance might very well decide not to use one or the other, but currently the thinking is that there are enough hypothetical use cases it’s worth having them both, since upgrades of smart contracts are disruptive and risky.

[Kurt_Barry]

Let’s say %-wise reward is 2%, constant reward is 5 DAI.

Liquidate a Vault with 1,000 DAI in debt, receive (0.02 * 1,000) + 5 = 25 DAI.

[yaronvel]

Further to the discussion on the dust parameter in liquidation 1.2, there is an implicit assumption among the community that liquidation 2.0 mechanism will allow Maker to support lower dust parameter as the tip mechanism will incentives users to call bite (in 2.0 bark).

In 1.2 bite currently cost $50 in gas (for 100 gwei gas price), and bark does not seem to be much cheaper.
Looking at the code, I see that the chop parameter is fixed for all debt sizes.
Hence, in order for the tip not to exceed the liquidation penalty, a minimum debt size of roughly $500-1500 is needed (depends on the target gas price).
This is not very different than the current state in 1.2.

[smaugho]

Thank you very much @yaronvel for noting this point. Much more reason for us to look for other mechanism like the one discussed in [Informal Poll] Creating a Bite-Rebate Contract for Keepers Acting on Small Vaults

[ElProgreso]

Yup–looking forward to @Kurt_Barry @BrianMcMakerDAO @cmooney providing the community their take on Yaron’s post. Thank you in advance Gentleman. Y’all are some real MVP’s to the community. And I don’t mean as in “minimum viable product”–more like Michael Jordan

[bit]

I didn’t find any timeline regarding liquidatons 2.0. What’s the current status and when can we expect it to be finished (winter/spring/summer)? Is it still in the blueprint/design phase? Any code written so far? Sorry for my ignorance.

[BrianMcMakerDAO]

@yaronvel

Hence, in order for the tip not to exceed the liquidation penalty, a minimum debt size of roughly $500-1500 is needed (depends on the target gas price).

This is a real possibility. Ultimately the primary goal of liquidations 2.0 is to improve overall access to market liquidity for Dai and remove the effective requirement that keepers must run an expensive external process and archive node. We’re still going to be constrained by the economic realities of the gas market.

[yaronvel]

I opened an issue suggesting to add the tip to the tab. Imo it could solve the issue. But idk if it is too late in terms of timelines.
Either way, if liquidation 2.0 will not solve it, then it should be pointed out clearly in the current discussions regarding the dust level.
I am under the impression many believe it will be fixed in 2.0.