Chain Rollbacks

Rolling back the chain to mitigate the impact or profitability of an attack (reverting the chain to a previous state)

Immunefi strongly recommends that projects do not downgrade a bug report’s impact, severity, or payout in cases where the bug’s impact or profitability may be limited by performing a chain rollback. 

Rollbacks will be more feasible for some projects than others. For projects that can easily and quickly perform rollbacks, and have concerns about not being able to cite rollbacks as a reason to downgrade a bug report, we recommend they use flat payment amounts for each impact instead of payment ranges which scale based on the bug report’s impact.

Reasons for this standard: 

• A chain rollback is an extremely heavy-handed method to reverse a devastating hack in the wild. If a project is forced to perform a rollback to prevent the hack, this implies that the bug impact is catastrophic enough that it merits the highest critical payout for the project’s bug bounty program. The purpose of the bug bounty program is to avoid having to execute chain rollbacks in the wild to reverse hacks.
• Not all rollbacks themselves are feasible or successful. 
• If projects were able to cite rollbacks, then they would never pay out a maximum critical reward for funds at risk because rollbacks could always be cited as a reason to downgrade the bug report, meaning the maximum critical amount would be misleading. 

Example: 

If a bug report showed that hundreds of millions of dollars were at risk on a chain, and the project stated that it would be impossible for a blackhat to steal that amount of money because they could execute a chain rollback, it might be true but it is besides the point. As long as the bug report submission met the rest of the bug bounty program’s criteria, it would be eligible for the highest critical payout. 

Chain Rollbacks’ FAQ

What if a project could roll back the chain before the stolen funds could be bridged out?

Immunefi recommends the project pay as normal and not use this as a factor to downgrade the bug report. Otherwise, the stated payment amount for that impact is false, since in practice it would never need to be paid because rollbacks could always be claimed.

Smaller chains and more centralized chains have an easy time executing chain rollbacks. It may even be an intentional safety mechanism. Shouldn’t they be able to claim chain rollbacks as a reason to downgrade a bug report?

If a project intends to use chain rollbacks as a safety mechanism, then their bug bounty program should account for that by adjusting the reward amount for the severities or impacts which they intend to use chain rollbacks to prevent. Otherwise, this invalidates the objectivity of the bug bounty program, since the project can arbitrarily downgrade a bug report despite the terms laid out in their bug bounty program.

Should projects that use ‘Primacy of Impact’ be able to claim chain rollbacks as a reason to downgrade bug reports because this impact is what they use to determine bug report validity?

Primacy of Impact refers to when an in-scope impact occurs on an out-of-scope asset and how that bug report should then be considered in-scope. Primacy of Impact does not refer to how impact should be calculated. Impact is calculated separately from any feasibility limitations, such as chain rollbacks. 

If a project intends to use chain rollbacks as a means to prevent an impact then their bug bounty program should account for that by adjusting the reward amount for those severities or impacts.