Attack Investment Amount

Introduction

This article lays out our standards and philosophy for evaluating bug reports that require an investment amount in order to exploit the vulnerability. The standards below, which are broken down into categories, determine under what conditions a bug can or cannot be downgraded.

Attacks Which Utilize Flashloans

In general, attacks which require flashloans to make the attack feasible or utilize flashloans to increase its impact are valid only if there is sufficient liquidity, either at the time of bug report submission or there is expected to be sufficient liquidity within the next 12 months.

If the conditions required for the attack are not present at the time of submission but are expected to be present within the next 12 months, then the bug report is valid for the appropriate payment amount based on its severity and impact.

FAQ

1. Q: What if the flashloan amounts were higher in the past and are expected to be higher in the future than they are at the time of submission, would this increase a bug report’s evaluated impact?
   
   A: No. Minimum payment amounts per severity exist to incentivize whitehats to submit bugs immediately instead of waiting for their impact to increase in order to receive a greater payout, because this waiting would risk the bug being exploited by a blackhat or being submitted by another whitehat first.

Attacks Which Require An Investment Of The Attacker’s Own Capital

In general, Immunefi does not consider the high investment amount required for an attack to be a valid reason to downgrade a bug report. There have been successful attacks in which the attackers utilized millions worth of USD in order to execute, such as the Venus Protocol Hack, and nation-state-backed attacks could feasibly utilize significantly more.

That said, attacks which require $100 million USD or more to execute will be considered on a case-by-case basis as an exception to this general principle.

FAQ

1. Q: What if spending such a large amount for an attack isn’t profitable?
   
   A: If the attack is not profitable then it may be downgraded to the impact of Griefing. This is explained in depth here: When Is An Impactful Attack Downgraded To Griefing?
   
   
2. Q: Isn’t it too risky to expect an attacker to risk so much of their own money?
   
   A: In general, the financial risk to the attacker is only a valid reason to downgrade a bug report payment when the risk extremely outweighs the reward. This is explained in depth here: Attacks With A Financial Risk To The Attacker
   
   
3. Q: What if the whitehat who submitted the bug couldn’t acquire that much capital themselves?
   
   A: Bug report evaluations are based on what a blackhat could acquire, not on what the specific whitehat who submitted the bug report could acquire.
   
   
4. Q: What if low token liquidity would require the attacker to spend a long time to acquire the high investment amount required for the attack?
   
   A: In general, if an attacker could acquire the amount needed for an attack over 12 months, then the attack is considered valid.
   
   That said, if it’d take longer than 12 months or there are unusual circumstances, Immunefi will consider it on a case-by-case basis.

Attacks Using An Asset Under The Project’s Control

This category refers to attacks which require an investment of an asset that the project could either prevent the blackhat from acquiring or could lock or seize in some way.

In general, if a project’s means of stopping an attack depend on manually executing an emergency action then this is considered an invalid reason to downgrade a bug report. This is because the purpose of a bug bounty program is to avoid the need to manually execute emergency actions in live code.

However, in unusual or complex situations Immunefi will evaluate the bug report on a case-by-case basis.

When evaluating if an attack could even acquire the necessary capital, or how the project could stop the attack, we base our judgements on objective historical data as much as possible. Common data we’ll look into are:

• Total CEX/DEX liquidity over the last 12 months.
• When historically has an individual attempted to acquire large amounts of capital and what was the project’s reaction?
• When historically has the project prevented an individual from acquiring large amounts of capital, and when has the project locked or seized an individual’s capital?

FAQ

Q: In totally novel situations where there is no historical basis how does Immunefi evaluate the situation?

A: Those situations are evaluated on a case-by-case basis.