Liquidation Event Handling And Collateral Reserves

While implementing the above patch, we uncovered an opportunity for another small improvement to the protocol.

Currently, based on the ‘internal accounting’ methodology of the protocol, collateral balances held by a deployment (but not created through the standard supply function) belong to nobody, and are inaccessible without a code change, nor included as reserves for sale. This could occur if a user sends a token to the wrong address, or if (hypothetically) a Compound III market is collateral in another deployment (for example, if cUSDCv3 were collateral in cWETHv3) and generates interest.

In addition to the liquidation event log, this patch will also include an accounting change, in which the protocol’s reserves of a collateral asset are calculated as the balance held, minus all user owned balances. In effect, if the protocol receives collateral, for any reason, that does not belong to a user address–it will become reserves. This patch will not impact any existing users, but unlocks future tools for governance, including the use of a Compound III market as collateral in another deployment.

This also requires a change to the example liquidation bot contract we provided, and which is updated accordingly in the code.

We are proposing to bundle these changes together, as they are relatively small changes that will give us parity for the markets being launched soon after. By bundling them together, we aim to minimize the governance burden. We’ve added test coverage for the new changes to the pull request, and are working on a few other testing enhancements before creating the proposal. OpenZeppelin is currently auditing these changes, and we will update this thread with any additional findings they have.

2 Likes