[ARFC] AaveShield — Modular Security Framework for Aave V4

Governance
1

[ARFC] AaveShield — Modular Security Framework for Aave V4 Hub & Spoke Architecture

Author

Kristiyan Petrov (@zontak)

Date

April 14, 2026

Summary

AaveShield is a modular, open-source security framework that wraps Aave V4’s Position Manager layer with 8 composable security modules — protecting against 39 identified security gaps across the Hub, Spoke, and Position Manager layers.

The framework is fully implemented, deployed on Sepolia, and verified on Etherscan. All 296 unit/integration tests pass. This ARFC requests community feedback on integrating AaveShield into Aave V4’s security infrastructure, with a Phase 1 grant of $50,000–$75,000.

Motivation

The Security Gap

Aave V4 launched on Ethereum mainnet on March 30, 2026, introducing the Hub & Spoke architecture — the most significant architectural change in Aave’s history. BGD Labs ceased all contributions on April 1, 2026, with their security retainer expiring June 1, 2026.

Our independent security analysis identified 39 specific vulnerabilities across three layers:

Severity Count Examples
CRITICAL 7 Premium delta manipulation, deficit reporting without proof, oracle staleness, dust liquidation exploit, cross-hub desync, cross-chain signature replay, missing PM identity validation
HIGH 12 Halted spoke premium changes, interest rate reentrancy, unlimited reinvestment sweep, flash loan position manipulation, multicall non-atomicity
MEDIUM 16 Fee receiver deadlock, config staleness, liquidation bonus gaming, decimal mismatch, share dilution
LOW 4 Nonce collision, ETH trap, unlimited approvals

Key Risks Without Mitigation

  • Premium manipulation — Spokes report arbitrary premium deltas to the Hub. Crafted offsets can permanently brick assets via .toUint256() overflow.
  • Zero-validation deficit reports — reportDeficit() accepts bad debt claims without proof. Pure accounting entry, no funds required.
  • No oracle safety net — getReservePrice() only checks price > 0. No staleness, deviation detection, or fallback.
  • Flash loan attacks unblocked — Unlike V2/V3, V4 has no mechanism preventing flash-loan-powered position manipulation within a single transaction.
  • Cross-hub desync — Reserves using different Hubs have no atomic cross-hub health factor verification.

Specification

Architecture

User --> AaveShieldRouter (Position Manager wrapper)
           |-- Collect protocol fee (configurable BPS)
           |-- delegatecall --> Module.onBeforeOperation() [each enabled module]
           |     \-- returns guardFee (punitive fee if threat detected)
           |-- call --> Spoke.supply/borrow/withdraw/repay
           |-- delegatecall --> Module.onAfterOperation() [each enabled module]
           \-- Split fees: protocolShare --> treasury, remainder --> Aave reserves

Users opt in by approving AaveShieldRouter as their Position Manager. Modules execute via delegatecall in the router’s storage context using ERC-7201 namespaced storage for isolation. EIP-1153 transient storage provides gas-efficient pre/post-operation snapshots (100 gas vs 20,000 SSTORE).

8 Security Modules

# Module Gaps Covered Key Protections
1 HubInvariantModule 8 (2 CRITICAL) Liquidity conservation, share consistency, deficit bounds, premium integrity, cap enforcement
2 OracleValidatorModule 2 (1 CRITICAL) Price staleness, EMA deviation, intra-block manipulation detection
3 LiquidationGuardModule 3 (1 CRITICAL) Dust attack prevention, sandwich detection, self-liquidation, post-HF verification
4 FlashLoanShieldModule 2 (2 HIGH) 6 flash loan attack patterns, per-block activity tracking
5 UtilizationBreakerModule 2 (1 HIGH) Soft/hard circuit breakers, sweep rate limiting, velocity tracking
6 PositionGuardModule 5 (1 CRITICAL) Cross-hub validation, reentrancy snapshots, whale rate limits
7 PremiumValidatorModule 8 (1 CRITICAL) Independent premium recalc, halted spoke blocking, deficit fraud detection
8 IntentValidatorModule 8 (2 CRITICAL) Cross-chain replay prevention, atomic multicall, approval verification

Total coverage: 39/39 gaps addressed — all 7 CRITICAL, all 12 HIGH, all 16 MEDIUM.

Response Modes

Each module supports two response modes per spoke:

  • Soft mode (default): Charges a punitive fee proportional to threat severity. Attack becomes economically irrational while legitimate transactions proceed.
  • Hard mode: Reverts the transaction entirely. Used for critical attack patterns where any execution is unacceptable.

Access Control (Two-Tier)

Role Controls
Owner Protocol fees, treasury, module registry, spoke admin permissions, emergency pause
Spoke Admin Module selection, threshold tuning, hard/soft mode toggle (within owner-granted permissions)

All parameters are runtime-configurable — no redeployment required for fees, thresholds, permissions, or module implementations.

Revenue Model

  1. Protocol Fee — Configurable BPS on every operation (default: 5 BPS = 0.05%)
  2. Punitive Fee Share — When modules detect threats, configurable share goes to protocol treasury (default: 50%)
  3. Service Provider — Ongoing maintenance, monitoring, and incident response

Evidence of Work

GitHub Repository

  • 8 fully implemented security modules
  • AaveShieldRouter with delegatecall dispatch, fee engine, two-tier access control
  • 296 passing tests (unit, integration, invariant)
  • 95–100% line coverage across all modules
  • Full deployment and configuration scripts
  • MIT licensed

Sepolia Testnet Deployment (Verified on Etherscan)

All contracts deployed, registered, configured, and verified:

Contract Address Etherscan
AaveShieldRouter 0xE6b5B72d8909141b187bd71d2EBe2509a45C1d2f View
HubInvariantModule 0xB799601C457fbE8C9A6D652C65e3ac6947EE72d8 View
OracleValidatorModule 0x81695365d5ccdE878B8E024525910f286c236270 View
LiquidationGuardModule 0x664AE1aF620c61Dec7Ec0b881afA47Bb169C3f15 View
FlashLoanShieldModule 0x9ebE9389625eDeBC3B6987F79A02e28dBF2EB7E4 View
UtilizationBreakerModule 0x361f7b0aA62c608579B6FfbB05c728ed1048b7F6 View
PositionGuardModule 0xf8d9C1752f8584de4aB5BdFCE62e7833179D0af6 View
PremiumValidatorModule 0x6B595526a669F54EB59998F69072299B110f30c6 View
IntentValidatorModule 0x9F358e0dac6535980dC7950c3e48853372dF3403 View

Additionally deployed: MockHub, MockSpoke, MockOracle for end-to-end demonstration.

Mainnet Fork Validation

13 integration tests run against live Aave V4 mainnet state (Core Hub 0xCca852..., Main Spoke 0x94e7A5...), confirming:

  • Modules read real Hub asset state (liquidity, deficit, shares)
  • Modules read real Spoke reserve configurations
  • Modules read real oracle prices
  • All 8 modules configure correctly against real V4 addresses
  • Gas overhead within acceptable bounds

Test Coverage

Component Line Coverage
AaveShieldRouter 97.35%
AaveShieldMath 100%
HubInvariantModule 95%+
OracleValidatorModule 95%+
LiquidationGuardModule 95%+
FlashLoanShieldModule 95%+
UtilizationBreakerModule 95%+
PositionGuardModule 95%+
PremiumValidatorModule 95%+
IntentValidatorModule 95%+

Team

We built ShieldPad — the first modular security framework for Uniswap V4 hooks:

  • 5 security modules (anti-rug, MEV protection, oracle validation, volume guards, vesting unlock protection)
  • 143+ unit tests, ~90% line coverage
  • Same architecture: delegatecall composition, ERC-7201 namespaced storage, soft/hard modes
  • Deployed on Arbitrum One

AaveShield directly adapts ShieldPad’s proven architecture for Aave V4’s lending-specific attack surface, scaling from 5 modules / 15 attack vectors to 8 modules / 39 attack vectors.

Budget

Phase 1 — $50,000–$75,000

Already delivered:

  • All 8 modules implemented and tested
  • Sepolia deployment with Etherscan verification
  • 296 passing tests, 95%+ coverage
  • Full documentation

Remaining Phase 1 work:

  • Professional security audit (coordinated with Aave security)
  • Mainnet deployment preparation
  • Gas optimization pass
  • Community feedback integration

Phase 2 — Service Provider ($300,000–$500,000/year)

  • Module updates for new Spoke types and Hub upgrades
  • Real-time monitoring dashboard
  • Incident response support
  • Security advisory for governance proposals
  • Expansion to new chain deployments (Base, Arbitrum, etc.)

Budget Context

Reference Amount
AaveShield Phase 1 ask $50K–$75K
BGD Labs annual retainer Multi-million (expired)
Aave Labs recent funding $25M
V4 Sherlock audit contest $365K
V4 Sherlock bug bounty $1.5M ongoing
Protocol annual revenue $140M+

AaveShield’s ask is a fraction of the protocol’s security budget and fills the critical infrastructure gap left by BGD Labs’ departure.

Timeline

Phase Status Timeline
Security Analysis (39 gaps) Complete –
8 Module Implementation Complete –
296 Test Suite Complete –
Sepolia Deployment Complete –
Etherscan Verification Complete –
Mainnet Fork Validation Complete –
Community Review (this ARFC) Current April 2026
Professional Audit Pending May 2026
Mainnet Deployment Pending June 2026
Service Provider Proposal Future Q3 2026

How This Aligns with Aave

  1. Security first — 39 gaps identified and mitigated before any exploit occurs
  2. Non-invasive — Position Manager wrapper, no changes to Aave V4 core contracts
  3. Opt-in — Users choose to route through AaveShield; no governance action required for integration
  4. Open source — MIT licensed, fully auditable by community
  5. Revenue-aligned — Punitive fees make attacks economically irrational while funding ongoing security
  6. BGD replacement — Fills the security tooling gap with working code, not just proposals

Links

Copyright

Copyright and related rights waived via CC0.

2 Likes
2

I’ll be direct: this proposal should be fast-tracked. The $50-75K ask is almost absurdly cheap relative to the risk surface it covers, and the timing makes the case self-evident.

Aave V4 launched three weeks ago with a fundamentally new Hub & Spoke architecture. Three weeks later, the rsETH exploit demonstrated exactly what happens when infrastructure-layer risks cascade into protocol-level losses. Aave saw an $8B liquidity exodus as depositors fled uncertainty around collateral integrity.

Now consider the current situation:

  • BGD Labs, the primary security contributor, ceased contributions on April 1
  • The security retainer expires June 1
  • An independent analysis has identified 39 vulnerabilities, including 7 critical ones

This is a $25B protocol running a new, relatively untested architecture with its primary security provider departing and no replacement in place.

Vulnerability Analysis

The critical findings — cross-hub desync, oracle staleness propagation, flash loan position manipulation, dust liquidation exploits — are precisely the class of systemic risks that don’t manifest in isolation. They cascade.

Cross-hub desync is particularly concerning in a Hub & Spoke model. The entire architecture depends on state consistency across hubs. If desync is possible, then the composability that makes V4 powerful becomes the attack surface that makes it fragile. This is the same pattern we saw with rsETH: the feature (cross-chain liquid restaking) became the vulnerability (bridge-dependent price feed with no redundancy).

The dust liquidation exploit is a different flavor of the same problem, that being economic edge cases that individually seem minor but can be weaponized at scale. These are exactly the bugs that automated attackers find first.

Cost-Benefit Analysis

Let’s do the math that governance apparently needs spelled out:

  • TVL at risk: ~$25B
  • Security investment requested: $50-75K
  • Ratio: 0.0003% of protected value
  • rsETH-related losses: Hundreds of millions in liquidations + $8B in withdrawn liquidity
  • Cost of the rsETH exploit to the broader ecosystem: Still being calculated

For context, the rsETH incident — which exploited infrastructure risks of the exact type this audit would cover — caused more damage in hours than this grant would cost over its entire engagement. A single critical vulnerability left unpatched could dwarf this investment by orders of magnitude.

The question isn’t whether $50-75K is worth spending. It’s whether the governance process can move fast enough to close the security gap before it’s exploited.

The Post-rsETH Security Imperative

I’ve written extensively about the rsETH incident. Both the collateral ratio failures and the liquidity cascade it triggered across Aave. The core lesson is that infrastructure risks don’t stay contained. They propagate through every protocol that touches the compromised layer.

Aave V4’s Hub & Spoke architecture introduces new infrastructure-layer dependencies. Each hub, each spoke, each cross-hub interaction is a potential propagation vector. Without continuous, dedicated security coverage, you’re essentially hoping attackers don’t find the 39 vulnerabilities that an independent team already found.

What Governance Should Do (in my humble opinion)

  1. Approve this immediately. The June 1 security retainer expiration is a hard deadline. There should be no gap in coverage.
  2. Treat this as a floor, not a ceiling. $50-75K covers the initial engagement. Ongoing security for a $25B protocol with a new architecture should be a standing budget line, not a one-off grant.
  3. Require public disclosure of findings (with responsible delay for remediation). The community funding security research should have access to the results.
  4. Establish a security coverage SLA. No protocol of this scale should ever again find itself in a position where the primary security provider leaves with no succession plan.

The rsETH incident was a wake-up call. The question is whether Aave governance treats it as one, or waits for the next exploit to make the same argument more expensively.

-– Robby Greenfield | tokedex.org

1 Like
3

@robtg4 — Appreciate the direct read. A few responses:

On cross-hub desync and dust liquidation - these two scenarios are specifically why HubInvariantModule and LiquidationGuardModule exist as first-class modules rather than policies on a generic router. HubInvariantModule’s use of ERC-7201 namespacing and EIP-1153 transient storage addresses exactly this class of cross-Spoke drift. Dust liquidation is the messier one - the attack surface is a family of micro-position economics rather than a single threshold, and it’s where I’d most welcome external test vectors. If the rsETH work surfaced a specific pattern the current LiquidationGuardModule doesn’t cover, that’s the feedback worth upstreaming before Phase 1 scope freezes.

On “foundational, not temporary.” Agreed. The harder governance question is how the standing-coverage clause gets structured. Encoded as a hard DAO requirement, it’s valuable only if the market of credible providers is >1 - otherwise it’s fragile and creates lock-in that a future gap can’t remediate cleanly. One middle ground: approve AaveShield Phase 1 on its own technical merits, and let the ongoing-coverage norm be debated separately so it isn’t load-bearing on this proposal.

Also, noted IL Shield Protocol shipped on the 1st. Good to see the shield pattern getting built in adjacent problem spaces.

2 Likes
4

Good points across the board. A few responses:

On HubInvariantModule and LiquidationGuardModule as first-class modules: The architectural decision to make these discrete modules rather than policies on a generic router is the right call — it means failure in one doesn’t propagate through a shared execution path. The ERC-7201 namespacing for cross-Spoke drift is elegant and addresses the state isolation problem cleanly. My concern in the original comment was less about whether the modules exist and more about whether the coverage extends to adversarial interactions between modules under concurrent stress — the rsETH cascade wasn’t a single-vector attack, it was a sequence of individually rational steps that produced systemic failure when combined. That’s the test scenario worth prioritizing.

On dust liquidation and external test vectors: Agreed that the attack surface is a family rather than a threshold. The rsETH incident didn’t surface a dust liquidation pattern specifically, but it did demonstrate something adjacent: the attacker positioned all 7 loan addresses at health factors between 1.01 and 1.03 — the economic boundary where liquidation incentives become ambiguous, and liquidator behavior becomes unpredictable. That’s the same neighborhood where dust economics live. If the LiquidationGuardModule’s coverage includes adversarial HF clustering near boundary conditions — not just individual micro-positions but coordinated positioning across multiple accounts targeting the same collateral type — that would address the pattern. Happy to document the specific rsETH HF distribution data as a test vector if that’s useful for the Phase 1 scope.

On standing coverage and provider lock-in: Your framing of the governance question is more precise than mine was. You’re right that a hard DAO requirement for standing coverage is only as resilient as the provider market depth. Mandating coverage with n=1 credible providers creates a dependency that’s arguably worse than the gap it fills — you get coverage on paper but fragility in practice. The middle ground you propose — approve Phase 1 on technical merits, debate the ongoing norm separately — is the pragmatic path. The one thing I’d add: the standing-coverage debate should happen concurrently with Phase 1, not sequentially. If governance waits until Phase 1 concludes to discuss the ongoing coverage structure, you’re back in the same gap scenario that prompted this proposal: parallel tracks, not waterfall.

On IL Shield Protocol and the shield pattern: Worth watching. The convergence of shield/protection mechanisms across lending (AaveShield), LP provision (IL Shield / BELTA), and staking is an interesting design pattern — modular, composable protection layers that wrap existing protocol surfaces rather than modifying core logic. If these mature, they become a new infrastructure category with their own tokenomics and risk profiles. I’d like to see AaveShield’s long-term roadmap address composability with external shield protocols, particularly for positions that span multiple DeFi primitives where risks correlate.

-– Robby Greenfield | tokedex.org

1 Like
5

Thanks, useful. Four things.

Concurrent multi-module stress: yes, that’s a real gap. The suite today has 305 unit tests, one mainnet-fork integration, fuzz at 10k/50k runs, and invariants at depth 100. We don’t have a cross-module cascade harness yet. That’s worth adding in Phase 1. I’ll scope it as an explicit deliverable: a harness with the rsETH sequence (oracle drift, then boundary HF pre-positioning, then sequenced liquidations on the same collateral) as the first named test vector.

On HF clustering, LiquidationGuardModule today operates per-operation. It checks dust amount, caps per-block liquidation counts, observes post-liq HF via event, and tracks liquidator/victim pairs per block. It doesn’t currently detect the topological pattern you’re pointing at: pre-positioning of N accounts at HF 1.01-1.03 on the same collateral. That’s a setup step, not a trigger step. Fits as a Phase 1 extension: HF-distribution analytics at the Spoke level with configurable cluster-detection thresholds, run as a pre-check before the per-op path.

Re the rsETH data, yes please. If you can share per-address HF at t-0 (pre-cascade block), loan sizes, and collateral composition, I’ll incorporate it as a named test case in the cascade harness with attribution, and link the commit in a follow-up post here. If it’s easier, I can send the test-fixture interface first so the dump lands already shaped for it.

On the standing-coverage debate, agreed: parallel not sequential. Within two weeks of Phase 1 approval I’ll open a separate thread for an ongoing-coverage RFC that isn’t tied to AaveShield’s continuation, so the DAO can decide the norm on its own.

Composability with other shields isn’t in Phase 1. A cross-shield interop layer is a Phase 2 question, once two or more systems have stable surfaces. The correlation case is real though. A user who’s both an AaveShield borrower and an IL Shield LP has risks that move together, and interfaces are easier to align pre-audit than to retrofit. If you’re up for it, I’d co-design that abstraction with you offline while both projects are still at that stage.

1 Like
6

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.