The Aave team partners with Sherlock across the V4 upgrade through three distinct phases: a multi-phase collaborative audit conducted alongside Blackthorn, a $365,000 audit contest, and an ongoing bug bounty program covering live code after launch. For one of the most significant architectural changes in Aave’s history, the security coverage doesn’t stop at pre-launch review. It runs through deployment and into live operations.
Why V4 Needs This Level of Coverage
Aave V4 introduces a Hub-and-Spoke architecture alongside a new risk premium system. These are not incremental changes to existing code. They represent a fundamental redesign of how the protocol routes liquidity and prices risk across its markets.
New architecture means new attack surfaces, and new attack surfaces in a protocol handling billions in user funds means the margin for missed issues is effectively zero.
Sherlock is brought in specifically to go deeper on the parts of V4 that are entirely new. A standard audit covers what exists. What Aave needs for V4 is coverage that understands what the new components are supposed to do, how they interact with legacy code, and where the novel design creates exposure that prior audit frameworks weren’t built to catch.
Three Phases, One Continuous Security Layer
The multi-phase collaborative audit with Blackthorn forms the foundation. Rather than a single-pass review, the structure allows findings from early phases to inform the scope of later ones. As V4’s components develop and integrate, the audit process adapts rather than treating the codebase as a finished artifact.
The $365,000 audit contest opens the code to a broader field of independent security researchers with financial skin in the game. Contest-based auditing consistently surfaces issues that traditional firm-based audits miss, because the incentive structure rewards finding real vulnerabilities rather than completing a checklist.
At $365,000, the prize pool is large enough to attract serious researchers who treat it as a professional engagement rather than a side effort.
The bug bounty program extends coverage past the launch date. This is the part that most audit processes skip entirely. Code that passes pre-launch review still faces real-world conditions, novel transaction patterns, and interaction scenarios that no audit fully anticipates. A live bug bounty keeps the financial incentive for responsible disclosure active after deployment, which means the security layer doesn’t expire the moment users start interacting with V4.
The Hub-and-Spoke Architecture and Why It’s the Focus
The Hub-and-Spoke model is the core of what makes V4 architecturally different from previous Aave versions. It centralizes certain protocol functions at a hub level while allowing individual markets to operate as spokes with their own parameters.
The risk premium system sits on top of that, dynamically adjusting borrowing costs based on the specific risk profile of each asset and market configuration.
Both components are new enough that there is no prior audit history to draw from. Sherlock’s focus on these areas reflects a straightforward security principle: the newest and most complex code carries the highest residual risk, and that’s where independent scrutiny needs to concentrate. Collaborative work with Blackthorn allows both firms to cross-check findings on components where a single reviewer’s blind spots could have real consequences.
What Full Lifecycle Security Actually Means
Sherlock’s model goes beyond point-in-time audits by design. The three-phase structure on Aave V4 is an example of what that looks like in practice: coverage that begins during development, intensifies at the pre-launch stage through competitive review, and then continues into live operations through ongoing bounty incentives.
For a protocol at Aave’s scale, this approach reflects a realistic view of where security failures actually happen. Pre-launch audits catch a lot. They don’t catch everything.
The combination of professional audit, crowdsourced contest, and post-launch bounty creates overlapping layers that cover different failure modes at different stages of the protocol’s life.
Conclusion
Aave V4’s security process with Sherlock is worth paying attention to as a model. Three phases, two pre-launch and one post-launch, covering the protocol’s most architecturally novel components with a combination of expert review, open competition, and live monitoring. For protocols shipping genuinely new infrastructure, it’s the kind of coverage that matches the actual risk profile of what’s being deployed.Aave V4’s partnership with Sherlock’s DeFi platform across a collaborative audit, $365K contest, and live bug bounty set a new bar for protocol security. When the architecture is entirely new, the security process needs to match.
