The previous implementation assumed that, from the start of the auction, lot amount of Gem would be received for a bid of price * lot. This isn't true; while the auction price is higher than tab, some collateral is returned to the vault. I've updated the keeper to calculate slice, such that Dai proceeds are calculated based upon the amount of collateral which would be received if a bid at the current price was accepted.
The daiAmount configuration was confusing; it seemed to be used as a max amount, but when converted to Gem terms, was labeled as a minAmount in code. As an enhancement, I created separate configuration knobs which can be used to limit participation in small gas-inefficient takes (minLotDaiValue) and a maximum to let user tune slippage/opportunity tradeoff (maxLotDaiValue).
Reduced output verbosity, reducing redundancy and showing priceWithProfit only for Oasis, the only place where it is used.
Changes
lot
amount of Gem would be received for a bid ofprice * lot
. This isn't true; while the auction price is higher thantab
, some collateral is returned to the vault. I've updated the keeper to calculateslice
, such that Dai proceeds are calculated based upon the amount of collateral which would be received if a bid at the current price was accepted.daiAmount
configuration was confusing; it seemed to be used as a max amount, but when converted to Gem terms, was labeled as a minAmount in code. As an enhancement, I created separate configuration knobs which can be used to limit participation in small gas-inefficient takes (minLotDaiValue
) and a maximum to let user tune slippage/opportunity tradeoff (maxLotDaiValue
).priceWithProfit
only for Oasis, the only place where it is used.