Punitive accounting for borrow and redeem

As the community lists more types of collateral tokens, the risks to the protocol also increases. There are known issues, such as listing a token which has the ability to ‘infinimint’ itself, which inherently poses a danger to the protocol. Other risks come from adding tokens which are not inherently malicious but follow standards outside of ERC-20 which the current Compound Protocol was not necessarily designed for.

The recent attack on CREAM falls into the latter category. We at Compound Labs are recommending making a change along these lines to mitigate such attacks, in a world in which the protocol is adding more diverse sets of tokens.

The proposed change builds upon a community PR to move the accounting for borrowing to update before a transferOut is called, which we call Punitive Accounting. We add punitive accounting to redeem as well, and note that the rest of the protocol already operates according to this concept.

Individual cTokens currently protect themselves from any kind of reentrancy on an individual market basis. It is possible to add reentrancy to the whole protocol (through the Comptroller), though it would be more expensive than the current checks. Some amount of internal reentrancy is needed by the protocol in order to perform liquidations, so there is some added complexity for this type of protection.

With the proposed punitive accounting changes, it may now instead be possible to remove the reentrancy checks altogether. To do that, the community should prove to itself that the protocol is now safe to reentrancy attacks altogether. That can be done as an independent later step, after more thorough evaluation.

3 Likes