ABM Protocol
Search…
ABM Protocol
Introduction
ABM DOCUMENTATION
.BTC
.BTC Mechanism
Generating .BTC
System Architecture
ABM Faucet
SMART CONTRACT MODULES
Core Module
Collateral Module
dotBTC Module
System Stabilizer Module
Vow - Detailed Documentation
Flopper - Detailed Documentation
Flapper - Detailed Documentation
Oracle Module
ABM Module
Governance Module
Rates Module
Proxy Module
ABM Protocol Emergency Shutdown
Community
Powered By GitBook
Flopper - Detailed Documentation
The ABM Protocol's Debt Auction House
​

1. Introduction (Summary)

Summary: Debt Auctions are used to recapitalize the system by auctioning off ABM for a fixed amount of dotBTC . In this process, bidders compete by offering to accept decreasing amounts of ABM for the dotBTC they will end up paying.

2. Contract Details

Flopper (Glossary)

  • flop: debt auction (covering debt by inflating ABM and selling for stablecoins)
  • lot: quantity up for auction / gems for sale (ABM )
  • guy: high bidder (address)
  • gal: recipient of auction income / receives dotBTC income (this is the Vow contract)
  • ttl: bid lifetime (Max bid duration / single bid lifetime)
  • beg: minimum bid decrease
  • pad: Increase for lot size during tick (default to 50%)
  • tau: maximum auction duration
  • end: when the auction will finish / max auction duration
  • kick: start an auction / Put up a new ABM bid for auction
  • dent: make a bid, decreasing the lot size (Submit a fixed dotBTC bid with decreasing lot size)
  • deal: claim a winning bid / settles a completed auction
  • vat - the Vat's address
  • gem- ABM Token (address)
  • kicks - Total auction count, used to track auction ids
  • live - Cage flag
  • wards [usr: address], rely/deny/auth - Auth mechanisms
  • Bid - State of a specific Auction {bid, lot, guy, tic, end}
  • bid - Bid amount in dotBTC / dotBTC paid
  • tic - Bid expiry
  • tick - restarts an auction

Parameters Set By Governance

  • The ABM Governance voters determine the debt limit. The Debt auction is triggered when the system has dotBTC debt above that limit.
  • ABM Governance sets the Vow.dump which determines the starting lot for an auction as well as the pad which determines how much that lot can increase during tick.
  • The contracts that are auth'ed to call kick() (should only be Vow) and file() to change beg, ttl, tau (should only be governance contracts).
Informational Note: The cage sets the Flop to not be live anymore and the yank is used during Global Settlement in order to return a bid to the bidder since the dent and deal can no longer be called.

3. Key Mechanisms & Concepts

The Flop Auction process begins with ABM Governance voters determining the system debt limit (Vow.sump). Debt Auctions are then triggered when the system has dotBTC debt that has passed that specified debt limit.
In order to determine whether the system has net debt, the surplus, accrued stability fees, and debt must be reconciled. Any user can do this by sending the heal transaction to the system contract named Vow.sol. Provided there is sufficient debt (i.e. debt after healing > Vow.sump), any user can send a Vow.flop transaction to trigger a debt auction.
The Flop is a reverse auction, where keepers bid on how little ABM they are willing to accept for the fixed dotBTC amount they have to pay at auction settlement. The bidders will basically compete with decreasing lot amounts of ABM for a fixed bid amount of dotBTC . Once kicked, the bid is set to the flop auction bid size (Vow.sump) and lot is set to a sufficiently large number (Vow.dump). The auction will end when the latest bid duration (ttl) has passed OR when the auction duration (tau) has been reached. The payback process begins when the first bid is placed. The first bid will pay back the system debt and each subsequent bid will pay back the previous (no longer winning) bidder. When the auction is over, the process ends by cleaning up the bid and minting ABM for the winning bidder.
If the auction expires without receiving any bids, anyone can restart the auction by calling tick(uint auction_id). This will do two things:
  1. 1.
    It resets bids[id].end to now + tau
  2. 2.
    It resets bids[id].lot to bids[id].lot * pad / ONE

Bidding Requirements during an auction

During an auction, lot amounts will decrease by a percentage with each new dent decreasing the lot by the beg for the same bid of dotBTC . For example, the beg could be set to 5%, meaning if the current bidder has a lot of 10 (ABM) for a bid of 100 (dotBTC ), then the next bid must pass at most a lot of 9.5 (ABM) for a bid of 100 (dotBTC ).

Placing Bids

When a bid is beaten out by another bidder, the new winner's internal dotBTC balance is used to refund the previous winning bidder. Once placed, bids cannot be canceled.

Example bidding flow:

  1. 1.
    Vow kicks a new Flop Auction.
  2. 2.
    Bidder 1 makes a bid that decreases the lot size by beg from the initial amount. Bidder 1's dotBTC balance in the Vat is decreased by bid and the Vow's dotBTC balance in the Vat is increased by bid.
  3. 3.
    Bidder 2 makes a bid that decreases Bidder 1's lot by beg. Bidder 2's dotBTC balance in the Vat is decreased by bid and Bidder 1's dotBTC balance in the Vat is increased by bid (thereby refunding Bidder 1 for their now-losing bid).
  4. 4.
    Bidder 1 makes a bid that decreases Bidder 2's lot by beg. Bidder 1's dotBTC = Vat.dotBTC[bidder1] - bid; Bidder 2's dotBTC= Vat.dotBTC[bidder2] + bid.
  5. 5.
    Bidder 2 (and all the other bidders within the auction) decide it is no longer worth it to continue to accept lower lots, so they stop bidding. Once the Bid.tic expires, Bidder 1 calls deal and new ABM tokens are minted to their address (ABM token contract.balances(Bidder1) = ABM.balances(Bidder1) + lot).
Note: During a Flop auction, the beg is actually the minimum decrease amount. In dent the new bid has to have a lot * beg that is less than or equal to the current lot size. Since the theory of the Flop auction is that a bidder’s offer is to take fewer and fewer ABM tokens (lot) for the same amount of dotBTC (bid) then the beg is the amount each bid's offer should decrease by.

4. Gotchas (Potential Source of User Error)

Keepers

In the context of running a 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 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).
  • This means, in the case of Flop, that since the dotBTC amount is fixed for the entire auction, the risk to the keeper is that they would make a "winning" bid that pays the bid amount in dotBTC but does not receive any ABM (lot == 0). Subsequent executions of this bad strategy would be limited by the amount of dotBTC (not ABM ) in their vat balance.

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

  1. 1.
    Flopper has the potential to issue an excessively huge amount of ABM and despite the mitigation efforts (the addition of the dump and pad parameters), if dump is not set correctly by governance, the huge issuance of ABMcould still occur.
  2. 2.
    See System Stabilizer Module Documentation.
Previous
Vow - Detailed Documentation
Next
Flapper - Detailed Documentation
Last modified 1yr ago
Copy link
Contents
1. Introduction (Summary)
2. Contract Details
3. Key Mechanisms & Concepts
4. Gotchas (Potential Source of User Error)
5. Failure Modes (Bounds on Operating Conditions & External Risk Factors)