As mentioned on the G&R call last week, we decided to propose a new set of auction parameters for the largest vault types. These were the initially implemented auction parameters for ETH and WBTC vaults. Some adjustments were made at the end of April this year (shorter auction duration for ETH-B and a general increase of auction throughput for all ETH vault types).
Looking at recent auction performance data we are confident that we can start improving the efficiency of auctions by increasing the throughput. Higher throughput means there is less market price risk and faster auction settlement of liquidated vaults. We can achieve this by making adjustments to the set of parameters that define the auction price curve as well as increasing the parameter that defines the amount of pending liquidations
On average, ETH-A, ETH-C and WBTC-A auctions settle in 40 minutes. The ETH-B auction duration, on the other hand, is set to 20 minutes. This is mainly due to the higher market price risk of the low liquidation vault type. We still believe network congestion can be a real threat. This is why we only propose a modest decrease of 10 minutes in auction duration for ETH-A, ETH-C and WBTC-A. This means the average settlement period would decrease to approximately 30 minutes. Despite this modest decrease in auction settlement time, it still represents a 25% improvement in auction throughput.
The simplest way to shorten auction duration is to decrease the
buf parameter that defines the starting auction price as a multiplier to the last OSM price. Currently it is set to 1.3. We propose decreasing it to 1.2 for ETH-A, ETH-C and WBTC-A vault types.
This change would have following effects:
- Auctions settle on average in 29 minutes instead of 41 minutes
cuspparameter that defines auction reset price is applied to
bufand therefore auction reset price gets lowered from 52% to 48% of OSM price
- Slope of the auction price curve stays the same
- 25% higher throughput of auctioned debt settled
Source: Own Calculations
As was previously the case, it is worth noting that any delay in settlement might have negative effects on potential losses. These effects may now be more pronounced due to the recently decreased liquidation ratios for ETH-A, WBTC-A and ETH-C. A comparison of theoretical losses is set out below. This outlines the effects of delayed settlement due to network congestion issues up to a specific price (as a percentage of OSM) after which it gets reset.
In a tail event scenario, where bids are delayed until the minimum auction price, the estimated* loss for Maker increases from -21.87% to -30.28% for ETH-A and WBTC-A, and from -8.84% to -19.08% for the ETH-C vault type. Note that this is a worst case scenario where, due to some tail event, there are no bids for more than 2 hours.
*estimated rests on the assumption that vaults get liquidated exactly at the Liquidation Ratio threshold. In reality, liquidations probably occur a few percentage points lower than the threshold. In addition, the table does not account for slippage from keeper bids. This means that an additional loss of between 5-10% should also be included.
We are also proposing a modest increase of the pending liquidations parameter
ilk.hole. Currently it is set at:
- 30m for ETH-A
- 20m for ETH-C
- 15m for ETH-B
- 15m for WBTC-A
We are proposing to increase these values by an extra 10m each:
- 40m for ETH-A
- 30m for ETH-C
- 25m for ETH-B
- 25m for WBTC-A
Auction throughput will be increased by a factor of almost 2x as a result of these combined changes. Previously, for example, a 100m ETH-A liquidation would need 133 minutes to settle. Under the new set of parameters, settlement would be reduced to approximately 75 minutes.
As long as we continue to see a smooth performance, the intention is to keep improving auction parameters for all vault types. One of the most important metrics we rely on is the amount of unique takers, which increased during the Liquidation 2.0 rollout. Gas prices will also be closely monitored in order to evaluate that keeper incentives remain properly set.
If there are not larger objections by the community, we’d like to include these parameter changes in an on-chain poll next week.