Open bingen opened 1 week ago
I don’t think this is going to be a problem, but if it is we could have workarounds in the form of zappers.
One could be to first check if the trove exists, and if it does first close it. That would prevent the attack and even make the owner make some money.
If we finally merge PR #522 for making trove ids non-reusable, this becomes worse, as this workaround wouldn’t work.
But we could still do something like using TroveIds.length + 1
as the index.
So we won’t fix it at core level.
Of course there’s also the possibility of using things like Flashbots.
The function
TroveManager._openTrove
computes the trove ID from the owner address and a trove index chosen by the caller. Anyone can open a trove on behalf of another_owner
by providing the necessary collateral. Note that there cannot be two troves with the same trove ID:An attacker can grief other users by frontrunning them and opening a trove with the same ID on behalf of the same account, setting themselves as the manager and receiver of the collateral. They could then backrun the failing transaction by withdrawing the collateral from the trove. This attack is not free, as the attacker must pay the upfront fee for the trove. However, the fee can be relatively small. At an average interest rate of 5%, they would pay 0.05 * 2000 / 52 = 1.92 BOLD, plus the gas costs for the operation. The owner of the trove can remove the attacker as manager and claim their collateral if they are able to make a transaction before the attacker. This griefing is most problematic for multisigs or governance proposals that are executed after a time lock. Here, an attacker can potentially permanently DOS a contract from opening troves.