Investigate debt auctions logic

[valiafetisov]

Goal

Get understanding how different are flop auctions from the flap

Context

For the planning and implementation of the debt auctions support, we want to investigate how they work and how difficult it will be to support them given our codebase and existing support of the surplus auctions. Same issue should investigate testing scenarios.

Assets

• The contract https://github.com/makerdao/dss/blob/master/src/flop.sol
• Current UI portal https://auctions.makerdao.com/flop
  • Its source code https://github.com/makerdao/auctions-ui
• Python-based keeper that supports flop auctions https://github.com/makerdao/auction-keeper
• example investigation (as reference): Investigate surplus auctions logic #188 (comment)
• example implementation proposal (as reference): Investigate surplus auctions logic #188 (comment)

Tasks

• Outline investigation results

[KirillDogadin-std]

FLOP debt auctions

• same bid parameters

// --- Data ---

struct Bid {

uint256 bid; // gems paid [wad]

uint256 lot; // dai in return for bid [rad]

address guy; // high bidder

uint48 tic; // bid expiry time [unix epoch time]

uint48 end; // auction expiry time [unix epoch time]

}

• same structure for tracking the number of auctions: kicks counter is incremented when the auction is started; Kick event is emitted; auctions are stored in global state up until collection moment - then the auction is removed from the state.
• Difference:
  • Kick event of the flop/debt contains the additional paremeter address indexed gal. This is the parameter that defines who will be the receiver of the lot: "highest bidder" when the auction is started.

FLOP auction flow:

1. Auction is started via calling kick with the following params:
   1. address of the initial high bidder,
   2. how much MKR will winner receive (lot)
   3. how much is the initial bid bid
2. To bid on the auction one has to call dent and the following conditions have to be met:
   1. Flopper contract is online
   2. the high bidder has to be defined (read: auction exists)
   3. the auction has to be not finished (tic auction parameter has to be greater than current time now)
   4. auction has to be not expired: end parameter hat to be greater than now current time.
   5. bid (amount of DAI bid on the auction) has to be of exact value as the one auction has.
   6. The amount of MKR acquired has to be less than the one auctioned
   7. the amount of MKR acquired has to be at least beg times less than the currently auctioned amount
3. the finishing time of the auction is increased.
4. the new bid is placed: the VAT balance of the bidder is decreased, the balance of the previous bidder is refunded.
5. when the time expires, one can call deal to receive the DAI in exchange for the MKR:
   1. auction has to be either expired or finished
   2. the MKR is minted to the winner's address: now they have it in VAT
6. when the transfer to the VAT of the winner is made, the auction's data is deleted.
7. If the auction is expired and there's no winner, one can restart it;
   1. it has to be expired
   2. it has to have no bids (no finishing point)
   3. The amount of mkr recveived (starting value) will be increased by pad times. As of now by 50%

The user of the auction is thus has to:

• provide VAT with dai allowance
• authorize DAI for wallet transactions

[LukSteib]

Kick event of the flop/debt contains the additional paremeter address indexed gal

What is the difference to the guy in this case?

bid (amount of DAI bet on the auction) has to be of exact value as the one auction has.
The amount of MKR acquired has to be less than the one auctioned

Do you share the following understanding for this auction type:

• bid always stays the same for an active auction (read: If the auction is started with a bid of 50000 DAI it always stays like that)
  • the intial bid amount is specified via vow.sump
• bidders specify a reduced lot they are willing to receive for paying the fixed bid
  • this new lot has to be at least the prev lot lowered by beg
• This time Dai (higher than or equal to bid) needs to be deposited to the VAT before being able to call the dent function
• The winner receives MKR in the VAT and has to withdraw it from there

[KirillDogadin-std]

What is the difference to the guy in this case?

Initially the auction is initialized to point to the VAT as the highest bidder.

This leads:

• the very first actual bidder puts the bid into the vat

Do you share the following understanding for this auction type:

Yes. except for

The winner receives MKR in the VAT and has to withdraw it from there

because it seems to me like the mkr just arrives into the wallet.

[valiafetisov]

To bet on the auction
the bet into the vat

As pointed out previously, let's never use verb bet in our discussions and in the codebase as they are not interchangeable with the verb bid. Refer to the dictionary :

https://dictionary.cambridge.org/dictionary/english/bet
https://dictionary.cambridge.org/dictionary/english/bid

#361 (comment)

Can you please outline not what is the same, but only what is different compared to the flap auction type?
It would also help to link the exact places in the contracts which are different.

[KirillDogadin-std]

let's never use verb bet

adjusted the comments

Differences:

1. Namings of bidding methods (now it's dent and not tend)
2. Different initialisation, here the kick event has additional parameter of an address of "highest bidder". Effectively that has no impact on our tool because this is related to the bidding logic which manages the dai.
3. different approach of how the bid is handled: here it is VAT-DAI and not MKR that we pay with, it has to be present in VAT
4. as outlined by @LukSteib above, one has to pay the fixed amount of DAI in exchange for varying amount of MKR. Each bidder specifies the acceptable amount of MKR they're willing to receive for the known amount of DAI. Each consequent bidder thus has to submit a bid with lower number than the previous bidder.
5. Consequently (see 3), the permission set is different. The functionality for granting permissions is already present in our tool though: one needs VAT allowance and due to that DAI transaction authorization as well if i understand correctly.
6. If the auction resets, the starting amount of mkr received is increasing by pad times, which is a contract global variable.
7. The amount of the MKR received is known at the start of the auction because the initial bid is configured during kick (auction start)
8. Starting price of the auction is emitted in the Kick event and also is known in advance due to the value being stored in the vow contract.
9. The highest bidder parameter is configured and is not auto-determined (unlike in the flap/surplus auctions). It is contained in the Kick event and is stored as part of the auction parameters.

[valiafetisov]

Thanks!

one has to pay the fixed amount of DAI in exchange for varying amount of MKR

Is this fixed amount hardcoded in the contract (ie known in advance) and/or emitted during the kick?

Each consequent bidder thus has to submit a bid with lower number than the previous bidder.

Is there a minimum distance between bids like flap bids should have or is the difference can be as little as one digit? If not, is the formula differs from the formula determining next bid in flap auctions? Is it computed based on a different value taken from the contract or the same one?

[KirillDogadin-std]

Is this fixed amount hardcoded in the contract (ie known in advance) and/or emitted during the kick?

it is emitted via kick

Is there a minimum distance between bids

yes

formula

newBid * 1.05 <= previousBid

Because as mentioned above, we always pay the same amount of DAI, what is changed is how much MKR we receive. And thus we submit the bid in form of "mkr received"

[valiafetisov]

Looking at the code, 1.05 is not a hardcoded, but a public variable that can be set via file method. On the currently live contract it is set to 1.03.

Also, after the flyover, reset functionality seems different to me, since it changes the amount of auctioned DAI by pad. Right?

[KirillDogadin-std]

Looking at the code, 1.05 is not a hardcoded, but

Oops, sorry, I for some reason interpreted the q to be related to the amount of DAI paid

Reset

Correct, the alteration logic of the auction differs as well, although from the interface perspective the call is analogous. I'll add the point into the summary

[valiafetisov]

Is this fixed amount hardcoded in the contract (ie known in advance) and/or emitted during the kick?

it is emitted via kick

It is emitted via the kick, but also seems to be known in advance:
https://github.com/makerdao/dss/blob/fa4f6630afb0624d04a003e920b0d71a00331d98/src/vow.sol#L66-L67

q to be related to the amount of DAI paid

Yes, that question was related to the question about the lot. But 1.05 that you brought up was not a sufficient answer about the minimum (or rather maximum) next bid.

increasing by 50%

Please be more specific in the description, since I just pointed out that those numbers are not hardcoded and need to be fetched from the contract. The summary of the differences suppose to explain that some additional information (at least beg, maybe also pad for explanation text) needs to be fetched.

kick event has additional parameter of an address of "highest bidder"

Kick event is only emitted at auction start. gal is then effectively the address of the wallet who kicked the auction.

The other difference I see is that initial kick even receives a non-zero bid. According to that line https://github.com/makerdao/dss/blob/fa4f6630afb0624d04a003e920b0d71a00331d98/src/vow.sol#L145. That means that although the auction is just started, we might already know dai/mkr price.

After this is done, I suppose that new issue should be created for implementing missing methods and making store-based interface to them.

[KirillDogadin-std]

It is emitted via the kick, but also seems to be known in advance:

yes, one can know this via the different contract. Although since it's available by event and by the auctions map it , i fail to see the use case for now.

was not a sufficient answer

adjusted the top comment to be more generic. did not adjust the difference comment because the logic of the price step is essenetially the same.

Please be more specific in the description

adjusted differences for more accurate defenition of pad

Kick event is only emitted ...

The gal address being the same as the address of the kicker is analogous/extremely to the flap, is it not? It's just that in flap it is not configurable and the contract itself gets the sender. The flop is configurable, but the contract receives the argument of the vow contract anyway. Which is like retreiving the sender address. I am not sure whether it is a "difference".

Adjusted the difference to mention knowing price at the start of the auction.

[valiafetisov]

i fail to see the use case for now

It seems like you try to do two things at once: 1) investigate the difference and 2) judge its applicability to us. I think it's hard to do it in general, but also makes it impossible to review.

the logic of the price step is essenetially the same

For me it seems like the step logic is reverse. Users have to put lower bids, not higher ones. That is a significant difference that have to be reflected not only in the explanatory text, but also in the way bidding work on the frontend, the way nextHighestBid is calculated and called. It's definitely worth mentioning in the difference section as the key distinction.

The gal address being the same as the address of the kicker is analogous/extremely to the flap, is it not?

Yes, it's similar to the flap, with the difference that the address is a) passed as an argument b) emitted together with Kick

[KirillDogadin-std]

It seems like you try to do two things at once: 1) investigate the difference and 2) judge its applicability to us. I think it's hard to do it in general, but also makes it impossible to review.

added as (8) in the differences.

It's definitely worth mentioning in the difference section as the key distinction.

It already is as (4)

passed as an argument b) emitted together with Kick

(9)