As mentioned on Governance and Risk calls we believe LINK-A vault type is a good candidate for a test implementation of Liquidations 2.0. The vault has a safer liquidation ratio and debt exposure is high enough to observe some potential liquidations in real time and in near future.
We don’t expect the set of Liq 2.0 parameters will hugely differ among vault types. Most likely, higher collateralized vaults will have a bit flatter curve or a higher starting price. Parameter that will most likely differ by a larger degree between different vault types is ilk.hole which is the aggregate amount of pending debt liquidated per vault type plus the liquidation penalties.
Next section explains parameters that need to be set by Maker governance. We then try to explain the thought process behind choosing value for each parameter based on some of our own simulations and those made by Gauntlet. Note that two different methodologies were used for simulating different combinations of parameters: Gauntlet used GBM model whereas we focused more on stress testing different price curves on Black Thursday (BT) and on 22nd February 2021 price drops.
Set of Parameters
| Contract | Parameter | Description |
|---|---|---|
abacus.LinearDecrease |
tau |
Linear Curve Auction Duration |
abacus.StairstepExponentialDecrease |
cut |
Price Change Multiplier |
abacus.StairstepExponentialDecrease |
step |
Price Change Interval |
clipper |
buf |
Starting Price Multiplier |
clipper |
chip |
Proportional Kick Incentive |
clipper |
cusp |
Max Auction Drawdown |
clipper |
tail |
Max Auction Duration |
clipper |
tip |
Flat Kick Incentive |
dog |
hole |
Aggregate Pending Auctions |
dog |
ilk.hole |
Vault Type Pending Auctions |
dog |
ilk.chop |
Penalty fee |
Price Curve
Price curve shape is defined by two modules abacus.LinearDecrease and abacus.StairstepExponentialDecrease. There is currently a possibility for either linear or exponential price decrease function, although other implementations are also possible going forward.
We believe exponential price decrease function is preferred for various reasons. First, since the starting price is aimed to be above last OSM price, we may want that auction price decrease is more aggressive at the beginning of auction duration. On the other hand we also don’t want price to be falling too aggressively later in auction duration, since the auction price may be already much lower and could present risk for undercollateralization of vaults. At that point it is better to wait for markets to calm and not track market price lower with the same intensity as initially.
Exponential price curve is defined by cut and step. The combination of these values defines the slope of the curve but also time needed before the next price drop occurs and the magnitude of the price drop.
Steps length
There are pros and cons of choosing to either implement longer steps or having them very short which creates a continuous curve seen above. Long steps could have negative effects on protocol and vault users since large discrete drops increase price discount available once the correct or market price is reached. On the other hand continuous price curve can have negative effects on UX if users are potentially bidding in these auctions through UIs such as 1inch.
We therefore believe steps of about 90 seconds are preferred: it wouldn’t hugely affect the price leaking from protocol or vault users but still enable bidding through UIs. It is questionable though if retail users are going to be able to bid in these auctions at all since bots might be handling it.
Curvature
The slope of the exponential curves defines the time needed for auction to settle or when auction price reaches the market price. Based on a) the proposed step of 90 seconds and b) target duration of auction of around 40 minutes and c) hypothetical starting price of 1.30 above OSM defined as buf which we’ll address later, we need to choose the cut parameter to determine the curvature. Note that higher the cut, lower the drops in 90 seconds (per step) since the percentage price drop from the top is measured as 1-cut.
Slower falling auction price will take longer to clear and faster falling auction price will clear auctions sooner. There is again an upside and downside to choosing more or less aggressive price drop.
Price falling too fast
Fast falling auction price could lead to similar consequences as on BT where ttl of 10 minutes was too low. For this reason and in our opinion, auctions should on average last between 30 and 40 minutes (potentially faster for lower LR vaults such as ETH-B which we would want to settle sooner before market price collapses additionally which could lead to undercollateralization event for Maker). This however doesn’t mean some auctions couldn’t settle earlier or later. Another negative impact of a fast falling price could have is high auction throughput that is limited by ilk.hole and hole.
Price falling too slow
Price falling too slow could have negative consequences on market price slippage. In other words, realized auction price could be much lower because market price is falling faster than the price curve we set. This is why lower collateralized vaults would preferably have price auction with steeper slope or lower buf.
Report from Gauntlet shows nicely how a flatter curve (longer Auction half life at fixed step) leads to lower amount of bids in auctions.
Their proposed combination of parameters that defines the auction price curve is step of 30 seconds and cut of 0.997 which represents about a 5.6% drop every 10 minutes. Since our proposed step is 90 seconds and a similar slope is preferred from our side, a cut of 0.99 is suggested.
Starting price
Starting auction price is defined by a) last OSM price when auction is kicked and b) buf parameter. OSM lags on average one hour, but could lag more if we had no update due to OSM reporting price sensitivity. This is why the buf parameter is used which represents a buffer applied to the last OSM price in case the market price rebounds between the time OSM took the last market price and until the auction is kicked.
Higher buf makes it more probable that the auction starting price doesn’t start below the market price. On the other hand higher buf makes auction duration longer which could lead to lower settlement prices. Based on the most volatile day in recent history, Black Thursday, market price rebounds during the day were up to 10% for ETH and 40% for LINK (measured as largest 1h and 2h rolling price increases on 12&13th of March 2021).
This is one of the reasons buf of at least 120% is preferred, especially for volatile crypto assets. Note again that whatever buf is considered this has an effect on cut and step since we still primarily aim to target specific auction duration.
Gauntlet’s Report suggests 110% buf and uses a similar slope of the curve than the one suggested by us. Expected auction duration in their case is therefore 16 minutes whereas ours aimed is closer to 40 minutes for reasons mentioned above (network congestion). Since our proposed expected auction duration is longer, higher buf is preferred, which also assures that settlement price is closer to market price in case of price rebounds between last OSM price and auction start.
Gauntlet’s chart below shows that higher buf values does have an effect on the number of auctions settled and 120% would be maximum suggest buf from their side based on the slope they chose.
Since their report is made on ETH and this proposal is made for LINK, we believe that higher LR vaults and more volatile assets could have higher starting price and longer settlement time and therefore suggest to use a
buf of 1.30 for LINK-A. This makes auction duration longer (on average auctions would settle in 40 minutes - time until OSM + buf reaches OSM price according to price curve) which is one of our recommendations that holds especially for volatile assets where we might want to settle them later than vaults with low LR such as ETH-B which represent a larger risk to Maker. Longer auction duration also enables us to increase the amount of pending auctions per vault type by setting ilk.hole higher.
Another reason why a higher starting price is preferred is because of auction starting price dependency on OSM and potential issues that are being mitigated through implementation of permissionless circuit breaker.
Price Curve Proposed Parameters
buf = 1.30
cut = 0.99
step = 90 seconds
Plotted price function:
Features of proposed price curve:
- Starting price is 30% above last OSM price
- 1% drop from starting auction price every 90 seconds
- Auction is settled on average in about 40 minutes if market price doesn’t change from last OSM price when auction was kicked
- Auction price would achieve 50% of last OSM price in 2h23min after being kicked
Simulations
We simulated the above price curve on the actual LINKUSD price drop using 1 minute OHLC data from Coinbase on Black Thursday and on 22nd February 2021. We are mostly interested in 3 metrics when simulating random 10 minute interval liquidations during the day of price crash:
- How much time does it take for auctions to settle
- What is the market price slippage from the time auction was kicked (measures price curve efficiency)
- What is the market price slippage from the last OSM (measures price curve efficiency and its impact on actual losses or vault collateralization at auction settlement time)
Also note that we made two types of simulations on each of the historical crash events: one that uses our proposed buf of 1.30 (blue bars) and one with buf of 1.10 (red bars). The idea was to test for two types of price curve, one that is more aggressive and makes auction settle sooner (buf of 1.10) and one that takes longer (buf of 1.30) and see how that affects settlement times and market price slippage.
Simulations on Black Thursday using buf of 1.30 :
- On average auctions would settle in 42 minutes
- 10% percentile (fastest) settlement time is 22 minutes
- 90% percentile (slowest) settlement time is 60 minutes
- Average market price slippage from the time auction was kicked measures +0.34%
- 10% percentile market price slippage from the time auction was kicked measures -7.94%
- Average market price slippage from the last OSM is -0.73%
- 10% percentile market price slippage from last OSM is -13.03%
Simulations on 22nd February 2021 buf of 1.30:
- On average auctions would settle in 41 minutes
- 10% percentile settlement time is 31 minutes
- 90% percentile settlement time is 49 minutes
- Average market price slippage from the time auction was kicked measures +0.19%
- 10% percentile market price slippage from the time auction was kicked measures -3.33%
- Average market price slippage from the last OSM is -0.61%
- 10% percentile market price slippage from last OSM is -5.75%
How to interpret these results:
First, note that calculations above do not consider slippage from the keeper’s perspective but only the effect of auction duration time on realized market price. So for instance in 10% worst events during BT, an auction would start above the market price and would need 60 minutes to settle because the market price is falling faster relative to the price curve. Because of the long duration, the price curve would “catch” the market price 7.94% lower than what the market price was when the auction started. Because of the OSM delay, the realized market price would be 13.03% below the market price when the vault collateralization ratio dropped below liquidation ratio. This means a 175% vault would end up being liquidated at 152% CR in 10% worst case events before the potential slippage from keepers is applied.
Additional slippage from keepers might be derived a) due to keepers profit taking and b) actual slippage when keepers sell collateral for DAI on the market.
High versus low buf
As seen on charts above, higher buf does settle auctions on average about 25 minutes later (February 22nd 2021). Market price slippage is therefore 1.25% worse in 10% worst events compared to buf of 1.10. However the settlement time when using buf of 1.10 is in some instances too fast. In 10% of worst events on BT settlement time is in the first minute of auction duration, which means that due to volatility auction price could in some cases start below market price and would settle instantly. Similarly on 22nd February, settlement time in 10% worst events is only 7 minutes. This is one of the main reasons we recommend using a higher buf of 1.30, since we don’t want auctions to have too fast settlement time (due to network congestion issues, but also implications this has on too high auctions throughput that could not be controlled).
Resetting an Auction
Auction can be reset after the price curve defined by parameters above reaches one of the limits defined by cusp and tail parameters. The idea behind this is to have “another run” of auctions in case something unexpected happens during the auction (i.e. network congestion, keepers infrastructure issues, etc.) and we wouldn’t want to risk settling auctions at very low values below market price.
There are two parameters that assure auction can be reset by keepers, but only one will in practice lead to a reset. This is because the auction can be reset if either the price decrease is larger than x% (defined by cusp) or when the auction duration is longer than y seconds (defined by tail). Unless both are set equally related to the price curve, one that is triggered first will decide whether the auction can be reset.
Ideally we want to reset an auction when a specified percentage price drop occurs. If cusp is chosen as 0.4 and buf is 1.30, auction is reset when price reaches 0.52 of OSM price (drop tolerance of 48%). This would be also the value that we suggest implementing for LINK-A.
If we use all the parameters defined so far that determine the slope and apply ‘cusp` value of 0.4 to it, we also get an estimation of when the auction will be able to reset, which is in 2h18min.
As said, the tail parameter does in this case not matter if it’s higher than 2h18min. For that reason we set it to 2h20min to somehow equal 0.4 cusp, but we also believe that such auction duration before being reset is reasonable.
Limiting Auction Throughput
Auction throughput is limited by parameters hole and ilk.hole. hole limits the value of aggregate pending debt liquidated and is similar to box parameter in Liq 1.2 implementation, whereas ilk.hole limits this same value of pending debt liquidated per vault type. The idea behind limiting the amount of pending debt liquidated is to set auctions throughput to levels that does not lead to large market slippage when keepers are recycling bought collateral back to DAI.
Collateral Auction Throughput
Since most auction participants might use flash loans to bid on auctions and sell the collateral back to DAI, on-chain liquidity is what interests us. By using 1inch API we plotted the on-chain slippage curve for collaterals in Maker’s portfolio. These values represent percent slippage when selling a dollar amount of particular collateral to DAI on-chain (gas costs excluded).
For instance, selling $6m of LINK for DAI leads to 5.2% slippage and selling $50m LINK leads to 31% slippage. Rule of thumb would be to limit maximum slippage between 20-30% on a daily basis. Although the number might seem high, note that the majority of LINK liquidity is still on centralized exchanges and that is why a higher on-chain slippage threshold could be used. This means we would tolerate between $30m - $50m LINK auctioned on a daily basis.
As previously shown the auction duration based on chosen price curve would on average take around 40 minutes. This means that about $1.4m LINK ($50m divided by 24h times ⅔) could be sold per one auction cycle if auctions were to take a whole day. Since we might want to liquidate more initially, a more reasonable auction throughput for LINK would be $6m, which also represents a smaller 5.2% on-chain slippage as mentioned earlier.
Live data: https://maker.blockanalitica.com/slippage/
Aggregate Auction Throughput
We believe the hole parameter should be related to the DAI liquidity metric. Namely, aggregate value of individual ilk.hole values could lead to DAI liquidity crunch events that we want to avoid.
The most liquid DAI pair that carries least slippage is DAIUSDC, obviously because of PSM. Yet we may not want to use this metric when choosing threshold here as the limit would simply be too high. We have therefore chosen to measure slippage when buying DAI via 1inch by excluding the routing of the trade via PSM. Tolerated slippage in our opinion needs to be small or around 0.2%, since as mentioned, hole can be emptied every auction cycle which can on average take 40 minutes. Slippage of 0.2% would equal around 100m DAI, which is also the value we propose for hole.
Incentivizing Auction Initialization and Reset
Auction kick incentivization is something that was discussed numerous times under Liq 1.2 implementation. Under Liq 2.0, parameters such as chip and tip ensure that auction initialization or reset is being compensated to cover keepers gas costs.
Not properly setting these two parameters could though lead to unintended consequences that were addressed in MIP45. After discussing the situation with the Smart Contracts team, it is recommended that tip parameter is set to a positive value at a later stage. chip parameter is on the other hand less controversial and we believe we could set it to some low value such as 0.1%. This means that the keeper kicking a 100.000 DAI debt vault should be compensated by receiving 100 DAI. In the meanwhile we are also in talks with one of the keepers to have them compensated from the DAO for kicking and resetting auctions.
Penalty Fee
MakerDAO’s penalty fee is on the higher end of liquidation fees in DeFi and because of the safer and more robust liquidation system, the community could perhaps think about reducing it. However a large reduction is not recommended due to auction grinding attacks. We don’t suggest changes to penalty fee at this stage and therefore ilk.chop proposed parameter is set to 13%.
Conclusion
The main challenge of properly setting Liquidations 2.0 parameters in our opinion is to determine the perfect auction price curve that minimizes the settled price slippage and has a duration that shouldn’t be too short which could potentially lead to below market price bids due to network congestion or other reasons.
This is why most of our focus in this report and going forward is to set the expected auction duration of each vault type. We believe that higher LR vaults such as LINK-A can and should have longer auction duration (we suggested 40 minutes), whereas vaults with lower LR would have auction duration shorter since the market price slippage for lower LR vaults can lead to loss events for Maker faster. We are thinking about 30 minutes expected auction duration for low collateralized vaults.
Proposed Liq 2.0 Parameters for LINK-A
LINK-A Auction Parameters:
cut = 0.99
step = 90 seconds
buf = 1.30
cusp = 0.4
tail = 140 minutes
chip = 0.1%
tip = 0
ilk.hole = 6m DAI
ilk.chop = 13%
Global Auction Parameter:
hole = 100m DAI