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.
If it is not too late, would you consider one of the following requests:
- having a
getChop(bytes32 ilk)in the
endcontracts. Or even better, in some persistent contract that the dao will regularly maintain.
- have the address of the
endcontract in some persistent contract.
- Or more practically have ways to identify contracts in a trust-less way. E.g., the
dogfunction will have
isDog()boolean that returns true. And then projects that integrate could assume that if contract
Xreturns true for
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
Our strategy to fetch
chop would be:
- if a contract
vat.wards(x)==1, then return
- else, if a contract
dog()then return it with dog.
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.
pinging to ask if there is more info about that.
Also @BrianMcMakerDAO if there is new info/timelines for the registry.
Not quite yet; @wil is working on it.
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.
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.
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.
I’m having a bit of trouble following. Could you give an example of a hypothetical liquidation?
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
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
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.
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.
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
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.
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
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
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.
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
I am under the impression many believe it will be fixed in 2.0.
Hey all, quick question - is liquidations 2.0 running on any testnets yet?