Blog.

Maker Simulation Series: Flapper Surplus Dai Auctions (Pt. 2)

Cover Image for Maker Simulation Series: Flapper Surplus Dai Auctions (Pt. 2)
Omer Goldberg
Omer Goldberg

Welcome back to the MakerDAO Simulation Series, where we highlight how the Chaos Labs platform can be used to enhance the testing of key protocol infrastructure in stateful, orchestrated environments. Though this series specifically focuses on some of our work during the MakerDAO SES program, the Chaos Labs platform can help you iterate on enhancements and optimize for a variety of potential parameters.

If you haven’t read part one, you can check it out before continuing.

If you prefer video, check out this tutorial:

In the second installment of the MakerDAO Simulation Series, we are going to look at Flapper Surplus DAI Auctions. MakerDAO primarily earns DAI through accumulated stability fees, which is subsequently held at the protocol. When this balance grows too large, the protocol will hold Surplus Auctions to sell DAI for MKR and subsequently burn the received MKR.

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.

Simulation Overview

Flapper Surplus Auctions

MakerDAO will occasionally accumulate surplus DAI in the form of stability fees over time. When this happens, the protocol uses Surplus Auctions to sell off the surplus DAI for MKR. In Surplus Auctions, automated bidders compete with increasing bids of MKR to “win” the auction. Once the auction has ended, the DAI is sent to the winning bidder, and the system burns the MKR received.

Surplus auctions are triggered when the system has a surplus of DAI above the relevant threshold. In order to determine whether the system has a net surplus that satisfies this threshold, both the income and debt in the system must be reconciled. In short, any user can do this by sending the heal transaction to the system contract named the Vow.

The threshold surplus is determined in the Vow when the Vow has no system debt and has accumulated enough DAI to exceed the Surplus auction size (bump) plus the buffer (hump). Provided there is a net surplus in the system, the surplus auction will begin when any user sends the flap transaction to the Vow contract.

Maker Architecture

You can learn more on how Flapper Auctions work in part one of this series.

Simulation Set Up

Simulation Config

The Chaos Flapper Simulation was designed to bring the blockchain and Maker protocol to a state that permits and initiates Surplus Auction(s).

Instead of manipulating price, we inject DAI into Maker reserves exceeding the hump and bump thresholds. We then resolve the outstanding debt to trigger the surplus auction.

Edit Simulation

Because of the uniqueness of this setup, we actually ran it in two separate structures:

  • A single Flapper auction (what is currently approved)
  • Multiple concurrent Flapper auctions.

Maker has a hard limit on the amount of DAI being auctioned concurrently (currently it is exactly bump - so only one concurrent auction is possible), so we had to add a new scenario where we alter the bump to a desired smaller value - allowing concurrent simulations.

This variation consistently creates new small auctions as our agent now successfully kicks the auction each time.

The simulation is monitoring for two things related to the active auctions:

  • The amount of surplus DAI auctioned
  • A count of the number of “kick” actions

Surplus Dai Auctioned

A single Flapper auction being triggered to sell excess DAI.

Multiple Observers

Multiple Flapper auctions are being triggered to sell excess DAI beyond the bump threshold.

Simulation Flow

With the simulation set up, we let the on-chain transactions flow unabated to see how agents interact with the protocol.

You can watch the entire product demo here with a walk-through of how it interacts with the Chaos Labs platform, how agents are set up, and the various types of observables to analyze both simulations.

For the initial, single auction simulation, we kicked the Flapper Auction using the following flow:

  • Increase DAI in Maker reserves past hump and bump thresholds
  • Resolve outstanding debt positions
  • Keeper agent triggers surplus auction (via kick)
  • DAI auctioned off in a single transaction

Since the second simulation required multiple-auctions, we followed a slightly different flow:

  • Adjust hump threshold & lower bump value
  • Increase DAI in Maker reserves
  • Resolve outstanding debt positions
  • Keeper agent triggers surplus auction (via kick)
  • DAI is auctioned off in multiple auctions.

Simulation Takeaways

In this demo, we demonstrate the underlying power of the Chaos Labs platform that can provide a positive impact on any protocol. Developers looking for a more sophisticated testing environments can use the demonstrated Chaos Labs features, including:

  • Future chain states: Create mainnet forks with any desired state, including novel states that your mainnet hasn’t experienced yet.
  • Composability: Chaos Labs lets you build on top of existing simulations or use building blocks (agent/scenarios) to create a new simulation with minimum effort. Any code deployed on the platform is directly transferable to the mainnet so that you don’t need to make changes between testing and deployment.
  • Integrations: Connect your simulations to RPC interfaces, including wallets, code or any utility that is used to talk to the Ethereum Mainnet. In this demo, Sidestream interfaced with our simulation forks exactly how they interface with production.
  • Observability: Track your simulations with easy-to-build, digestible visualizations. For MakerDAO we created observers and events that track the system auction and can be reused for multiple simulations and purposes.

For MakerDAO’s Sidestream Auction Services, the Chaos Labs platform lets their team test the high throughput auction system with scale-intensive simulation states.

Additionally, this demo created a verification for Sidestream that ensured their platform supports future Maker states before they happen (ex. Collateral onboarding, creating positions). Instead of a test in production, the team could simulate production with a near-mainnet fork of their environment.

In addition to these specific benefits for Sidestream, Chaos Labs additionally provided automated and reproducible test on-demand that:

  • Guarantee that ESM triggering shuts down Flapper auctions correctly
  • Ensure that altering Flapper configuration parameters yields the desired result.

For the broader MakerDAO protocol, this simulation protects the ecosystem by creating different Flapper auction sizes. After the demo, MakerDAo concluded that multiple live auctions can break if not coerced as today’s configuration allows for a single auction, but this may change.

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.