Call is happening now: [Agenda/Discussion] LIQ-2.0 Stakeholder Discussion - Wednesday, October 14, 2020 17:00:00 UTC
2 Likes
pinging to ask if there is more info about that.
Also @brianmcmichael if there is new info/timelines for the registry.
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.
3 Likes
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.
4 Likes
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) andchop(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.
5 Likes
I’m having a bit of trouble following. Could you give an example of a hypothetical liquidation?
1 Like
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).
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.
2 Likes
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.
1 Like
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.
4 Likes
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
1 Like
Yup–looking forward to @Kurt_Barry @brianmcmichael @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 
1 Like
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.
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.
3 Likes
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.
3 Likes
Hey all, quick question - is liquidations 2.0 running on any testnets yet?
1 Like
Hey everyone, just echoing the questions here. Has liquidations 2.0 been scheduled? Has any code been written yet - or has this idea been abandoned?
I’m building an integration product for MakerDAO and some clarity on this could save us a lot of developer hours.
It was built, deployed, and performed impressively during the crash a few weeks back.
https://security.makerdao.com/liquidations-2.0
1 Like
As @Cassius says, LIQ 2.0 is live for all collateral types where flip auctions used to be enabled. In order to integrate I would suggest reading the docs here: Liquidation 2.0 Module - Maker Docs
2 Likes