Urgent Configuration Change to ETH-A `lump`

The current ETH-A lump with max debt at liquidation could cause an integer overflow when computing the tab that would result in a revert of that liquidation. This means large vaults in this configuration would be immune to liquidation, which could be disruptive to the health of the protocol and the keeper ecosystem. For this reason, we suggest adjusting the lump for ETH-A to 100 ETH.

The resulting change will reduce lot sizes from 500 ETH to 100 ETH and result in smaller auction sizes.

See https://github.com/makerdao/dss-cat-overflow


This change will be included in today’s (07/08/20) executive vote. My understanding is that this post will be updated with further details once the Smart Contracts Domain Team gets the chance.


The linked github repo appears to be private.

1 Like

It’s public now!


Could you elaborate more on this? I have a few questions:

  • Is this something that was known could happen ahead of time, or is this a recently discovered “bug”?
  • What is a “max debt at liquidation”? Does this mean a liquidation of 340M Dai?
  • Will we need to keep adjusting the lump as the debt ceilings increase?
  • What are the consequences of this integer overflow event occurring and how realistic a possibility is this?

It was recently discovered and it doesn’t have to do with the debt ceilings but with the relationship between collateral locked and debt generated.
The overflow happens in this line: https://github.com/makerdao/dss/blob/master/src/cat.sol#L136
which makes art * rate * chop can not be higher than the max uint256.
Taking out chop (1.13 RAY) makes the debt to be auctioned (art * rate) can not be higher than: 102,470.8754… DAI.

So a vault with for example 500 ETH or less and 102,471 DAI debt couldn’t be liquidated now if the price of ETH would drop (this is the only effect of this issue).
This gets mitigated by reducing the lump as each auction will also split the total debt.

The problem raises now as with a higher ETH price it is more normal to have higher debt with less ETH collateral locked.


To clarify, the same vault with a lump of 100 ETH, would be broken in 5 auctions making each auction tab 20,494.2 DAI way below the 102,470.87… limit.


Thanks for the explanation. Just so I’m understanding, this prevents liquidations of the vaults with more than 102k Dai per lot, but it will not put the system in a broken state, correct? As soon as the executive passes the liquidations will turn on again?

Is there plans to update the contract code to address this more robustly? 102k Dai per lot is not a super high number.

I’m also curious as to why something like this isn’t picked up with formal verification. Integer overflow seems like a common class of error to run into, especially since the system is designed to operate over many orders of magnitude of growth.


Yes that’s right, as soon as the executive passes they would be liquidated, so no broken state.

We are thinking on making a more robust change but the lump is the easiest to apply right now.

The thing is the these formal verification proofs check when overflow happens is actually leading to a reversion. And that’s actually what is happening, preventing to complete bite. It is not that the overflow provokes an undesired value.


Awesome, thanks again for the detailed explanation.

I guess MKR holders should vote on this quick especially now that ETH is dropping a bit. We could take on bad debt if the value drops too rapidly.


This topic was automatically closed 7 days after the last reply. New replies are no longer allowed.