Simple summary
Present to the community a re-structuring of Aave’s bug bounty program, to optimise different aspects of it from learnings during the past 3 years.
More precisely, we propose fragmenting the current Aave bug bounty program into more granular ones, organized by Aave’s subsystems, with different eligibility rules, criticality tiers, and bounties themselves.
IMPORTANT. BGD’s engagement scope for services will end in March, so this proposal or any other modified version of it will need to be implemented in practise by other technical/security contributors of the community, like Aave Labs, Certora, or anybody else engaged to do so.
Context
Since the release of the Aave protocol, the priority has always been security, and one aspect of this is rewarding white hats for reporting bugs that affect the production system, before they can be potentially exploited.
Initially, the Aave bug bounty program was managed very ad hoc for each report. However, since our initial involvement as SP to the DAO, we tried to formalise this process, first via a still pretty ad-hoc mechanism here on the governance forum, and since September 2023, via a bug bounty program hosted on the Immunefi platform.
Since then, multiple submissions have been evaluated on the bug bounty program, and in some cases, rewarded with bounties. Even if we think the process is working relatively well, we think there is room for first, optimisation of how the program works, and second, an overall update of reward levels, more aligned with the current stakes of the Aave protocol, and the overall ecosystem of the smart contracts’ system of Aave.
Specification
A more granular bug bounty, by Aave sub-system
When we proposed the setup of an Aave <> Immunefi bug bounty program back in 2023, the goal was to standardize a process that was not so formalized before.
Even if this goal was achieved, over time, there have been multiple learnings on different parts that are not totally optimal in the bounty program:
-
One set of rules of eligibility, but multiple types of totally different systems. The Aave bug bounty program covers multiple (sometimes unrelated) smart contract systems of the ecosystem: partially Aave v2, Aave v3, GHO, the legacy Aave Safety Module, Umbrella, the Aave Governance.
However, the rules of eligibility, classification by criticality of bounties, and even bounty amount per criticality tier, are common to the whole bug bounty program. This is far from optimal, as we believe different systems should have different metrics of evaluation: e.g, Aave v3 production should have substantially higher critical bounty levels than other systems, e.g., Umbrella. -
Lack of flexibility for multi-team reviewers. At the moment, there are two separate teams reviewing submissions: ourselves (BGD Labs) for the majority of the systems covered, and Aave Labs for GHO-related ones.
Even if this has not really created any issue, and more due to the negative implications of the previous bullet point, it can create, for example, a lack of consistency in resolutions between multiple reviewers due to naturally different criteria. That would be fine if the program was more granular per system, but potentially problematic if not.
Additionally, configuring access control to the bug bounty platform becomes simpler whenever a single team is reviewing a program. And it is still possible to have total communication/coordination between reviewers.Finally, the community is in the process of approving running a bug bounty program for v4 separately from the current Immunefi one, in the Sherlock platform, which is aligned conceptually with the model we propose.
So, we think it is reasonable to change the current bounty program in the following manner:
- Split into separate bounty programs by Aave sub-systems. This will reflect in having different programs on Immunefi or a different platform. To keep operations lean, our suggestion would be to have these separate programs:
- Core Aave v3
- GHO.
- Non-liquidity protocol infrastructure.
- Aave v4 (already proposed by Aave Labs).
-
Redefine the bounty terms (eligibility, tiers, monetary amounts themselves) for each sub-system. Each program will have its own program description, but with the advantage of each one being way simpler than the current global program.
In a case of a critical vulnerability in one of the sub-systems clearly affecting other sub-systems, the reasonable criteria would be to escalate to the most critical sub-system. E.g., a full governance malicious takeover report due to a vulnerability would affect Aave v3 directly, so it is just reasonable to apply the Aave v3 bounty payouts. For other non-critical vulnerabilities, bounty rules should be for each sub-program.In terms of bounties per sub-program, we think the following is reasonable in the non-v4 components (all amounts in discretionary mix of stablecoins and AAVE):
Core Aave v3
| Severity | Min Bounty | Max Bounty |
|---|---|---|
| Critical | $100k | $5m |
| High | $10k | $50k |
| Medium | $5k | $10k |
| Low | $1k | $5k |
GHO
| Severity | Min Bounty | Max Bounty |
|---|---|---|
| Critical | $50k | $1m |
| High | — | $25k |
| Lower | — | $5k |
Non-liquidity protocol infrastructure (governance, Umbrella)
| Severity | Min Bounty | Max Bounty |
|---|---|---|
| Critical | $50k | $1m |
| High | — | $25k |
| Lower | — | $5k |
Aave v4
Already proposed by Aave Labs HERE.
- Still keep a common payment scheduling/proposal for all subsystems. Given that the payment stage is pretty independent from the program itself, and to reduce governance overhead, we are still batching payments of all sub-systems’ programs altogether.
However, to optimise the process, the payments can be done via the periodic treasury proposals performed by treasury service providers.
- Define the reviewer of each subsystem strictly. The reviewers of the different sub-programs should be re-defined, especially considering that we, BGD Labs, will not be a reviewer anymore.
- Not cover legacy/deprecated systems. We think it is a good idea to simplify bug bounty coverage by not including it in deprecated systems, like Aave v2, or the currently almost not-to-be-used on-chain rewards system of v3.
Next steps
- Listen for feedback from the community regarding the high-level changes.
- After feedback, and if approved on ARFC stage, the technical/security provider engaged could start the progressive implementation on the existing and/or new bounty programs.