Summary
Aave Labs proposes launching a dedicated Aave V4 bug bounty program on the Sherlock platform. The objective is to add an always-on security reporting channel for Aave V4, with a triage setup designed to reduce spam and route high-severity reports with high urgency.
Motivation
Aave V4 introduces new architecture and new attack surfaces. In addition to audits, formal verification, and other security review tracks, an ongoing bug bounty provides a complementary path for independent researchers to report issues during late-stage testing, launch, and post-launch.
Why Sherlock
Sherlock positions its bug bounty platform around three operational goals: (i) strong visibility to experienced researchers, (ii) low spam volumes, and (iii) actionable triage with clear routing.
Sherlock has previously supported security work with Aave contributors across Aave V3 and in early Aave V4 efforts, which builds shared context on reporting standards, triage expectations, and escalation paths. Sherlock notes that its broader platform combines audit competitions with a bug bounty program, and that the bounty platform is designed to keep response workflows lightweight for core contributors while still surfacing high-severity reports quickly.
Spam resistance and operational focus
A practical challenge for prominent programs is high volumes of low-quality submissions (including AI-generated reports), which can consume significant contributor time and degrade signal-to-noise. Sherlock’s model uses stake-gated submission rules for High/Critical reports while keeping Medium/Low submissions open to everyone, paired with a defined triage workflow and periodic summaries.
Specification
This Temp Check proposes approving the creation of a dedicated Aave V4 bug bounty program hosted on Sherlock, with the commercial and operational structure summarized below.
Program scope
-
Aave V4: separate bug bounty program, scoped to the Aave V4 in-scope repositories and deployed contracts (final scope list to be published in the ARFC, alongside the payout table and severity criteria).
-
This Temp Check is limited to the Aave V4 program; any broader consolidation or migration of other programs (if applicable) would be discussed separately.
Submission model (stake-to-submit for High/Critical)
Sherlock’s proposed submission rules:
-
High/Critical submissions: require a 250 USDC stake to submit.
-
If valid, the stake is returned alongside the bounty payout.
-
If invalid, the stake is forfeited and applied toward triage costs.
-
-
Medium/Low submissions: free to submit.
- These submissions cannot be upgraded into High/Critical payout tiers after submission, incentivizing accurate severity classification at time of filing.
Triage and routing
Sherlock’s proposed workflow:
-
High/Critical: immediate notification to Aave’s designated responders via agreed channels (e.g., Slack/email/Telegram), triggered when the stake is posted; then rapid validity triage by assigned security researchers across time zones for 24/7 coverage.
-
Medium/Low: handled through a Sherlock workflow combining AI-assisted prioritization with human triage; a weekly summary is provided linking Medium/Low items and surfacing higher-quality reports (including those ultimately deemed invalid/out-of-scope but potentially useful).
-
Aave retains dashboard visibility into submissions and conclusions.
Program management and integrations
-
Self-service controls for program configuration (scope, severity criteria, payout amounts, notification routing, and related settings).
-
Standard and custom notification routing (Slack, email, Telegram, and custom workflows as needed).
Pricing options
Sherlock proposed two options for the DAO to consider:
-
$24,000 fixed annual cost for hosting + triage, or
-
No fixed hosting/triage cost, with a 5% fee on bounty payouts.
The ARFC would present a single recommended option, along with implementation and payment details.
Risk considerations
-
Stake gating tradeoff: a stake requirement can reduce noise but may deter some researchers from submitting High/Critical reports. The intended mitigation is preserving free Medium/Low submissions and maintaining high visibility to experienced researchers through platform positioning and invitations.
-
Severity downgrade constraint: prohibiting Medium/Low upgrades to High/Critical tiers can reduce “severity inflation,” but also penalizes misclassified submissions. Clear severity guidance and scope documentation would be part of the program launch materials.
-
Operational dependency: triage and platform operations depend on a third-party provider; this is addressed via explicit routing, defined SLAs/expectations in the commercial agreement, and DAO visibility into outcomes.
Disclaimer
-
This Temp Check is posted by Aave Labs in its capacity as a contributor proposing an approach for Aave V4 security operations. Decisions and approvals belong to the DAO via the standard governance process.
-
Sherlock is a third-party service provider. Final commercial terms and execution details would be presented in an ARFC and, if progressed, implemented via an AIP.
Next Steps
-
Engage with the community and service providers to refine the detailed proposal
-
If consensus is reached on this TEMP, escalate this proposal to the Snapshot stage
-
If the TEMP snapshot outcome is YAE, incorporate stakeholder feedback and move proposal to ARFC stage
Copyright
Copyright and related rights waived viaCC0.