CS-BOLD-012 Low 5.15: Zapper Delegation Is Not Reset When a Trove Is Closed

[bingen]

When a trove is created through a zapper, the zapper will be set as the addManager, removeManager and receiver of the trove in the core system. However, a user can also create a trove without using a zapper, then set these roles to the zapper later to use its functionality.

This must be done with extreme care, as there might be delegations set in the zapper that the user is not aware of. Either the user could have had a trove with the same troveId earlier, that they had set delegation for in the zapper and then closed (closing a trove does not reset zapper delegation). Or the user could have gotten frontrun on trove creation, with an attacker creating a trove with the same troveId in the zapper, then immediately closing it but leaving the delegation in place on the zapper.

Zapper roles are always written to when a trove is created in the zapper, so the issue can only appear when a user opens a trove without using a zapper, then sets the zapper as the manager.

[bingen]

This is a known and discussed issue. As the user can close a trove (or get liquidated) through the core contracts instead of through the zapper, that would mean that core contracts should call back to zappers, which we want to avoid.