Flap
- surplus auction (selling stablecoins for MKR) [contract]wards [usr: address]
- rely
/deny
/auth
Auth Mechanisms [uint]Bid
- State of a specific Auction[Bid]bid
- quantity being offered for the lot
(MKR) [uint]lot
- lot amount (DAI) [uint]guy
- high bidder [address]tic
- Bid expiry [uint48]end
- when the auction will finish [uint48]bids (id: uint)
- storage of all Bid
s by id
[mapping]vat
- storage of the Vat's address [address]ttl
- bid lifetime / max bid duration (default: 3 hours) [uint48]lot
- lot amount (DAI) [uint]beg
- minimum bid increase (default: 5%) [uint]tau
- maximum auction duration (default: 2 days) [uint48]kick
- start an auction / put up a new DAI lot
for auction [function]tend
- make a bid, thus increasing the bid size / submit an MKR bid (increasing bid
) [function]deal
- claim a winning bid / settling a completed auction [function]gem
- MKR Token [address]kicks
- total auction count [uint]live
- cage flag [uint]file
- used by governance to set beg
, ttl
, and tau
[function]yank
- is used during Global Settlement to move tend
phase auctions to the End
by retrieving the collateral and repaying DAI to the highest bidder. [function]tick()
- resets the end
value if there has been 0 bids and the original end
has passed.file
:beg
ttl
tau
Vow.bump
which sets the Bid.lot
for each Flap auction and the Vow.hump
which determines the surplus buffer.auth
- check whether an address can call this method [modifier function]rely
- allow an address to call auth'ed methods [function]deny
- disallow an address from calling auth'ed methods [function]Vow
when the Vow
has no system debt and has accumulated enough DAI to exceed the Surplus auction size (bump
) plus the buffer (hump
)lot
) of DAI is put up for sale. Bidders then complete for a fixed lot
amount of DAI with increasing bid
amounts of MKR. In other words, this means that bidders will keep placing MKR bid amounts in increments greater than the minimum bid increase amount that has been set (this is the beg
in action).ttl
) without another bid getting placed OR when auction duration (tau
) has been reached. At auction end, the MKR received for the surplus DAI is then sent to be burnt thereby contracting the overall MKR supply.flip
, flop
, and flap
).flap
auction run the risk of overpaying MKR for the DAI as there is no upper limit to the bid
size other than their MKR balance.tend
, bid
amounts will increase by a beg
percentage with each new tend
. The bidder must know the auction's id
, specify the right amount of lot
for the auction, bid at least beg
% more than the last bid and must have a sufficient MKR balance.beg
%] would get committed after the dishonest keeper's bid for the same, thereby preventing the honest keeper's bid from being accepted and forcing them to rebid with a higher price ((Past-bid + beg) + beg)). The dishonest keeper would need to pay higher gas fees to try to get a miner to put their transaction in first or collude with a miner to ensure their transaction is first. This could become especially important as the bid reaches the current market rate for MKR<>DAI.beg
could be set to 3%, meaning if the current bidder has placed a bid of 1 MKR, then the next bid must be at least 1.03 MKR. Overall, the purpose of the bid increment system is to incentivize early bidding and make the auction process move quickly.kick
's a new Flap Auction.bid
above the initial 0 value set during the kick
. Bidder 1's MKR balance is decreased and the Flap's balance is increased by the bid size. bid.guy
is reset from the Vow address to Bidder 1's and bid.tic
is reset to now + ttl
.beg
. Bidder 2's MKR balance is decreased and Bidder 1's balance is increased by Bidder 1's bid
. The difference between Bidder 2's and Bidder 1's bid
is sent from Bidder 2 to the Flap.bid
by at least beg
. Bidder 1's MKR balance is decreased and Bidder 2's MKR balance is increased by Bidder 2's bid
. The amount Bidder 1 increased the bid is then sent from Bidder 1 to the Flap.bid
s, so they stop making bids. Once the Bid.tic
expires, Bidder 1 calls deal
and the surplus DAI tokens are sent to the winning bidder's address (Bidder 1) in the Vat
and the system then burns the MKR received from the winning bidder. gem.burn(address(this), bids[id].bid)
.bump
+ hump
is always auctioned off in bump
increments. However, auctions run concurrently, so this would "flood the keeper market" and possibly result in too few bids being placed on any auction. This could happen through keepers not bidding on multiple auctions at once, which would result in network congestion because all keepers are trying to bid on all of the auctions. This could also lead to possible keeper collusion (if the capital pool is large enough, they may be more willing to work together to split it evenly at the system's expense).