Welcome back to our final installment of the MakerDAO Simulation Series, where we highlight some of the work Chaos Labs completed as part of the MakerDAO SES program. As a part of the program, we were tasked with building a simulation-based unified testing infrastructure to better implement major technical upgrades and communicate risks to MakerDAO core units and the community.
In our final demo, we created a simulation to understand how Keepers with competing gas strategies impact the Auction Price Curve for liquidations.
If you prefer video, check out this tutorial:
If you’re interested in seeing our other simulation demos, you can find the full library of MakerDAO simulation walkthroughs below:
- Auction Price Curve & Keeper Gas Strategies
- Black Thursday & Flip Auctions
- Flapper Surplus DAI Auctions
- Peg Stability Module
In our simulation environment, we create a scenario in which the DAI held is greater than the allowed upper bound threshold and automated agents “kick” auctions to test the functionality of this yet-to-used smart contract.
Collateral auction and gas strategies overview
When vaults on MakerDAO are insufficiently collateralized, they become eligible for liquidation. When this threshold is reached, MakerDAO starts an auction for the vault collateral in an attempt to raise the amount of DAI needed to cover the outstanding debt.
Maker specifically uses Dutch auctions for this vault liquidation process. In a Dutch auction, prices start high and decrease monotonically until a Keeper accepts the offered price and the auction ends. An ideal outcome for the Maker Protocol is for collateral auctions to start slightly above the market price and fall to the market price in the shortest amount of time.
For external parties, like liquidation bots, competing in liquidation auctions can be highly profitable, particularly during extreme market conditions and steep price drops.
The external parties (‘keepers’) typically use two different gas price strategies while competing for liquidations:
1. Fixed Gas Cost Taker: This keeper always sets a total gas cost worth 1% of the expected profit from the auction.
2. Adaptive Gas Cost Taker: This keeper sets an initial total gas cost at 1% of the expected profit from the auction. After every reverted transaction (lost auction) the total gas cost percentage is doubled and after every successful transaction, the total gas cost of the transaction is set back to 1% of the total expected profit.
Simulation Set Up
In this simulation, we are comparing the performance and impact of the Fixed Gas Cost and Adaptive Gas Cost Taker strategies.
To initiate an auction in our simulated scenario, we have the price of ETH drop from $1,200 to $750 in under 90 minutes, resulting in over 17M DAI liquidating across 30 ETH-A auctions. The two keepers are both looking for arbitrage opportunities between the auction and market price, while competing with each other for the highest bid to win auctions.
One of the most unique aspects of this simulation is that we are not only manipulating the environment surrounding the protocol, but also deploying a custom Spell, which is a Maker governance contract, into the cloud environment to dictate auction parameters.
To assess the strategies, we set up additional observers to monitor the performance of the two strategies, including:
- Individual auction curve
- Clipper net & gross profit (both before and after gas fees)
- Clipper gas costs
- Number of auctions won by each keeper
- Total amount of DAI auctioned off
With the simulation set up, we let the on-chain transactions flow unabated to see how agents interact with the protocol. In order to compare the strategies, we initiated the following simulation:
1. Set up fixed and adaptive takers
2. Initiative price drop trajectory
3. CDPs become eligible for auctions
5. Keepers send ‘Take’ transactions
6. Auction closes with profit to the winning taker
7. Repeat steps 3-6 as long as loans remain in default
This simulation provides a better understanding for the MakerDAO team while demonstrating the power of the Chaos Labs platform. Specifically, this scenario enables protocol developers to run a multitude of differentiated competitive agents along a probabilistic curve to determine optimal strategies in a given scenario. This means you can pressure test protocol operations to maximize relevant stakeholder profits while protecting against malicious actors with misaligned incentives.
Additionally, the simulation demonstrates how to create agents with complex priority stacks that mimic on-chain behavior. Agents participating in the MakerDAO protocol may have a priority stack that is different from Maker. For example, an agent may hold large stakes in other protocols or have equal to greater profitability and need to make zero-sum decisions that are irrational when optimizing for Makers’ gain.
Here, behavior can be irrational for the purpose of profit maximization, narrowly defined for profit via Maker, but keepers often operate on several protocols simultaneously and may make seemingly non optimal decisions to optimize other positions in times of high volatility.
About Chaos Labs
Chaos Labs is a software company building a simulation platform to allow teams to efficiently test protocols and understand how they will react to adversarial market environments. The backbone of our technology is a cloud-based, agent- and scenario-based simulation platform that allows users to orchestrate blockchain state, test new features, and optimize risk parameter selection.
Our technology allows users to:
- Orchestrate protocol/blockchain state
- Generate wallets with behavioral attributes
- Test protocol performance in chaotic market conditions
- Optimize risk parameters
Our mission is to secure and optimize protocols through verifiable agent and scenario-based simulations.
The Chaos Labs simulation platform is built to emulate a production environment. Each simulation runs on a mainnet fork with the chain's current state so that your simulations include up-to-date account balances and the latest contracts and code deployed across DeFi. You cannot look at your protocol in a silo when you're testing adversarial environments. You must ensure you understand how external factors such as cascading liquidations, oracle failures, variable gas fees, liquidity crises, and more will impact your protocol in various situations.