A Liquidation System Redesign: A Pre-MIP Discussion

Dutch auctions will return collateral to the Vault owner as well, if they complete at a sufficiently high price. The auction simply doesn’t accept more than (debt + liquidation penalty) amount of dai, and if that requirement is met before the price gets too low, there will be leftover collateral.

Also who makes the profit if the collateral is sold for more than the OSM price? The protocol? The Vault owner?

The protocol’s profit is only ever the liquidation penalty (at most). Any leftover collateral goes back to the Vault holder.

1 Like

I’d misunderstood initially. Thanks for the clarification. All clear now.

1 Like

Finally nice to see this pop up guys.

Various thoughts not in any particular order.

I see nothing about controlling auction liquidity flow here. What I thought was put into using OSM vs. auction price regarding how much collateral will be allowed to flow through auction. The idea of jamming a shitload of collateral for a lot of DAI ‘all at once’ isn’t really an appealing solution here. But I am quite aware that putting say a OSM to Dutch price collateral liquidity throttle isn’t really appealling from a risk perspective. But think about it from a liquidity perspective. Is it better to jam a ton of collateral into a disjointed market or to use a value for how disjointed the market is (or not) to throttle or accellerate collateral liquidation.?

Another point. IF one groups these liquidations together into a ‘liquidation lot’ I guess basically all the auctions together split the total price right? Here I am wondering whether there will be a liquidation lot size and whether these will vary or not. One is going to want to have some small lots hit simply to sample the market to gather some operational data before jamming a lot more liquidity at it and finding the market price and liquidity is horrible.

Someone was talking about initial pricing on the Dutch. Are you going to use something like OSM*1.1 or something better like last sell price * 1.1 on the new auctions. Point here is once you decide to liquidate you really don’t want to wait too long to hit the market price to clear collateral, but you also don’t want to lower price to aggressively/fast. Again I come back to controlling collateral liquidity offering against the [OSM-last sale prices]/OSM and using this as a kind of market disjointed factor to ‘manage’ what the system is doing.

I know you guys are aware of this but what is the thought about what to do when the market price on auctions vs. OSM is such that attack is possible? Is the system going to still throw out collateral and auction it even at a loss simply to keep getting some data to feed the data for the [OSM-last sale price]/OSM and wait for OSM to come down or last sale prices to come up or just keep jamming Dutch auctions out without much control of collateral liquidity flows when the market to OSM is heavily disjointed?

I keep thinking about liquidity here. Since stablecoins are a collateral type might it be possible to use them during really bad times for people to bid for collateral? The point being stablecoins typically increase in value above $1 during bad times and since we already have these as collateral types in the system why not use not just DAI to bid for collateral but all the stablecoins that can be deposted in the system to mint DAI? Then just reverse out the system positions as DAI liquidity returns to the system? I know this has centralization risks etc and the system wants to work the liquidity all in DAI but has any thought been put towards easing the liquidity constraints on DAI when the system is being hammered by liquidating collateral for stablecoins that can be deposited into the system to mint DAI thereby helping ease liquidity availability for liquidations or do we just want to let the keepers do this?

Oh last question: Where is the technical write up on how this would work in detail.?! lot sizes, pricing decrease/unit time, setting of lower price auction bounds where collateral won’t be sold, etc.

That is about all I have for now on this. I look forward to seeing the details on this.

EDIT ADD: I think given what I wrote above one definitely would want to use different lot sizes and price lowering constraints to sample the markets. Ideally these prices at the various auctions should be used to create a collateralliquidation oracle price which is then used to set the next set of liquidation prices and to be used from this whole how disjointed is the market to the OSM throttling mechanism. Some real deep thought and probably some monte carlo type testing work will have to done against the contract mechanics I think. In the end I think we are still back to wanting to design a system that can probe the market quickly to gather information and then act based on this information. Having a memory is going to be important as well. Is the collateral price fluctuating a lot (up and down) is it just going down did it just bounce?

Think about this. Would we really want to auction collateral if the OSM is telling us the price is Y, when the auction market is paying 1.2 x Y. Sure the vault would get extra collateral back but do we then still auction this collateral or do we maybe hold it back because the auction price being fetched is above someones liquidation point. I think this has huge complexity issues but the idea of pulling back collateral that doesn’t need to be auctioned really has huge benefits in terms of reducing the need to auction collateral which brings me back to this idea that if the OSM drops significantly we end up in this state the system needs to liquidate a lot of collateral which will further depress the market causing a self re-inforcing feedback loop. Notice that most of the people liquidated during black thursday that had liquidation prices between 100-120 USD on ETH - all that had to happen was to wait less than 1 maybe 2 hours and this collateral would have been above the liquidation threshold.

While I want to see a better auction system. I really think some thought being put into how to provide a liquidation threshold buffer in place to try to stave off liquidations might be in order as well because the liquidation system does better and vault owners end up happier (not liquidating) if we can find a way to create some flexability with regards to when to liquidate using a kind of fluid LR threshold based on market conditions. I know this introduces risk to DAI holders and the system in general but again if we can put this whole system on edge into more of ‘the whole damn thing fails at once’ or ‘basically it survives mostly intact with the least amount of liqudiations’ bimodal survive or die model I think it works better generally.

One thing I don’t think I have ever seen really is a kind of risk analysis using current vault situations where the collateral price(s) have to fall to put entire system at risk. For most of the smaller collateral types I think they could crash to zero and it would hurt but not kill the system. ETH on the other hand literally IS the single collateral type that could risk the entire system. I never heard anyone say ETH dropping to like 30-40% value pretty much could wipe out the system vs. 60% in most cases won’t and what this scenario basically means to all the stake holders.

BTW: I think the whole LR flexibility could be accomodated by adjusting Liquidation Fees (using this 13% fee buffer as a kind of LR buffer to flex LR’s to the tune of at least 13% down during severe market stress and giving up the LF during these times).

END EDIT ADD:

3 Likes

I very much support the proposal. About 2 months ago, I wrote about the DAI problems and the liquidation process is one big problem that needs redesign. I also mentioned the need for the liquidation system redesign here.

I am not familiar with most of the technical details so I’ll leave to the devs to find the best solution. The side effect of that redesign is regaining trust in the system and that benefit is huge.

When opening a vault (and later), it would be great to be able to select some kind of notification when the collateral value falls below a certain threshold. I know that there are 3rd party solutions for that but the average user does not know about them. I don’t know if that notification mechanism should be integrated in the proposal (API) or it is a completely separate problem.

1 Like

What were the reasons not to go for Sealed/Batched auctions?

I think sealed/batched auctions would preclude the possibility of single block composability.

4 Likes

In my opinion, one of the most important features of a new design here is going to be how it affects the system’s reliance on oracles. One of the strengths of the current liquidation system (which nevertheless I agree is not perfect), is that while oracles are used to decided whether or not to liquidate, they do not affect how we liquidate. Specifically, given that a liquidation will occur, the oracle value has no impact on the outcome (since the OSM value is not used anywhere beyond the initial liquidation trigger) so price discovery cannot be impeded by a wild oracle value.

This can be compared to a naïve Dutch auction design which kicks off a decreasing-price auction at some spread above the last OSM value, which will catastrophically fail to discover a good price if the last OSM value was significantly below market (apologies for this straw man example, but I didn’t see this issue mentioned anywhere above). While we of course have the OSM delay to try to react to a wild oracle price, note that the failure mode with the naïve Dutch auction in the event that the wild oracle price is not caught in time is probably significantly worse than in the current design, where at least in theory there is a chance to recover some value during the mass liquidations). Note that it’s not easy to solve this problem by just setting a very high initial price spread, since there is currently no restriction on the range of the oracle price.

I think the conclusion is that in order to avoid introducing this new risk, a Dutch auction based design would need to incorporate one or more of:

  • some kind of intelligent liquidation throttling
  • some kind of intelligent initial price discovery, potentially combined with throttling (e.g. if a previous auction cleared immediately then use a higher initial price)
  • some kind of filtering/anomaly detection/sanity checking of OSM prices, when they are used to initialise auctions
  • some kind of circuit breaker that would stop liquidations if there is a wild OSM value (perhaps similar to the one that we already have on ETH liquidations)

It is also worth adding that the DAI lockup multiplier problem during bidding is to some extent currently addressed by the USDC/USDC-B collateral types, i.e. you can effectively bid in USDC and the extra funding cost on a 6-hour bid is 0.028%, though of course the availability is limited by the debt ceiling, (currently two competing bidders cannot finance more than 5mm DAI of open bids at once). Interestingly, if we were to introduce some form of liquidation throttling, we would have more control over how much collateral might be at liquidation at once which would help us plan for this situation.

18 Likes

This is a great point. One possible way of mitigating this is by using a non-linear function to determine the auction price offered, e.g.:

y = dutch auction price offered
t = time since auction began (minutes)
p = OSM price at time auction was triggered
c = time until OSM price is reached (minutes) - constant set by governance

y(t) = (c/t)*p

If c was set as 10 minutes, then:
y(0) = infinity
y(1) = 10*p
y(5) = 2*p
y(10) = p
y(20) = p/2

Another option would be to hard code an initial auction price variable that is comfortably above market price (2-5x) for each collateral package. Auctions could then be initialized either at the hard coded price, or the average of the hard coded price and the OSM price, before swiftly dropping to the OSM price (and below if needed). I believe this is similar to how Compound protects their system from oracle manipulation.

Each of these solutions has the drawback of causing delays to auction settlement, as the time at the beginning when auction price offered is above OSM will not receive bids unless the OSM price is unreasonably low. However, if the “overpriced” period is too short, then the system becomes more vulnerable to network congestion, miner collusion to not mine bids, etc.

11 Likes

Looking at the last two posts by @equivrel and @monet-supply

Completely agree regarding liquidation throttling and price discovery mechanics.

One thing I was thinking is that the above is an actual reason for the protocol to own collateral. Wouldn’t it be better to absorb the cost of market pricing determination by the protocol itself and to maintain a robust auctioning system to basically have two auctions running simultaneously. One to buy the other to sell some amount of collateral using the same dutch system.?

The real issue here is market oracles. I take well @equivrel point regarding issues with using the OSM for price discovery but we have a lot of markets to choose from that we can pull prices from. Uniswap v2 looks to have an interesting on-chain pricing model that could also feed the liquidator here.

Something else that came to mind given consideration of compensation and theoretical collateral return modelling. We know two things.

  1. OSM basically signalled a liquidation (via a keeper activating a kick)
  2. IF the OSM was correct and the liquidation should occur we know if a bidder is not overbidding the theoretical collateral return based on the vault TAB. Why not start the reverse auction bidding just over the nominal theoretical collateral return. Example say 100 ETH is liquidating to capture 10K DAI tab. We know the theoretical collateral return based on the LR(150%) LF (13%) is like 25% so why not start the bidding at 70ETH for 10K DAI?

IF the liquidation market is above this number then I think the liquidator should use that new information to feed into a liquidation OSM price and decide perhaps to hold back on liquidations that have a liquidation price market above the OSM but below the liquidation OSM market as sampled by an actual liquidation.

A few things that look to be true:

  1. Liquidator is going to need some brains
  2. Liquidator is going to need to sample the liquidation market (somehow) to determine the liquidation market price.
  3. The OSM drives initalization of auctions so there is some relevance of the OSM to the liquidator even if the OSM can hang up.
  4. The liquidator is going to need some way to determine if the OSM is whacky or not. Which will probably require more pricing inputs. I think uniswap v2 is interesting, dydx another.
  5. Circuit breaker that activates when Liquidator parameters out outside of a reliable working space.
  6. Liquidation volume management/throttling which should help with managing DAI liquidity.
2 Likes

Primarily, that we cannot take advantage of single block composability as most of these systems have some reveal stage some number of blocks later. We think the strengths of reducing liquidity requirements by making all DEX liquidity available for auctions is too great. What’s more, we can intrablock lend (flash lend) the collateral up for auction at that price with no fee. Combine this with all of DeFi and also the ability to use USDC-A/B in that single block to reduce DAI demand, and this one requirement excluded any auction that would require multiple blocks to settle.

The only other problem I would have with a sealed bidding system would be the complication of the bidding and reveal stages for UI users. There are probably ways to improve UX for these auction types, but I wasn’t a fan of the Vickrey auction UX ENS initially used. I love the price discovery methodology, but it needed to be more user friendly.

2 Likes

@equivrel @monet-supply @MakerMan

Regarding liquidation throttling and how to set that initial liquidation price, the problems you’ve identified and even solutions proposed are all up for discussion. We’ve been thinking about this exact set of problems internally and have some ideas (some of which you’ve already suggested).

I am reluctant to comment yet, because I don’t want to coerce the problem space into something else or influence proposed solutions. This process should help us discover problems we were blind to, and solutions we had not considered. Please keep the ideas coming. How would you exploit a particular design, and what are the countermeasures that would fix that? I’ll try to record novel problems and approaches so they can compete fairly, when we think we’ve found the right solution to one of these sub-problems I may even post it in a new forums thread for final review.

Thank you for putting the time in everyone.

5 Likes

One consideration I’d like to point out that applies to many of the suggestions around improving price discovery (using Uniswap, previous auction settlement values, “probing the market”, etc) is that care is required to ensure that these are not vulnerable to gaming/manipulation themselves. I think ultimately the initial price determination logic will need to take several sources of information into account to be as robust as possible. Throttling/other rate limiting is of course under discussion as well.

1 Like

Something like Uniswap v2’s on-chain price oracle solution? I believe it allows you to get the average price over a timescale of your choice (not entirely sure how it works.) Something like taking the price average over the last week or month, and then adding a fixed percentage is my first thought for initial price determination.

Rate limiting also seems like a great idea.

Is your main concern with the price oracle attack is system stability or fairness towards user? (I assume both are concerns, but still).

2 Likes

Welcome @yaronvel!

I’m assuming that ensuring vaults’ debts are covered (avoiding bad debt) will be the top priority, but optimizing for the best possible price (and therefore the greatest possible return of collateral to liquidated vault owners) will also be an important consideration.

Vaults have 1 hour notice before being liquidated due to the oracle security module delaying price updates, so hopefully liquidations will only happen rarely. With a liquidation penalty of 13%, users should always get more collateral back by liquidating their own position (potentially using a flash loan or automation service like defisaver) versus letting their vault go to auction.

1 Like

Had another thought about this. It seems like the greatest risk with the dutch auction system is an oracle attack that feeds in an unreasonably low price - causes lots of liquidations and the starting price could potentially be far below market. Maybe this risk could be mitigated by limiting the rate of change of the OSM price itself.

E.g. Revise the oracle system to only permit next price to change by a maximum factor of 2x per hour since the last update. For any median price outside of these bounds, the OSM updates the next price to the minimum (last price * (50% ^ time since last update)) or maximum (last price * (200% ^ time since last update)) amount permitted instead of the fed price.

If an oracle attack feeds too low of a price, a rate of price change feature would limit the damage. Side benefit is that this feature could help with oracle attacks feeding too high of a price as well to purposefully generate bad debt.

Drawback is that if a collateral price fell faster than the rate limiter, it could lead to some bad debt accumulating. If a price ever updates limit down, maybe that could be used to trigger an automatic drop of that asset’s DC to 0.

1 Like

@monet-supply hmmm yeah a tweak to the oracle system like that could be a good idea. Depending on exactly how it’s implemented, it could have the side effect of significantly slowing liquidations during a crash, and also if the price recovers quickly, avoid some liquidations entirely. EDIT: of course, it’s not strictly necessary to implement this in the OSM itself, you can track it in the auction instead (probably by having the Spotter poke the auction contract as well).

One other thing that’s been suggested elsewhere but not mentioned in this thread is using the “liquidation price”, which is defined as the price of the collateral in a Vault after adjusting for the liquidation ratio (i.e. the maximum price at which the position could be liquidated). In the case of an oracle attack that artificially crashes the ETH price very suddenly, the liquidation price of most Vaults will be well above the OSM price and thus can be used to set a more reasonable starting value. In reality it should probably just be one of several inputs to the logic that determines the starting price.

7 Likes

To me it seems that the dilemma on how to set initial price is really about what is a reasonable/ideal time for the auction to reach so called “market price”.
I would imagine the rate of the price change to be a main question.

Here are few thoughts on how to mitigate the initial price problem, but not sure how practical they are:

  1. Let governance vote decide on initial price which will always be at least x10-x100 from current market price (and vote again whenever price changes by x10). And in addition have a mechanism for speedy price decrease in the initial phases. E.g., price goes down quickly before X% of the tab was bid.
  2. When tab is big, first do an auction (like with current flipper) on 10% of the tab. Then use the outcome to set an initial price for a dutch auction on the remaining 90%.
  3. Run daily DAI=>GEM and GEM=>DAI (non dutch) auctions for 10k dai qty. and use the price x2 as initial price for that day. Assuming 10% loss in DAI=>GEM=>DAI conversion, this requires a subsidy (dai inflation?) of 1k dai per ilk per day.

All the above have attack vectors and disadvantages, and most importantly probably heavy to implement. But they could be refined to mitigate some of the pitfalls.

Finally a note on OSM price. It should be noted that OSM does not reflect DAI/USD price, hence taking x1.1 over OSM price is a bit borderline, as e.g., on black Thursday DAI was briefly traded for 1.1 USDC.
That said, from a system stability point of view, i guess 1 DAI = 1 USD is good enough.

2 Likes

One more idea about resistance against oracle attacks:

The risk here is mostly one-sided. We are worried about oracles being manipulated to show too low prices which triggers liquidations. Too high prices would lead to auctions not being started. Let’s additionally assume that the oracles were honest recently. This should hold, except well into a long-running attack which should have been reacted to otherwise.

So keep track of the recent maximum price and use that to set the initial price. Due to taking the maximum, it can’t be manipulated downwards.

This does not need tricky governance decisions (except perhaps deciding the period to take the maximum price from) or have costs to run (apart from normal oracle costs).

A multiplier can be applied on top for the same reasons other options have multipliers.

2 Likes

Doesn’t the OSM already take into account many different price feeds? It is good to be cautious, but are we being overly afraid here assuming the OSM cannot be trusted? Surely such a robust attack across multiple price feeds and exchanges would be incredibly difficult to pull off? If we believe this attack vector is feasible, perhaps we should look into restructuring the OSM.

I am also in favor of limiting the amount the price could change in a single update. But maybe even having the price change percent be lower than 50%. Black Thursday we lost about 50% over the course of a day if I remember correctly. Maybe even a max change of 10-20% for a single update would be good. In most cases when there is a dramatic swing like this there tends to be a rebound effect anyway, and so smoothing the curve will likely reduce losses for the protocol.

3 Likes