ABM Protocol
Search
⌃K
Comment on page

System Stabilizer Module

Keeping the ABM Protocol Stable

1. Introduction (Summary)

The System Stabilizer Module's purpose is to correct the system when the value of the collateral backing dotBTC drops below the liquidation level (determined by governance) when the stability of the system is at risk. The system stabilizer module creates incentives for Auction Keepers (external actors) to step in and drive the system back to a safe state (system balance) by participating in both debt and surplus auctions and, in turn, earn profits by doing so.

2. Module Details

The System Stabilizer Module has 3 core components consisting of the Vow, Flop, and Flap contracts.

System Stabilizer Components Documentation

3. Key Mechanisms & Concepts

Summary of the System Stabilizer Module Components

  1. 1.
    The Vow represents the overall ABM Protocol's balance (both system surplus and system debt). The purpose of the vow is to cover deficits via debt auctions and discharge surpluses via surplus auctions.
  2. 2.
    The Flopper (Debt Auction) is used to get rid of the Vow’s debt by auctioning off ABM for a fixed amount of internal system dotBTC . When flop auctions are kicked off, bidders compete with decreasing bids of ABM . After the auction settlement, the Flopper sends received internal dotBTC to the Vow in order to cancel out its debt. Lastly, the Flopper mints the ABM for the winning bidder.
  3. 3.
    The Flapper (Surplus Auction) is used to get rid of the Vow’s surplus by auctioning off a fixed amount of internal dotBTC for ABM. When flap auctions are kicked off, bidders compete with increasing amounts of ABM. After auction settlement, the Flapper burns the winning ABM bid and sends internal dotBTC to the winning bidder.

How do the Vow, Flop and Flap contracts help the MCD system operate?

Vow

When the ABM Protocol receives system debt and system surplus through collateral auctions and CDP stability fee accumulation, it will deviate from system equilibrium. The job of the Vow is to bring it back to system equilibrium.
The Priority of the Vow
  1. 1.
    To kick-off debt and surplus auctions (Flop and Flap), which in turn, corrects the system’s imbalances.

Flop

The purpose of debt auctions is to cover the system deficit, which is resembled by Sin(the total debt in the queue). It sells an amount of minted ABM and purchases dotBTC that will be canceled 1-to-1 with Sin.
The Priorities of the Flopper:
  1. 1.
    To raise an amount of dotBTC equivalent to the amount of bad debt as fast as possible.
  2. 2.
    To minimize the amount of ABM inflation.

Flap

The purpose of the surplus auctions is to release dotBTC surplus from the Vow while users bid with ABM, which will be burned, thus reducing the overall ABM supply. It will sell a fixed amount of dotBTC to purchase and burn ABM.
The Priority of the Flapper:
  1. 1.
    To mechanically reduce the ABM supply when auctioning off dotBTC surplus.

4. Gotchas (Potential Sources of User Error)

Auction Keepers

In the context of running an Auction Keeper to perform bids within an auction, a primary failure mode would occur when a Keeper specifies an unprofitable price for ABM
  • This failure mode is due to the fact that there is nothing the system can do to stop a user from paying significantly more than the fair market value for the token in an auction (this goes for all auction types, flip, flop, and flap).
  • Keepers that are performing badly are primarily at risk during the dent phase since they could return too much collateral to the original CDP and end up overpaying (i.e. pay too much dotBTC (bid) for too few gems (lot)).
    • Note: This does not apply to the Flap contract (Flop and Flip only)
When no Auction Keepers Bid:
  • For both the Flip and Flap auctions, the tick function will restart an auction if there have been 0 bids and the original end has passed.
  • In the case of a Flop auction expiring without receiving any bids, anyone can restart the auction by calling tick. Along with restarting the auction, it also includes a necessary increase of the initial lot size by pad (default to 50%). This extra process is because the lack of bidding for the lot could be due market circumstances, where the lot value is too low and is no longer enough for recovering the bid amount.

5. Failure Modes (Bounds on Operating Conditions & External Risk Factors)

Governance Trade-offs

  • beg
    • If too high, it would discourage bidding and create a less efficient auction mechanism.
    • If too low, it would not be that significant but would encourage small bids and increase the likelihood of the Bid.end being hit before the "true" price was found.
  • ttl
    • If too high, it would cause the winning bidder to wait "too long" to collect their winnings (depending on the situation, possibly subjecting them to market volatility).
    • If too low, it would increase the likelihood of bids expiring before other bidders get a chance to respond.
  • tau
    • If too high, it would not have that significant of an impact as auctions would still operate normally based on the Bid.tic.
    • If too low, it would increase the chance that an auction will end before the "true" price was found.

Other Non-Obvious Auction Failure Modes (This is for all auction types: Flip, Flop, Flap)

Potential Issues around Network Congestion
When auctioning off collateral tokens, bids are finalized after an interval of time (ttl) has passed. Hence, in the case when extreme network congestion occurs, ttl and auctions are affected because they can take longer than three hours to confirm a transaction. Therefore, due to Ethereum network congestion, this can result in auctions settling for less than the fair market value. Due to this potential issue, bidders need to calculate network congestion risks when making bids.
Example:
When high network congestion occurs, where common APIs can be shut down due to denial of service (DoS), and where high gas prices are present, this can result in bidding becoming extremely expensive regardless of whether bids win or not. Unfortunately, this also results in only enabling those who have the experience and technical knowledge to build their own transactions are able to use and participate in auctions. Therefore, auctions thus settle for less than the fair market value.
Transaction-reordering / Front Running Attacks on Auctions
Front running attacks are possible. In order to mitigate this possibility, we reviewed and evaluated other auction options such as dutch and/or commit reveal but do not currently feel this change is worth delaying the whole system for. Due to the modular nature of the system and the fact that the auction modules can be swapped out, it will be possible for governance to upgrade the auction process in the future.
Previous
dotBTC- Detailed Documentation
Next
Vow - Detailed Documentation
Last modified 2yr ago