Aave Governance

[TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance Author: ACI Date: 2026-03-19 --- Simple Summary The current proposal is set to onboard Sonic stablecoin USSD to Aave V3 Sonic Instance. USSD will enable users to supply USSD for yield and use it as a stable borrowing mechanism. Motivation USSD is Sonic's network-integrated USD stablecoin designed to become the key source of stable liquidity across the Sonic ecosystem, built on Frax's frxUSD infrastructure. USSD is backed 1:1 by high-quality USD assets and can be redeemed back to USDC on any CCTP-supported chains, providing a familiar and reliable on and off-ramp. Using Layer Zero interoperability, USSD enables users to mint USSD from over 10+ chains directly to Sonic. Reserves consist of short-duration, tokenized U.S. Treasury products, including BlackRock's BUIDL, Superstate's USTB, and WisdomTree's WTGXX, custodied with regulated providers to support redemption confidence and regulatory alignment. Technical details: USSD is minted through non-custodial smart contracts at a 1:1 ratio with no minting fees. Supported mint assets include: Stablecoins: USDC, USDT, PYUSD, USDB Tokenized Treasuries: BUIDL, USTB, WTGXX, and other approved USD/Treasury representations Peg: 1:1 USD Reserve Composition: Tokenized short-duration U.S. Treasury instruments: - BlackRock USD Institutional Digital Liquidity Fund (BUIDL) - Superstate Short Duration U.S. Government Securities Fund (USTB) - WisdomTree Government Money Market Digital Fund (WTGXX) Minting: Zero-fee, non-custodial smart contracts on Sonic Collateral Types: USDC, USDT, PYUSD, USDB, BUIDL, USTB, WTGXX, and others at 1:1 ratio Custodians: Regulated institutional custodians Contract Address (Sonic): https://sonicscan.org/token/0x000000000eccff26b795f73fb0a70d48da657fef Specification Risk Parameters will be provided by Risk Service Providers and proposal will be updated accordingly at ARFC stage. Useful Links: https://www.soniclabs.com/ussd https://blog.soniclabs.com/ussd-sonics-native-permissionless-usd-stablecoin-built-with-frax/ https://docs.soniclabs.com/sonic/ussd Next Steps 1. Publication of TEMP CHECK to gather community & service providers feedback, and escalate to TEMP CHECK Snapshot. 2. Publication of a standard ARFC, if TEMP CHECK Snapshot passed, to continue collecting community & service providers feedback before escalating proposal to ARFC snapshot stage. 3. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Disclaimer The current proposal is powered by Skwyards. ACI is not compensated for creating this proposal. Copyright Copyright and related rights waived via CC0

[ARFC] Bug Bounty Program on Sherlock 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 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: strong visibility to experienced researchers, low spam volumes, and 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 and Critical reports while keeping Medium and Low submissions open to everyone, paired with a defined triage workflow and periodic summaries. Specification This ARFC proposes launching a dedicated Aave V4 bug bounty program on Sherlock as an always-on reporting channel for Aave V4. The program is scoped specifically to Aave V4 and covers the final list of in-scope repositories, contracts, and environments included in the launch configuration. Sherlock would provide self-service program configuration across scope, severity criteria, payout amounts, and notification routing, with support for standard and custom integrations across Aave’s preferred operating channels. Triage and Routing The program would operate under the following submission and triage structure: High and Critical submissions Require a 250 USDC stake at submission Return the stake for valid reports alongside any bounty payout Forfeit the stake for invalid reports to offset triage costs Medium and Low submissions Remain open without a stake requirement Cannot later be upgraded into High or Critical payout tiers Report handling High and Critical reports follow an expedited routing path Sherlock notifies Aave’s designated responders through agreed communication channels Medium and Low reports move through Sherlock’s standard review flow Aave keeps visibility into submissions and outcomes through the Sherlock dashboard Pricing and Payout Sherlock would provide hosting, triage, and program administration without a fixed annual platform fee, and instead receive a 5% fee on bounty payouts. :contentReference[oaicite:1]{index=1} | Annual Payouts | 5% Fee | | --- | ---: | | $100,000 | $5,000 | | $200,000 | $10,000 | | $300,000 | $15,000 | | $450,000 | $22,500 | | $500,000 | $25,000 | Scope and Severity Criteria | Severity Level | Reward Range | | --- | --- | | Critical | $25,000 - $500,000 | | High | $5,000 - $25,000 | | Medium | Flat $5,000 | | Low | Flat $1,000 | These amounts can be increased as the protocol is hardened and more TVL is increased. Scope Hub src/hub/Hub.sol src/hub/HubConfigurator.sol src/hub/AssetInterestRateStrategy.sol All base contracts they inherit from and libraries used Spoke src/spoke/AaveOracle.sol src/spoke/instances/SpokeInstance.sol src/spoke/instances/TokenizationSpokeInstance.sol src/spoke/instances/TreasurySpokeInstance.sol src/spoke/SpokeConfigurator.sol All base contracts they inherit from and libraries used Periphery src/position-manager/NativeTokenGateway.sol src/position-manager/SignatureGateway.sol src/position-manager/ConfigPositionManager.sol src/position-manager/GiverPositionManager.sol src/position-manager/TakerPositionManager.sol All base contracts they inherit from and libraries used src/access/AccessManagerEnumerable.sol Additional coverage Use and integration of external dependencies, excluding their internal code Next Steps 1. If consensus is reached on this ARFC, the proposal can proceed to Snapshot with the finalized commercial structure, scope, and payout framework. 2. If Snapshot passes, an AIP can then be submitted to approve the Sherlock engagement and authorize implementation of the Aave V4 bug bounty program. Disclaimer This ARFC 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. Copyright Copyright and related rights waived via CC0.

[ARFC] Aave V4 Activation on Ethereum Mainnet Summary This proposal seeks community approval to deploy Aave V4 to Ethereum Mainnet through a security-first initial setup with conservative risk parameters and a deliberately narrow Hub and Spoke configuration. Aave V4 introduces a modular architecture where Liquidity Hubs hold shared liquidity and Spokes define distinct borrowing environments with governance-bounded exposure. This design preserves the depth and efficiency of unified liquidity while allowing for more precise risk management and support for a broader range of market structures. A deployment on Ethereum Mainnet would establish the foundation for V4 as Aave’s next-generation credit infrastructure. Motivation Aave is the leading liquidity protocol in DeFi. V4 builds on that position by extending the architecture to support a much broader financial system onchain. As onchain credit expands across more collateral types and risk profiles that form new market structures, Aave needs a framework that can keep liquidity unified while allowing markets to be configured to their own parameters. Capital Efficiency, Risk Pricing, and Credit Expansion The next phase of onchain finance brings a new range of market requirements: New collateral types: Collateral with hard maturities, constrained redemption, or offchain counterparty exposure requires tighter exposure boundaries, and market logic that does not force unlike risks into the same assumptions. Credit structures: Positions shaped by duration, payout profile, or defined repayment paths require borrowing terms and liquidation logic that can follow the structure of the position itself rather than a single generalized market design. Productive infrastructure: Cash-flow-backed markets which involve productive infrastructure require borrowing terms, pricing, and exposure limits that reflect scalable energy output, recurring cash generation, and longer-duration repayment profiles. Supporting new market needs has often meant deciding whether unlike token exposures should share the same borrow curve, reserve configuration, and liquidity base, or they can be moved into isolated markets that preserve cleaner boundaries but require separate liquidity and separate growth. In Aave V4, Spokes keep those market-specific rules and risk boundaries separate, drawing from a Hub that contains deep liquidity reserves. Credit lines make each Spoke’s access explicit and bounded, so novel markets can be introduced without merging unlike risks into the same market configuration or forcing isolated liquidity bootstrapping each time. Once market logic is separated, borrowing costs can be matched more closely to the risk being introduced. V4 provides an additional risk pricing mechanic at the collateral level, so stronger positions are not diluted by weaker ones, and more complex token exposures contribute premium in line with their risk profile. Thus, suppliers are compensated on terms that more closely reflect the risk drawn from shared liquidity, and protocol revenue benefits directly from diverse exposure. As exposure diversifies with more Spokes drawing from shared liquidity, the accounting model is challenged to keep supplier claims, borrower debt, and liquidation flows consistent across the deployment. In Aave V4, supply and debt are tracked through shares, so different borrowing environments can apply different market logic while still settling cleanly against the same balance sheet. Liquidity claims, debt, and liquidation state remain consistent even as Spokes diverge in how they price and manage risk. Taken together, these changes evolve Aave beyond a single generalized lending design. Liquidity depth is maximized, risk is priced with precision, and a wider range of lending activity can be supported onchain, within one framework, while segregating risk. This positions Aave to become the infrastructure for global onchain finance. Specification This proposal covers the initial Ethereum Mainnet deployment of the Aave V4 codebase, the intended launch topology, the rollout path, the implementation and control model, the initial asset universe for risk parameterization, and the security basis for activation. Final parameter values remain subject to risk provider review and will be included in the activation AIP. Hub and Spoke Configuration The initial deployment is similar to the three-Hub layout currently under discussion with Core, Prime, and Plus Hubs. In that candidate setup, Core serves as the default liquidity and routing venue, Prime is designed for suppliers seeking a more controlled collateral posture, and Plus is designed for strategy-heavy stablecoin activity that should scale behind its own caps and pause conditions rather than push Core-wide limits. Core Hub | Spoke | Collateral | Borrowable | |---|---|---| | Main Spoke | wETH, wstETH, weETH, wBTC, cbBTC, USDT, USDC, LINK, AAVE | wBTC, cbBTC, wETH, USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC | | Lido Spoke (e-Mode) | wstETH | wETH | | EtherFi Spoke (e-Mode) | weETH | wETH | | Kelp Spoke (e-Mode) | rsETH | wETH | | Lombard BTC Spoke (e-Mode) | LBTC | wBTC, cbBTC | | Gold Spoke | XAUt | USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC | | Forex Spoke | USDT, USDC, EURC | USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC | Prime Hub | Spoke | Collateral | Borrowable | |---|---|---| | Bluechip Spoke | wETH, wstETH, wBTC, cbBTC | USDT, USDC, GHO, coreUSDT, coreUSDC, corefrxUSD, coreEURC | Plus Hub | Spoke | Collateral | Borrowable | |---|---|---| | Ethena Ecosystem Spoke | PT-sUSDe, PT-USDe, sUSDe, USDe | USDT, USDC, USDe, GHO, coreUSDT, coreUSDC, corefrxUSD | | Ethena Correlated Spoke | PT-sUSDe, PT-USDe, sUSDe, USDe | USDe | Each supported asset in each Hub comes with its own tokenization form through a Tokenized Spoke, allowing deposits to be wrapped into tokenized supply positions without enabling borrow capabilities. Tokenized supply positions are ERC-4626 compliant, allowing them to be used in integrations built on top of Aave V4. Note, borrowable tokens with the core prefix are credit lines from the Core Hub, and tokens drawn from other Hubs will have an appropriate prefix. The initial list of assets included in this configuration are: AAVE EURC GHO LBTC LINK PT-sUSDe PT-USDe RLUSD USDC USDT USDe USDG XAUt coreEURC coreUSDC coreUSDT corefrxUSD cbBTC frxUSD rsETH sUSDe wBTC wETH weETH wstETH Parameters will be provided by Risk Service Providers and included in the AIP. Rollout The rollout will begin on Ethereum Mainnet with a deliberately narrow initial activation surface, with security and controlled production hardening taking priority over immediate growth. It will bring V4 online with conservative parameters and minimal assets, so the DAO can observe early liquidity routing, utilization concentration, and credit-line draw behavior. Supply and borrow caps will be carefully monitored and adjusted over time per risk providers recommendations to grow the protocol with a security first approach. When live conditions support it, the DAO can lift caps, extend or resize credit lines, onboard additional assets, and configure new Hubs or Spokes. Implementation Aave Labs will deploy the V4 system and prepare the initial configuration in line with the architecture approved by governance and the final recommendations of the risk service providers. Activation will occur through a subsequent AIP that includes the deployed contract addresses together with the finalized launch parameters. Within the V4 architecture, the Liquidity Hub is the immutable coordinator for shared liquidity and emergency-stop functionality, while Spokes are upgradeable modules that manage user-facing lending logic, reserve configuration, and oracle interactions. Each Hub maintains the registry of authorized Spokes, sets the relevant caps, and enforces the core accounting invariants that govern shared liquidity and debt across the system. Guardian Roles At launch, Aave V4 will use a Protocol Security Council that operates in a role similar to the Guardian framework in Aave V3. During the initial hardening phase, this council will hold the emergency powers needed to safeguard the protocol. Those permissions are expected to step down after hardening, at which point updates will proceed through AIPs and approved stewards, while the council retains pause and freeze powers for emergencies only. A Stewardship Council is outside the initial launch scope and, when introduced, will come through a follow-up proposal in a role similar to Aave V3 Risk Stewards. Risk changes during the hardening phase are expected to be limited. Security The security basis for launch reflects a year-long review process embedded throughout V4 development. Across that process, V4 underwent roughly 345 days of cumulative security review spanning manual audits, formal verification, invariant testing, fuzzing, and a public security contest, supported by a $1.5 million DAO-ratified security budget. Published materials already include audit reports from Trail of Bits, Blackthorn, and ChainSecurity, together with dedicated invariant and fuzz testing across core V4 components. More information on Aave V4’s security approach can be found in the Security by Design post. The relevant materials are being compiled here: https://github.com/aave/aave-v4/tree/main/audits Aave V4 Interface and Documentation At launch, Aave V4 will be hosted on a dedicated interface at pro.aave.com rather than within app.aave.com. Supporting materials are available through the Aave V4 technical docs in the core repository and the public Aave V4 documentation, both of which will continue to be expanded as the system moves toward activation. Next Steps 1. Seek community feedback and risk analysis. 2. If community consensus is reached, raise to Snapshot. 3. If the Snapshot outcome is positive, escalate to an AIP, with full risk parameters included, to deploy and activate Aave V4 to Mainnet. Disclaimer Aave Labs is the primary contributor to Aave V4 and is directly involved in its design, development, and deployment planning. Aave Labs received compensation to develop Aave V4 under the Aave Labs Service Provider Contract. Copyright Copyright and related rights waived via CC0.

Simple summary Proposal to expand the Aave/Chainlink SVR system to Aave v3 Base and Arbitrum. --- Motivation In March 2025, we proposed activating the Aave/Chainlink SVR system for a subset of assets on Aave Ethereum pools. SVR is a layer built on top of block searching and building, as well as price oracles, to recapture value from Aave liquidations, later redirecting this value for protocol protection through mechanisms like Umbrella. After that initial activation, we followed up with two additional phases that expanded the set of assets covered in Ethereum. Since then, the majority of liquidation volume has occurred via SVR without any issues, even during highly volatile events like the 10th of October 2025. Even if SVR on Ethereum has been a very successful project, there has not been any expansion to other networks before due to architectural constraints. The block building model on, for example, L2s is substantially different, and the SVR architecture required adaptation by Chainlink in those environments, to have maximum assurance and consistency with the running Ethereum system. To cover those architectural network differences, Chainlink has adapted the architecture of SVR, but without changing the major assumptions about its system. More precisely, SVR on non-Ethereum networks works as follows: 1. Instead of using Flashbots as a separate transactions coordination and auctioning layer on non-Ethereum networks, it uses Chainlink's native infrastructure, partially from Atlas, a system acquired by Chainlink from Fastlane. 2. The main difference of this system is that settlement/ordering of transactions happens in a smart contract layer now (akin to a multicall/ERC-4337 setup), without the need for a private mempool. 3. Same as with Flashbots, searchers submit a bid, in this case, explicitly to “batch” transactions after a price oracle update. So in the case of the Aave protocol, a transaction to “append” after the price oracle update is a liquidation transaction. 4. Similar to SVR on Ethereum, the system still keeps the same flow of fallback to the “public mempool” (sequencer transactions pool in L2s). In parallel with opening the SVR auction to searches, the price oracle update is sent to the public mempool too, in order to fallback after the defined time and avoid any major price delay. Technically, the fallback delay can be substantially shorter than the configured on Ethereum (10s vs 60s), but we think it makes sense to keep similar parameterization as Ethereum, given that price sourcing is not chain-specific (generated by Chainlink's DON). In summary, the trust model of SVR is the same as on Ethereum mainnet, given that price updates generated by the Chainlink DON are still the main trigger for updates, and the mechanism of fallback still mirrors Ethereum. Consequently, we think it is a good next step to activate extra networks with SVR on Aave. --- Specification The initial targets of this multi-network expansion are Base and Arbitrum, both because Chainlink has been battle-testing the new system there, and due to being two of the biggest Aave instances. Different from the other activation phases of SVR in the past on Ethereum, it is now simpler to reduce the operational overhead of multiphase and have only one activation proposal, given that: The SVR architecture is battle-tested on the majority of all Aave’s volume, while on Ethereum, SVR was a totally new system. On L2s/non-Ethereum L1s, SVR is a more “native” system of Chainlink, hence simpler to cover more feeds. Chainlink has been testing the infrastructure during the previous months. Consequently, we propose to activate the following feeds for each network. It is important to highlight that in composed prices (combining, for example, ETH/USD and exchange rate), only the internal components using Chainlink data will be swapped to SVR feeds, and only those with any influence on liquidations. These will be decided at AIP stage. Base WETH, cbETH, USDbC, wstETH, USDC, weETH, cbBTC, ezETH, wrsETH, LBTC, EURC, AAVE, tBTC, syrupUSDC Arbitrum DAI, LINK, USDC, WBTC, WETH, USDT, AAVE, wstETH, rETH, LUSD, USDCn, FRAX, ARB, weETH, ezETH, rsETH, tBTC. SVROracleSteward Similar to all activations of SVR on Ethereum, this expansion will include SVROracleStewards. To refresh the community on the concept, the SvrOracleSteward allows for the Aave Protocol Guardian to replace any of the newly introduced SVR feeds, by exclusively the non-SVR feed currently used in production. This way, even in the very unexpected worst-case scenario of the new SVR simply not being functional or having a really major issue, the Aave Protocol Guardian could immediately swap back to the standard price feeds currently used in production.

Summary This proposal introduces a two-part licensing framework for the canonical Aave V4 repositories: a BUSL–based license for the core codebase, and a Contributor License Agreement (CLA) for anyone who wants to contribute to the codebase. The goal is to put in place a framework that is clear, consistent, enforceable, and fair to contributors. Together, these two elements would create a transparent foundation for how V4 is developed and shared going forward. Motivation V4 represents one of the most significant innovations for the protocol to date. Its modular architecture is designed to set the foundations for continuous expansion, and will enable the protocol to evolve over time while maintaining the path for community contributions. The proposed approach follows the same core principle used for V3 under BUSL: protect the codebase for a defined period, then transition to open source automatically. With V4, the goal is the same, but with a couple of improvements suggested for the implementation. Today, the community is preparing for the production release and the finalisation of the governance-aligned licensing framework. In line with the V4 development proposals, the intention is to migrate the V4 canonical repository under DAO ownership, with the full licensing package and CLA published for the community. This proposal introduces a couple of practical improvements to make that model more robust and clear to the community. First, contributions. V4 is intentionally more extensible, and we expect more contributions from service providers and community builders. The proposed CLA brings those contributions under the same licensing framework as the core codebase. This keeps the repository licensing coherent and avoids fragmentation as the ecosystem grows. Second, clarity. The V4 repository uses SPDX license identifiers at the file level rather than applying a single license across the entire codebase. We are looking to restructure the repository so that each file will include a simple header indicating its license using SPDX identifiers, with the full license texts stored in a /licenses folder in the repository. This makes it easy to follow which license applies to which part of the code. This structure also aligns well with possibilities that come with the modular Hub and Spoke architecture of V4. Together, these improvements are designed to make the V4 licensing framework clearer, more resilient, and better aligned with the community and how the protocol will evolve. Specification BUSL-based repository license (Aave V4 core) Please review the proposed text here: BUSL\LICENSE The V4 core repository will be licensed under BUSL, consistent with the approach taken for V3 BUSL implementation, with these clarifications: DAO Ownership. Aave DAO is the owner of the canonical Aave V4 codebase and the associated intellectual property rights. During the development phase of Aave V4, Aave Labs has held the relevant copyright and licensing authority to protect and administer those rights on behalf of the Aave DAO while the governance-aligned licensing framework is finalised. Restriction design. V4 BUSL inherits the broad principles of the earlier BUSL restriction framework defined by the community, but with change in how those restrictions are phrased. V3’s language leaned on outcome-based concepts, things like “harm” or “migration”, which we think shifts the burden of proof in an unhelpful direction. V4 BUSL approach would improve the approach by reframing the underlying restrictions in conduct-based terms: what was deployed, where, and for what purpose, because it would make it far easier to act on in practice. Change Date. Consistent with the BUSL, the codebase transitions automatically to a permissive open-source license on the Change Date. That mechanism is unchanged from V3 BUSL. We suggest that the Change Date occurs within 5 years from the date of deployment of Aave V4 or earlier as recorded in a designated “changedate” text record. Scope note on architecture. This license governs the canonical repository and derivatives under copyright doctrine. Custom deployments that don’t incorporate or derive from the canonical repository code are not intended to fall within its scope. Aave V4 Contributor License Agreement (CLA) Please review the proposed text here: CLA\LICENSE Any contributor to the canonical V4 repository will be asked to accept the CLA. The CLA is a license, not a transfer of ownership. Contributors are not handing their rights over, instead, they’re granting the community a consistent, irrevocable right to use, incorporate, and sublicense their contribution as part of the canonical codebase. This matters because, without a CLA, contributions sit in an ambiguous space: the community may not have a clear, enforceable right to the code it’s building on. The CLA just formalises what should be common sense, and ensures the licensing framework applies consistently across the entire repository. Next Steps 1. Engage with the community and service providers to refine the detailed proposal 2. If consensus is reached on this TEMP CHECK, escalate this proposal to the Snapshot stage 3. If the TEMP snapshot outcome is YAE, incorporate stakeholder feedback and move proposal to ARFC stage 4. If consensus is reached on the ARFC, escalate the proposal to the Snapshot stage 5. If the ARFC snapshot outcome is YAE, execute the IP transition (including modifications arising from governance discussions), along with the transfer of the V4 core IP and the migration of the canonical repositories into the Aave DAO code repository. Copyright Copyright and related rights waived via CC0.

Summary This publication proposes reducing the annual AAVE buyback budget from approximately $50M to $30M ad outlined in the Aave DAO Funding Insights forum post. Motivation As outlined in the Aave DAO Funding Insights publication, the DAO's borrow fee revenue has declined approximately 25% from its peak, with January 2026 revenue of $7.95M, down from $13.5M in January 2025. At the same time, the optimistic 2026 operational budget is estimated at $190M, resulting in a structural deficit relative to 2025's annual revenue of $142M. Recalibrating the buyback program is a necessary step to ensure operational sustainability. Since its inception in April 2025, the buyback program has successfully acquired over 205,000 AAVE (1.28% of total supply), demonstrating the protocol's strong net acquisition posture. At a reduced $30M annual budget, the DAO would still acquire an estimated 292 AAVE per day, sustaining meaningful accumulation while preserving stablecoin reserves for operations and growth initiatives. The transition to include volatile assets, such as ETH, in stablecoin-funded buybacks is supported by the DAO's treasury composition. Across all of the wallets, the treasury holds approximately $40M in ETH-correlated assets. Given the strong historical relative correlation between AAVE and ETH, swapping between these assets is a relative-value trade with significantly lower volatility risk than converting from USD-denominated assets. This approach preserves the DAO's stablecoin reserve, critical for funding service providers, growth programs, and operational runway, while utilising assets that are naturally aligned with AAVE's price movements. The MainnetSwapSteward already supports ETH-to-AAVE swap routes, enabling this transition without additional infrastructure. Specification | Parameter | Current | Proposed | Delta | | --- | --- | --- | --- | | Annual Budget | ~$50M | ~$30M | -$20M | | Primary Funding Source | Stablecoins | ETH / Volatile Assets | — | | Est. Daily Acquisition | ~487 AAVE/day | ~292 AAVE/day | -195 | | Est. Annual Acquisition | ~177,855 AAVE | ~106,580 AAVE | -71,275 | The MainnetSwapSteward will be configured to prioritise ETH and ETH-correlated assets (wETH, wstETH) as the primary input for AAVE acquisitions. Stablecoin-funded buybacks will continue on a secondary basis as needed to meet the target budget, but the majority of acquisition volume will shift to volatile assets. The reduced budget maintains the DAO's position as a net acquirer of AAVE while freeing approximately $20M annually in stablecoin reserves for operational needs. Forward Looking Statement TokenLogic will continue to monitor buyback execution, AAVE acquisition rates, and treasury composition following this adjustment. As the Aave DAO’s revenue and growth spending commitments are met, the buyback program will be revised to direct capital to the areas that generate the highest returns for token holders. This proposal is part of the broader set of recommendations outlined in the Aave DAO Funding Insights publication, which also covers Safety Module emission reductions, GHO liquidity strategy, and treasury management priorities for 2026. Disclosure TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If the snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

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: 1. $24,000 fixed annual cost for hosting \+ triage, or 2. 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 1. Engage with the community and service providers to refine the detailed proposal 2. If consensus is reached on this TEMP, escalate this proposal to the Snapshot stage 3. If the TEMP snapshot outcome is YAE, incorporate stakeholder feedback and move proposal to ARFC stage Copyright Copyright and related rights waived viaCC0.

Summary The publication proposes implementing the AAVE Emission reduction as presented in the Aave DAO Funding Insights forum post. Motivation As outlined in the Aave DAO Funding Insights publication, the Aave DAO's buyback program has acquired over 205,000 AAVE (1.28% of total supply) in under a year, demonstrating the protocol's strong net acquisition posture. With the DAO acquiring AAVE faster than it distributes, there is a clear opportunity to further reduce Safety Module emissions while maintaining robust security coverage. stkAAVE participation has remained stable through previous emission reductions, net inflows of +98,600 AAVE in January 2026 and +60,100 AAVE in February 2026 indicate that stakers are resilient to moderate yield compression. At 16.78% of total supply staked, the Safety Module maintains strong coverage well above the levels needed for protocol security. !image|1620x1620 Source: coming soon Meanwhile, the Aave Finance Committee has deployed deeper Protocol-Owned Liquidity (POL) for AAVE/wETH, removing the dependency on rented liquidity via stkABPT emissions. The combined 29,200 AAVE saved annually represents nearly 0.18% of total supply, a meaningful reduction in annual AAVE emissions, valued at $3,212,000 at $110/AAVE. stkAAVE stkAAVE Emissions have been progressively reduced !Screenshot 2026-03-02 at 19.30.03|711x215 To accommodate the AAVE emission reduction, the Cooldown duration is reduced from 7 days to 2 days, making stkAAVE more liquid and suitable for various integrations such as CEX Earn programs and Future markets. stkABPT !Screenshot 2026-03-02 at 19.30.31|712x285 The Aave Finance Committee provided deeper AAVE/wETH liquidity following the implementation of the February 2026 - Funding Update. The Aave DAO can now proceed to reduce AAVE emissions to stkABPT holders, knowing that sufficient and reliable AAVE/wETH liquidity is available to support AAVE liquidations. Specification The tables below summarise the key amendments to the SM and the anticipated impact on depositors' yield. !Screenshot 2026-03-02 at 19.30.58|713x531 Forward Looking Statement TokenLogic will continue to monitor Safety Module participation and staker behaviour following these changes. If stkAAVE participation remains stable after the proposed emission reduction, further optimisations may be explored in future proposals. The transition from stkABPT emissions to Protocol-Owned Liquidity marks a structural shift in how the DAO ensures market depth in the AAVE/wETH pools. The AFC's POL strategy provides permanent, protocol-owned liquidity at near-zero marginal cost. Its effectiveness will be closely tracked. These changes are part of the broader set of recommendations outlined in the Aave DAO Funding Insights publication, which also covers buyback program adjustments, GHO liquidity strategy, and treasury management priorities for 2026. Disclosure TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If the snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

Summary This ARFC proposes the deployment of an Aave v3 Instance on X Layer. Motivation X Layer is expected to act as both a payment-focused network and a DeFi hub, creating new avenues for user onboarding, real-world adoption, and capital efficiency. Deploying on Aave v3 on X Layer continues the strategy of taking Aave to users. X Layer has the potential to significantly grow Aave’s reach, strengthen user acquisition through OKX's user base, and capture fresh liquidity. X Layer's vision is to serve as a general-purpose platform for payments and DeFi, connecting users and businesses with on-chain opportunities. The core focus will be on building infrastructure that enhances both financial accessibility and scalable DeFi applications. Aave Protocol will be a key pillar of the X Layer ecosystem. Specification The below values are for indicative purposes only, that will updated upon receiving feedback from both LlamaRisk and Chaos Labs. Aave Protocol General Configuration | Parameters | Value | Value | Value | Value | Value | Value | Value | Value | Value | | ------------------------ | --------- | --------- | --------- | --------- | --------- | --------- | --------- | --------- | --------- | | Asset | USDT0 | USDG | GHO | xBTC | wOKB | xETH | xSOL | xBETH | xOKSOL | | Isolation mode | No | No | No | No | No | No | No | No | No | | Borrowable | Yes | Yes | Yes | Yes | No | Yes | Yes | No | No | | Collateral enabled | Yes | No | No | Yes | No | Yes | Yes | Yes | Yes | | Supply Cap |50,000,000 | 5,000,000 | 5,000,000 | 150 | 125,000 | 5,000 | 110,000 | 5,700 | 135,000 | | Borrow Cap |48,000,000 | 4,250,000 | 4,800,000 | 20 | - | 1,300 | 14,000 | - | - | | Debt Ceiling | - | - | - | - | - | - | - | - | - | | LTV | 70.00% | - | - | 70.00% | - | 70.00% | 60.00% | - | - | | LT | 75.00% | - | - | 75.00% | - | 75.00% | 65.00% | - | - | | Liquidation Bonus | 7.50% | - | - | 7.50% | - | 7.50% | 7.50% | - | - | | Liquidation Protocol Fee | 10% | - | - | 10% | 10% | 15% | 10% | 10% | 10% | | Variable Base | 0% | 0% | 0% | 0.00% | - | 0.00% | 0.00% | - | - | | Variable Slope1 | 5.0% | 5.0% | 5.0% | 2.75% | - | 2.50% | 5.00% | - | - | | Variable Slope2 | 40.0% | 45.0% | 45.0% | 40.0% | - | 20.0% | 20.0% | - | - | | Uoptimal | 90.0% | 80.0% | 90.0% | 80.0% | - | 90.0% | 80.0% | - | - | | Reserve Factor | 10% | 10% | 10% | 10% | - | 15.0% | 15.0% | - | - | | Stable Borrowing | Disabled|Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | | Flashloanable | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | Siloed Borrowing | No | No | No | No | No | No | No | No | No | | Borrowed in Isolation | No | No | No | No | No | No | No | No | No | | E-Modes | 1,2,3,4 | 1,2,3,4 | 1,2,3,4 | 1 | 4 | 2,5 | 3,6 | 5 | 6 | eMode #1 | Parameter | Value | Value | Value | Value | | --------------------- | --------- | --------- | --------- | --------- | | Asset | xBTC | USDT0 | USDG | GHO | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | Max LTV | 78.00% | - | - | - | | Liquidation Threshold | 81.00% | - | - | - | | Liquidation Bonus | 6.00% | - | - | - | eMode #2 | Parameter | Value | Value | Value | Value | | --------------------- | --------- | --------- | --------- | --------- | | Asset | xETH | USDT0 | USDG | GHO | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | Max LTV | 78.00% | - | - | - | | Liquidation Threshold | 80.00% | - | - | - | | Liquidation Bonus | 6.00% | - | - | - | E-Mode #3 | Parameter | Value | Value | Value | Value | | --------------------- | --------- | --------- | --------- | --------- | | Asset | xSOL | USDT0 | USDG | GHO | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | Max LTV | 65.00% | - | - | - | | Liquidation Threshold | 70.00% | - | - | - | | Liquidation Bonus | 7.50% | - | - | - | eMode #4 | Parameter | Value | Value | Value | Value | | --------------------- | --------- | --------- | --------- | --------- | | Asset | wOKB | USDT0 | USDG | GHO | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | Max LTV | 50.00% | - | - | - | | Liquidation Threshold | 55.00% | - | - | - | | Liquidation Bonus | 10.00% | - | - | - | eMode #5 | Parameter | Value | Value | | --------------------- | --------- | --------- | | Asset | xBETH | xETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 88.00% | - | | Liquidation Threshold | 90.00% | - | | Liquidation Bonus | 2.00% | - | eMode #6 | Parameter | Value | Value | | --------------------- | --------- | --------- | | Asset | xOKSOL | xSOL | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 88.00% | - | | Liquidation Threshold | 90.00% | - | | Liquidation Bonus | 2.00% | - | 27/02/2026 Note: Upon discussions with the OKX team and Risk Service providers, the above tables have been updated to reflect on-chain liquidity considerations and X Layer's preferred go-to-market strategy. CAPO Parameters sUSDe | Token | Snapshot Delay | maxYearlyGrowthRatio | | :---: | :------------: | :------------------: | | sUSDe | 14 days | 15.19% | | Token | Snapshot Delay | ratioReferenceTime | maxYearlyGrowthRatio | | :---: | :------------: | :------------: | :------------------: | | syrupUSDC | 7 days | monthly | 19.94% | Upon confirmation of the Aave deployment on X Layer, the X Layer team will: X Layer will provide a rewards budget, currently being finalised. OKX wallet and exchange user base will be encouraged to use X Layer Early discussions with partners indicate additional rewards are being provided to support the adoption of various products. X Layer will support the integration and assist with boosting the adoption of Aave's GHO stablecoin within its ecosystem, targeting real-world and institutional use cases. Collaborate with liquidity providers, institutional capital allocators, and partners to expand supply in Aave v3 for xBTC and stablecoins. Entrust TokenLogic and ACI, on behalf of Aave DAO, to manage the design and distribution of liquidity mining campaign to Aave users respectively. Disclosure TokenLogic does not receive any payment for this proposal. Next Steps 1. Publish an ARFC to continue gathering community and Service Providers feedback. 2. Escalate proposal to ARFC Snapshot. 3. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via CC0.

Summary This TEMP CHECK seeks the community’s input on deploying the Aave Protocol on Monad, a fully EVM-compatible, high-throughput network well-suited to supporting high-frequency DeFi applications. Motivation Monad’s core differentiator is its pipelined and parallelised EVM execution architecture, enabling significantly higher throughput and lower latency than legacy layer-1 blockchain networks with 400ms block times and 800ms finality, while maintaining full Ethereum compatibility. By processing transactions concurrently rather than sequentially, and by pipelining transaction execution with BFT consensus, Monad unlocks a performance profile particularly well-suited to real-time financial applications. This technical foundation directly aligns with a key growth vector for the ecosystem: servicing neobanks and fintech platforms that require fast, reliable, and scalable on-chain infrastructure. Neobanks operating on-chain or integrating DeFi primitives require: Low-latency transaction finality High throughput under peak demand Predictable execution costs Battle-tested, proven, reliable liquidity infrastructure Monad’s architecture addresses the first three requirements through optimised execution and consensus design. Aave addresses the fourth. By deploying Aave v3.6 or v3.7 on Monad, the Aave Protocol would become a cornerstone liquidity layer supporting: On-chain savings and yield products Instant credit lines and undercollateralized fintech integrations (where applicable) Embedded lending and borrowing services within neobank apps Treasury management solutions for fintech platforms Stablecoin liquidity infrastructure Monad’s full EVM compatibility ensures seamless deployment of existing Aave v3 infrastructure without contract rewrites, allowing rapid time-to-market and ecosystem activation. This compatibility also lowers integration friction for fintechs already building within the broader Ethereum ecosystem. Importantly, as neobanks seek blockchain infrastructure capable of handling consumer-scale transaction volumes, Monad’s high-performance design positions it as a compelling settlement and liquidity layer. Aave’s presence from the early stages of the ecosystem's growth would ensure that lending markets, collateral frameworks, and liquidity pools are natively embedded in the network's financial stack. Targeting a mid-late March deployment schedule, deploying Aave on Monad would: Establish Aave as the primary liquidity engine of the ecosystem Enable fintech and neobank partners to build on a robust, battle-tested lending protocol Capture early liquidity inflows from institutional and retail participants Support scalable, real-time financial products that benefit from Monad’s execution speed In this context, Aave is intended to serve as a foundational DeFi primitive powering credit, liquidity, and yield infrastructure across Monad’s high-performance ecosystem. Incentives Package Monad Foundation will provide the following within the first twelve months of the Aave Protocol activation proposal being executed: $15M USD in incentives measured at the block when ACI distributes rewards via MASIv infrastructure 10M units of GHO will be acquired and retained for more than 6-months whilst respecting considerations for managing operating capital The Aave DAO will provide the following within the first twelve months of the Aave Protocol activation proposal being executed: 0.50M units of GHO incentives to be distributed to support the growth and adoption of GHO on the Monad network The Monad Foundation reserves the right to determine whether and when to migrate to Aave v4 at a future date. Disclosure TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this TEMP CHECK, escalate this proposal to the Snapshot stage. 3. Publication of a standard ARFC, collect community & service providers' feedback before escalating the proposal to the ARFC snapshot stage. 4. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] Aave Will Win Framework --- 1. Summary Aave began with the thesis that decentralized lending could play a major role in traditional finance. Eight years later, that thesis has been validated. Aave is the largest protocol in decentralized finance, commanding a 60% market share in lending. The opportunity ahead, however, is bigger than anything behind us. Detailed below is a strategic framework proposal for Aave's next chapter. It asks the Aave DAO to ratify Aave V4 as the protocol's foundational technology for future growth. It also proposes to direct all revenue from Aave-branded products built to the DAO treasury and to establish a budget for continued development. It also includes a solution to protect the Aave brand. This proposal asks the DAO to approve the following operational framework: 1. Direct 100% of Aave-branded product revenue to the Aave DAO treasury. 2. Commit to a solution for protecting the Aave brand. 3. Ratify Aave V4 as the protocol's core technical foundation for future development. 4. Create a framework for the DAO to fund strategic growth and development. 2. Motivation The LEND token sale in 2017 raised $16M to build a decentralized lending protocol. That protocol became Aave, and that $16M has grown into a multi-billion dollar ecosystem, creating billions in value in the process. Along the way, Aave Labs has requested DAO funds only for direct protocol development and marketing activities. Everything else has been self-funded. This includes the product layer, which encompasses aave.com, the Aave mobile app, Aave Pro, Aave Kit, and Aave Horizon. It also includes legal and regulatory work such as SEC defense, brand protection, trademark management, and compliance. Business development and growth has been self-funded as well. We are now entering one of the most important periods that will determine Aave's success going forward. Fintechs are entering DeFi, institutions are coming onchain, and regulatory clarity is emerging in certain markets that allows us to go direct to consumers. The protocols that win the next decade will be those that move fast, build great tools and products, and capture new markets before competitors. With the right focus, and by investing in important growth areas, Aave is positioned to do exactly that. Other approaches to this framework exist, however they have different trade-offs. Aave Labs could operate independently and keep product revenue to fund itself, but then there would need to be a separation of the protocol revenues from the ones generated by the Aave-branded products built on top of the protocol. The DAO could directly build and operate Aave-branded products through governance, but the execution would be slow, and governance overhead can't scale indefinitely to meet the pace required. 3. Specification 100% Aave Product Revenue to the DAO The first ever Aave governance proposal, AIP-1, established that AAVE token holders govern the Aave Protocol, which has led to the DAO rightfully collecting 100% of protocol fees. And since the protocol’s launch, Aave Labs has operated aave.com, which became an important access point for most protocol usage across retail users, power users, and integrators. This has supported millions of users with zero security incidents. The DAO has matured quite a bit since AIP-1 and we believe it’s time to align behind a token-centric model. Under this proposal, 100% of Aave Labs' product revenue will go to the DAO. This includes: aave.com, the existing interface, and all associated fees Aave App, the consumer mobile application Aave Card, a card tied to Aave App with all fees flowing to the DAO Aave Pro, the new interface for Aave V4 Aave Kit, enterprise solutions for fintechs and institutions building on Aave Aave Horizon, Aave's RWA market and institutional services AAVE ETP, exchange traded product of $AAVE Upon approval of this proposal, the DAO would also receive revenue from the swap integration on aave.com, which currently generates approximately $10 million in annualized revenue. This integration is expected to expand to additional chains and functionality. Revenue is defined as gross product revenue earned by Aave Labs, minus any direct revenue sharing paid by Aave Labs to external partners including revenue rebates, revenue subsidies, revenue sharing arrangements and any additional direct user incentives. Product growth incentive budgets are funded by the Aave DAO. Additionally, Aave Labs retains the discretion to redirect a portion of product inflows, such as vault yields, directly into user incentives. Competing for users requires the ability to deploy capital quickly toward growth without waiting for a governance cycle. In these instances, Aave Labs will disclose additional user incentives spending in our quarterly updates. With proper execution, the product layer can be an additional source of revenue for the DAO treasury. Combined with protocol fees, the DAO can fund its own growth, security, and development from a diversified revenue stream. Expanding Revenue Through Aave V4 The product layer is one part of the path to increasing the DAO's annual revenue. The protocol layer, powered by Aave V4, is the other. Aave V3 already generates over $100 million in annualized revenue. Aave V4 expands on V3 with new monetization features that allow the protocol to capture more value from the risk it underwrites. V4’s architecture also unlocks revenue streams that are not easily possible in previous Aave versions. Each Spoke can extend Aave into a new market or use case, with its own risk parameters and revenue model. As with V3, 100% of Aave V4’s protocol revenue will go to the DAO. We’ve taken a look at various products and protocols across the crypto and fintech industries to show estimations that highlight the size of the opportunities available: These opportunity estimates are based on other protocols or products in each category (e.g. Pendle, Fluid), and the size of the opportunity (e.g. OTC lending volume), etc. They each represent a net new revenue opportunity on top of what Aave generates today, and they are only possible to pursue in a scalable way once V4 is live. Reaching these estimates would also depend on market conditions, scale of adoption, and execution. Aave V4 also introduces a new reinvestment module, which is an optional net new revenue opportunity for the DAO to consider. Aave pools maintain a significant idle float that currently earns nothing. This reinvestment feature allows the protocol to sweep this capital into short-term, low-risk yield opportunities pre-vetted and approved by the DAO, similar to a collateral listing. When Aave rates fall below SOFR-rates, it signals underutilized liquidity that could be productively deployed. Based on historical stablecoin float levels and a risk-free proxy SOFR-rate, the additional interest that would have been earned is substantial: Based on historical performance and idle liquidity. These figures are illustrative good faith estimates included to inform governance discussions around prioritization and resource allocation. They are not projections, commitments, or expectations, and actual outcomes may vary materially depending on governance choices, execution, adoption, and market conditions. This interest can be split between depositors and the DAO or whatever else the DAO decides. The analysis does not include other strategies such as ETH staking or reinvesting into higher-yield opportunities, which are also an option if the DAO chooses. Taken together, these opportunities illustrate the range of operational scale the DAO may need to support across both the protocol and product layers if adoption and market conditions warrant it. Viewed as an aggregate opportunity set, they suggest that the long-term revenue ceiling for the Aave ecosystem is materially higher than today. Ratification of Aave V4 Aave V3 has served the protocol well, but it is approaching its architectural limits. Adding new features to V3 requires modifying core protocol logic, which involves extensive audits and significant coordination overhead. Meanwhile V4’s architecture allows new functionality to be added through Spokes without touching the core, making experimentation cheaper, faster, and safer. Importantly, anything V3 does can be recreated on V4, but not vice versa. V4 is a strict superset of V3's capabilities, meaning no functionality is lost in the upgrade. V4’s architecture expands the range of revenue models the protocol can support, which is why governance analysis considers higher-scale revenue scenarios when planning long-term operations. To capture the opportunities outlined above, Aave Labs and the rest of the DAO’s service providers should coordinate development efforts around V4. This means prioritizing V4 Spoke development, aligning roadmaps, and shifting new feature work away from V3. Notably, V4 is already live on testnet, has completed an open security contest, and has its first public audit. The DAO is being asked to agree on this strategic direction and a separate proposal will follow for V4 protocol activation, the launch setup, etc. V3 Maintenance Plan That said, V3 should not be shut down hastily or haphazardly. V3 is stable, mature, and battle-tested. There is no need for a rushed, or forced, migration, and the transition should happen in three phases: 1. Active Development. V3 remains the primary production system, with security patches, parameter updates, and critical maintenance continuing as normal. It also makes sense to pause any new features for V3 if this framework is passed. 2. Stable Maintenance. V4 becomes the primary technology layer for expansion and innovation. V3 documentation, tooling, and access points remain fully supported, and users migrate at their own pace. 3. Legacy Support. Once V4 is mature, V3 parameters could be gradually adjusted to encourage migration, following the same approach used in past version transitions. V3 remains open indefinitely for withdrawals, with governance stepping in only for critical security issues. Note: As per the DAO’s feedback, the timeline for these phases can evolve organically or be decided in a different proposal. In the near term, V3 will run alongside V4 until further discussions are held by the DAO. That said, aligning the DAO behind V4 is important. If the DAO ratifies this strategic direction, coordination among service providers will be essential for efficient execution. Service providers funded by the DAO can align their work with this direction to maintain Aave's competitive position. Those who prefer to focus on different priorities can adjust their scope accordingly. Aave Brand Governance The Aave brand is one of the protocol’s most important assets, built over years of technical excellence, security track record, and community trust. Protecting it is in the best interest of the DAO, token holders, and the broader ecosystem. Today, Aave Labs is the exclusive legal owner of the Aave trademarks and has been solely responsible for holding, defending, and enforcing them. Because the DAO is not a legal entity, it cannot directly hold or defend trademarks. As a result, trademark stewardship has necessarily sat within Aave Labs. For the past seven years, Aave Labs has carried this operational burden, and the work is hands-on, expensive, and necessary. Trademarks that are not actively and consistently defended can be weakened or lost, reducing the ability to control how a mark is used in commerce and increasing the risk of misuse or confusion. At the same time, there are understandable concerns around concentrating long-term control of such a critical asset within a single operating entity, particularly as the DAO continues to mature. To address this, and subject to DAO approval, Aave Labs proposes the creation of a Foundation that would assume responsibility for holding and stewarding the Aave trademarks going forward. The Foundation would be mandated to protect the brand, license it to approved entities, address unauthorized use, and operate in alignment with DAO-approved parameters. The details regarding the structure, governance, and execution of this Foundation, including any transfer or licensing of trademark rights, as well as proposed approaches to V4 codebase licensing, will be presented to the DAO in a follow-up proposal. $AAVE Market Access To go beyond the product/protocol layer and expand market access to $AAVE, Aave Labs will support partners to launch regulated, traditional market products referencing $AAVE as the underlying asset. This includes the potential launch of $AAVE regulated futures, as well as a regulated spot exchange-traded product (ETP). The introduction of regulated futures and ETP products would represent a meaningful step toward institutional maturity for Aave, broadening access for professional and traditional investors. A standalone proposal covering structure and execution will follow under the workstreams authorized by this proposal. DAO Growth Requires Resources At Scale The operational framework outlined above requires execution at scale that matches the opportunity. For Aave to scale and play a role in the real financial system, it should allocate resources in growth the way fintechs, banks, and other financial institutions do. Without commitment to this as a goal, Aave's upside will always be limited. If all of Aave Labs’ product revenue flows to the DAO, the DAO would need to fund the ongoing development and growth of these products. Aave Labs Funding Request The DAO is facing a structural decision regarding Aave Labs’ operating model going forward. Currently, Aave Labs self-funds a significant portion of its operations. Historically, the ecosystem’s direction of travel (via AIP-1) was to use fees generated by Aave-branded products, such as aave.com and other product surfaces, to cover Aave Labs’ product development, marketing, legal, and operational costs, while the DAO funded direct protocol version development carried out by Aave Labs. Under the proposed operational framework, all fees from Aave-branded products would go to the DAO treasury rather than supporting Aave Labs’ operations and product development. In this configuration, the responsibility for funding Aave Labs’ activities would shift correspondingly to the DAO. Aave Labs requests $25 million in stablecoins, 75,000 AAVE, with additional growth and development grants payable upon specific product launches. The funding would be structured as follows: Primary Grant: - $5 million paid upfront upon approval of the proposal and $20 million streamed over the course of the year. - 75,000 AAVE delivered upon approval of the proposal, unlocking linearly monthly over a 2 year period Growth/Development Grants: - $5,000,000 for Aave App launch, with funds used for user acquisition, marketing, and ongoing development - $5,000,000 for Aave Pro launch, with funds used for user acquisition, marketing, and ongoing development - $5,000,000 for Aave Card launch, with funds used for user acquisition, marketing, and ongoing development - $2,500,000 for Aave Kit launch, with funds used for maintenance and marketing Note: For clarity, all funds will be spent on Aave-related efforts. Growth and development grants are released upon delivery and streamed over a period of six months, with governance confirming completion before funds are disbursed. They cover the cost of bringing each product to market, from engineering through go-to-market. Companies entering DeFi are well-capitalized and spending aggressively on product and distribution. To succeed in the market, Aave needs to invest at a similar scale. This commitment allows for long-term planning, aggressive hiring, and sustained investment in product and go-to-market without the friction of annual budget cycles. The funding requested is a significant expansion of scope beyond historical funding. To date, Aave Labs has largely self-funded the cost of building and scaling the product layer, seeking DAO support mainly for core protocol development and focused marketing. This proposal secures the investment needed to stay competitive and continue innovating over the next decade. Growing Aave and growing it to the scale of other TradFi alternatives requires stable, predictable funding so contributors can plan, hire, and execute at the standard of a global financial platform. Altogether, these funds are covering the following costs: Continued protocol development (V4 improvements, Spokes, core infrastructure, research, and development) Product engineering across Aave Pro, Aave App, Aave Kit, and other products Product go-to-market, user acquisition, marketing (e.g. social media/SEO/content) and growth Business development - Aave Labs invests heavily in partnering with the largest institutional and fintech names to integrate with Aave. - Aave Horizon asset onboarding and driving TVL/borrow growth. - Ongoing 360° resource provision for institutional integrators, including technical, InfoSec and operational support. Application security - Aave Labs runs an extensive monitoring program, and very heavy enterprise fees to social media platforms, to protect the Aave brand. Events, which historically Aave Labs has already run with funding from the DAO (e.g. rAAVE, DeFi Day) With this capital, Aave Labs can build with the runway needed to succeed on the items outlined above. It would also reflect the DAO’s decision to fund the level of execution required to support protocol operations at increased scale, should governance determine that expansion is warranted. In order to be as effective as possible, Aave Labs would retain autonomy over product strategy and operations. Building competitive products requires the ability to move quickly, make decisions without committee approval, and iterate based on market feedback. We suggest the same for other Service Providers who might choose to operate under this framework. The grants outlined above are for one year and would need to be revisited, if approved, 12 months after the proposal is decided on. In line with existing DAO practices, oversight of this work is exercised through governance. Aave Labs will provide regular transparency into its activities, including: Quarterly updates on progress against funded initiatives, key metrics, and use of DAO-authorized resources Ongoing updates on active workstreams and prioritization decisions Continued open and responsive communication with the DAO through established governance channels 4. Next Steps Aave remains early in its journey. What exists today is a base layer, while the real scale of adoption lies ahead as global finance moves onchain. DeFi is still quite small in the grand scheme of things. And over the coming decades, trillions of dollars in assets will migrate onto open rails. In that world, Aave can become the core infrastructure for global finance. Since 2017, the focus has been on disciplined execution at the frontier, and that conviction has only strengthened. The next phase of growth, fueled by innovation, and institutional adoption will be led by Aave. With sustained commitment and effective execution, the protocol can support significantly greater scale over time and continue establishing itself as core liquidity infrastructure for the onchain economy. This proposal seeks to establish a framework for Aave’s next decade. Upon approval, it would reaffirm Aave Labs’ alignment with the DAO by directing all Aave-branded product revenue to the DAO treasury. It asks for the ratification of V4 as the technical foundation for this growth and for the funding to execute this vision. This framework’s objective is to position the Aave Protocol as a core piece of global financial infrastructure, with the value it creates directed to the Aave DAO to fund its continued development and success. In accordance with Aave governance processes, this proposal is intended as an initial Temp Check to gather community feedback on the strategic direction outlined above. Any commitments, structural changes, or funding allocations would proceed through the appropriate stages of discussion, refinement, and governance proposal stages prior to implementation. If the Temp Check is successful and the community supports this proposal, we will move forward with a formal ARFC submission. Disclaimer Historically, Aave Labs has self-funded its endeavors. Due to the nature of the proposal, Aave Labs would receive funding from the DAO in exchange for Aave Labs' revenue going to the DAO if passed. No third parties co-authored this proposal. Copyright Copyright and related rights waived under Creative Commons Zero (CC0). FAQ 1. Why are so many significant items grouped into a single proposal? Shouldn't these be separate votes? This proposal presents a single, cohesive strategy. The components are interconnected and depend on each other for success. For example, aligning on V4 as the core technical foundation informs how development efforts are prioritized, while the proposed funding framework supports coordinated execution across protocol and product workstreams. Voting on these items separately could result in a fragmented and unworkable plan. Approving the strategy without the technology, or the technology without the funding to build it, would be inefficient. This proposal is a complete strategic package, and voting on it as a whole ensures the DAO is aligned on a single, comprehensive path forward. 2. The funding request is substantial. Why does Aave Labs need this budget? The requested budget reflects a deliberate shift in operating model rather than an incremental extension of past funding. Historically, Aave Labs subsidized a broad range of activities and requested DAO support primarily for direct protocol development and focused marketing. Under this framework, the DAO is choosing to fund a wider operational scope directly, including product engineering, go-to-market execution, product relevant legal and compliance work, and business development. This budget is intended to support long-term planning and execution at scale and to enable stable resourcing and sustained focus. It reflects a governance decision about how the DAO wishes to resource protocol-adjacent work as Aave engages more directly with an evolving and increasingly competitive market landscape. 3. Why should the DAO fund Aave Labs now if it has been self-funded for so long? By directing 100% of revenue to the DAO, Aave Labs will not be able to self-fund going forward. Without the ability to earn or raise revenue, there is no way to cover the costs across product development, business development, and other operational functions Aave Labs has historically funded. Without funding to continue this work these functions would stop. 4. Is this funding request annual? Yes. Aave Labs will submit an annual budget proposal to the DAO for the work it performs. Each year's budget requires a separate governance vote, giving the DAO ongoing oversight of how funds are allocated. 5. What does "autonomy" mean in this proposal? The proposal requests autonomy over certain operational and product strategy decisions. Building competitive products requires the ability to move quickly and iterate based on market feedback, which is difficult if every decision requires a vote. Accountability is central to this arrangement. Aave Labs commits to providing quarterly reports on progress, frequent updates on development, and continued open communication with the DAO. The DAO retains ultimate oversight through its control of the treasury and Aave Labs’ funding stream. If Aave Labs does not meet its commitments or perform effectively, the DAO can choose not to continue contributing to this budget. 6. What does ratifying V4 mean in this proposal? This vote asks the DAO to agree on a strategic direction. Ratifying V4 in this proposal means committing to it as the core technical foundation for future development. It signals to all service providers that V4 is the priority, allowing them to align their roadmaps and development efforts. This coordination is necessary to build the features that will achieve the proposal's goals. The subsequent vote to activate the V4 protocol will be a purely technical one, focused on the readiness of the code, launch parameters, etc. 7. Why is there compensation tied to milestones? Launching and scaling products involves costs beyond core development work. This includes go-to-market execution, partnership development, and ongoing operational support around the time a product is introduced. The milestone-based payments are intended to support these activities at key delivery points, aligning resourcing with product rollout. As all revenue from these products flows to the DAO, funding this work supports execution that directly contributes to the protocol’s operational sustainability. 8. How does this framework impact other Service Providers working with the Aave DAO? If the DAO ratifies this proposal, coordination among service providers will be important for efficient execution. Service providers funded by the DAO can align their work with this direction to maintain Aave's competitive position. Those who prefer to focus on different priorities can propose adjusting their scope accordingly. Additionally, the increased surface area for revenue generation established by this proposal creates a framework that other service providers can consider for their own work with the DAO.

Summary Proposal for the pre-approval of Aave v3.7, to authorise security procedures before the final on-chain AIP activation vote. As extra clarification, this approval only confirms a candidate set of features and changes, whose scope can only be reduced in AIP stage, not increased unless for bug fixing on production problems. The candidate changes/features are the following: Simplification of eModes’ configuration, adding an isolated flag. Removal of isolated collaterals and borrowable in isolation, features not useful anymore. Removal of the L2 sequencer oracle. Explicit removal of the flow to drop reserves, making the reserves list append-only. Small improvements on liquidation calculations. Multiple improvements/simplifications (not on-chain) of the codebase peripheral infrastructure. Context On previous upgrades (v3.4/5, v3.6), we have commented with the community that, while future upgrades should not be categorically discarded, they will naturally be much smaller than previous ones, focusing on surgical changes and simplification oriented toward maintainability. v3.7 follows exactly that approach, being a smaller upgrade from code size and invasiveness perspective, and focusing on simplifying the protocol to its current and envisioned usage. We believe this is an important upgrade to reduce unnecessary maintenance overhead and modelling work. Especially considering that Aave will have three production protocols running in parallel very soon, with the upcoming v4. Aave v3.7 changes 1. eMode isolated configuration Adding a new bool isolated flag on eMode categories, that when isolated = true: Only assets explicitly listed in the eMode's collateralBitmap contribute LTV. All other assets the user has supplied are treated as LTV-zero (they still contribute to the liquidation threshold and health factor, but cannot back new borrows). Users with non-eMode collateral enabled cannot enter the isolated eMode — entry is blocked because those assets would become LTV-zero. Users already inside an isolated eMode cannot enable non-eMode assets as collateral. → Motivation for the change In the current version of Aave (v3.6), eMode categories define a collateralBitmap that determines which assets receive the eMode's enhanced LTV/LT parameters. However, assets outside the bitmap still contribute their regular (non-eMode) LTV. This means a user in an "ETH-correlated" eMode could still borrow against non-ETH collateral at the asset's base LTV, defeating the purpose of the eMode's risk isolation. The workaround in v3.6 is for governance to manually set ltvzeroBitmap bits for every non-eMode asset. Even if very explicit and functional, this is operationally burdensome: it requires an LTV0 of multiple assets on listing. The isolated flag solves this by automatically treating all assets outside the collateralBitmap as LTV-zero, removing the need for per-asset manual maintenance (but still allowing granularity via LTV0 on eMode). --- 2. Removal of isolated collateral/borrowable in isolation configurations Aave v3.7 removes two configuration features introduced on v3.0: 1. Isolation Mode - Restricts users to a single collateral asset with a debt ceiling and limited borrowable assets 2. Siloed Borrowing - Prevents users from borrowing multiple assets if one was marked as siloed → Motivation for the change No current need for those modes. - Siloed borrowing: never actively used in production. - Isolated collateral: very few assets configured with debt ceilings (across all networks, the majority of assets in isolation are LTV0), and no real need to do so by risk teams going forward, versus other mechanisms. v3.6 (and v3.7 isolated eMode) introduces simpler mechanisms to achieve similar control. E.g., siloed borrowing can be achieved reproduced using borrowing enabled/disabled on eModes, while collateral isolation can be achieved in a similar way with eModes. v3 codebase complexity reduction. Simplifies in a very non-invasive way multiple components of the protocol, using the validation logic where the main change resides. This translates into simpler auditability/maintainability and reduces the overall attack surface. Simplifies the reasoning model and configuration levers for risk and growth providers. --- 3. Removal of L2 sequencer uptime oracle This feature was used on some of the L2 deployments to check whether the L2 sequencer was online, and enforce a grace period to users after recovery, with the following: Borrowing was blocked while the sequencer was down or the grace period had not elapsed (isBorrowAllowed()). Liquidations were blocked under the same conditions (isLiquidationAllowed()), with a special exception: liquidations were always permitted when a position's health factor fell below MINIMUMHEALTHFACTORLIQUIDATIONTHRESHOLD (0.95), regardless of sentinel status. Both checks are removed. Borrows and liquidations now proceed without sequencer uptime gating. → Motivation for the change Historically, sequencer uptime detection on L2s has been very ad-hoc, with each network having different mechanisms and reliability characteristics for reporting sequencer status. This lack of standardisation led to infrastructure differences across deployments/chains, hence to high-maintenance overhead both on the Aave side and middleware like Chainlink, and to false positives. That is very problematic to the system because false positives can, in the worst case: Block liquidations: allowed unhealthy positions to deteriorate further, increasing protocol risk during the exact moments when liquidations were most needed. Block borrows: prevent normal user activity during periods where there was not really any issue on the network. In summary, our evaluation of risk versus value tells us that the right decision is to remove the mechanism, which, similar to other changes included in this v3.7, improves simplicity and auditability, while reducing the attack surface. --- 4. Removal of drop reserve flow This includes the dropReserve() methods from both PoolConfigurator and Pool contracts, and logic directly related to those. However, we keep untouched some (now redundant) validations across the codebase, as they really have no impact, but reduce the changes surface. → Motivation for the change The functionality to drop reserves has never been used, and there is no plan to do so. Also, we know it should enforce extra validations that are not currently in the code, and that we will not approve a governance proposal to use it without a deep review of the flow and security procedures. So factually, it is a non-active/deprecated part of the code, which we are making more explicit. This also adds value from the same angle as other features in this v3.7: simplification, as now the list of reserves will be append-only. --- 5. Small precision improvements on liquidation Post v3.5 (adding directional rounding to the protocol), we detected some minor part of the protocol logic on liquidation that could be improved even further in terms of rounding, without being too invasive. These are included in this v3.7 proposal, with details to be disclosed once we finish our internal development/security evaluations. → Motivation for the change Improving the precision of the math in the protocol. --- 6. Misc simplifications In parallel with (and outside of) numbered releases of Aave (but async to them), we do different maintenance tasks on non-core protocol components in the Aave v3 Origin repository. Aside from other minor changes, we have been doing the following high-level changes since the v3.6 release. Some non-invasive dependencies cleanup. Archival from v3 Origin of the Paraswap adapters, not used anymore in production. Archival of the RevenueSplitter contract, not currently used. Simplification of the V3 ConfigEngine. → Motivation for the change General simplification of the Aave v3 Origin repository, to reduce global compilation time or reduce inconsistency on dependencies. Basically, a continuous improvement of maintainability.

Summary Umbrella makes deficit handling explicit and mechanically enforceable. Once a reserve deficit is realized on-chain, the protocol applies a senior, DAO-backed first-loss layer (the deficitOffset) before any impairment is passed through to Umbrella stakers. Conceptually, the deficitOffset is the protocol’s equity buffer: it is the amount of realized loss the DAO is willing to absorb in that reserve before invoking the backstop. The core issue is not the existence of this equity layer, but its calibration. Today, deficitOffset is not systematically linked to the protocol’s own realized upside from the same liquidation machinery that occasionally generates deficits. This disconnect is notable because liquidation recapture has never been intended as “free revenue” in isolation. Protocol liquidation fees and, more recently, SVR, have always served a dual purpose: they are mechanisms through which the protocol internalizes part of the liquidation surplus, not only to align incentives, but also to strengthen the system’s ability to absorb future losses. In other words, liquidation-linked profitability has always been conceptually part of the protocol’s security and coverage loop; an earnings stream meant to reinforce resilience over time. This paper proposes a Risk Oracle that updates deficitOffset per reserve as a function of realized liquidation-linked recapture, specifically liquidation protocol fees and SVR, attributed to the debt reserve whose positions are being unwound. The objective is to convert realized liquidation profitability into continuously “earned” first-loss capacity, rather than treating deficitOffset as a static governance parameter that can drift away from the protocol’s actual earnings power and incentive intent. Motivation Aave liquidations are often discussed as a pure solvency mechanism, but economically, they function as a decentralized execution engine. The protocol effectively delegates liquidation execution to third parties through a liquidation bonus, and in return, the system obtains two meaningful forms of realized value: protocol-level liquidation fees and value recaptured through SVR. In aggregate, liquidation activity therefore exhibits a familiar risk-return structure: frequent, generally positive cash flows punctuated by rare tail losses when liquidation is incomplete, delayed, or occurs under adverse microstructure. Umbrella changes the allocation of those tail outcomes. Deficits, once realized, can immediately translate into slashing unless buffered by deficitOffset. Meanwhile, the positive cash flows generated during the same regimes accrue to the DAO treasury. Over time, this can create a skewed payoff profile: the treasury retains most of the “upside” from liquidation activity, while Umbrella participants are positioned as the primary absorbers of the downside from the liquidation tail. The deficitOffset layer is intended to mitigate exactly this problem by placing an equity buffer ahead of the stakers. But if deficitOffset is not responsive to realized earnings from liquidation activity, it may understate the DAO’s effective capacity to absorb moderate losses, leading to slashing in regimes where the protocol is net-profitable and where a more coherent risk-sharing arrangement would have funded the loss through retained liquidation earnings. Empirical intuition The misalignment becomes most visible during stress events, when liquidation volumes surge and the protocol simultaneously experiences both “wins” and “losses.” During the October 10th, 2025 market dislocation, long-tailed collateralized debt positions produced reserve deficits of approximately $10K in USDT, $22K in USDC, and $18K in WETH, with an aggregate deficit of around $500K across all reserves (primarily CRV and ENS). Over the same period, the DAO generated roughly $1M in liquidation fees and approximately $1M in SVR-related recapture stemming from $180M in aggregate liquidation volume, implying roughly $1.5M in net profit. The system was highly economically profitable, yet the deficits produced exactly the type of realized loss that can mechanically propagate into Umbrella slashing if the deficitOffset buffers are not sized to reflect that profitability. The result is a counterintuitive allocation: the engine generates surplus in aggregate, but the backstop tranche can still be asked to absorb the loss leg of the same regime. A similar pattern occurred in the BAL crash on February 2nd, 2026, when BAL experienced a rapid price collapse and large fractions of the frozen reserve were offloaded, resulting in a $28K USDC deficit, climbing its currentDeficit value to $51K; just $50K less than the configured Deficit offset. In that same window, BAL-specific liquidations generated roughly $15K in liquidation fees, and aggregate liquidation-linked recapture across recent days with USDC debt was close to $1M. Again, a single volatility regime produced both meaningful realized upside to the DAO and a localized realized loss that can be charged to Umbrella unless adequately buffered. !image - 2026-02-04T195708.202.png USDC Deficit Accrual over time These episodes suggest a general principle: if Umbrella is the mechanism-level absorber of deficits in a given debt reserve, the equity buffer in front of Umbrella should evolve with the realized cash flows generated by liquidating that same debt reserve across regimes. Since the launch of Umbrella, USDC and USDT reserves are effectively responsible for generating 95% of liquidation-related revenue on Ethereum, at $4.9M and $5.9M respectively, or rather $3.3M and $4.2M when adjusting for SVR’s denomination in WETH and the associated collateral assets via liquidationProtocolFee. [grid] !output - 2026-02-03T211438.221 (3).png !output - 2026-02-03T205444.208 (3).png [/grid] Attribution nuance: multi-debt positions and separating “revenue generation” from “loss realization” The ambiguous case is a cross-margined borrower with multiple Umbrella-covered debt assets. Consider an account with USDC and WETH debt. Liquidators may repay USDC first because it is operationally cheaper or more liquid to source, while WETH ends up realizing the deficit because collateral continues to decline after the initial liquidation. A naïve fairness argument would suggest that liquidation-linked recapture should be credited to the reserve that ultimately experiences the deficit (here, WETH), since that is the reserve whose backstop capital is eventually impaired. This quantification intentionally does not implement that mapping. The primary objective is not to allocate revenue according to the realized “loss leg” of a particular liquidation path; it is to systematically reinvest liquidation-derived upside into first-loss capacity using a rule that is observable, stable, and aligned with the mechanism that generated the revenue. The most defensible primitive is the liquidation event itself: liquidation-linked recapture is produced at the moment debt is repaid, and positions are unwound, and that action is parameterized by the debt asset that is being repaid. Crediting revenue to the repaid debt asset, therefore, follows the causal structure of the process that generates the cash flow. There is also a substantive economic argument for this choice in multi-debt accounts. When a liquidator repays one portion of a debt stack (e.g., USDC), the account’s leverage and liquidation risk are reduced. That reduction is path-dependent: it changes the subsequent evolution of the position under further price moves, and in expectation it reduces the magnitude of future deficits that could otherwise arise across the remaining debt stack. In the USDC/WETH example, the USDC liquidation is not merely “a liquidation that happened before WETH went bad”; it is an intervention that likely prevented worse outcomes by deleveraging earlier. Under that interpretation, it is coherent that liquidation profitability realized through repaying USDC contributes to building USDC’s equity buffer, because USDC liquidations are precisely the actions that systematically reduce insolvency risk and produce protocol revenue in that reserve. For these reasons, the specification uses a simple, event-driven accounting convention: liquidation-linked recapture is credited to the debt reserve that is repaid in the liquidation event, and reinvestment is expressed as growth in that reserve’s deficitOffset. Deficits, meanwhile, are handled where they occur: reserves that realize deficits consume their offset capacity accordingly. What deficitOffset should represent in a mature Umbrella design DeficitOffset is already the correct abstraction: it is a reserve-specific equity tranche that determines how much first loss the DAO absorbs before passing losses to backstop capital. The missing component is the “capital formation” logic. In a well-aligned system, deficitOffset should represent a conservative estimate of the reserve’s accumulated, realized capacity to absorb losses and the capacity directly funded by liquidation-linked earnings during profitable periods. This proposal reframes deficitOffset as a parameter that should be earned and maintained, rather than merely set. When liquidation activity generates meaningful net revenue for a debt reserve, a portion of that revenue should be converted into additional first-loss capacity for that same reserve. When liquidation revenue is weak, uncertain, or absent, deficitOffset should grow more slowly and remain conservative. This produces an equity layer that is endogenous to realized protocol economics, and therefore better aligned with the actual distribution of risks borne by Umbrella stakers. Proposed Risk Oracle: revenue-indexed deficitOffset per debt reserve The oracle continuously tracks realized liquidation-linked revenue and uses it to update deficitOffset per reserve. The accounting stance is intentionally simple: deficitOffset should be derived from a conservative measure of recent realized liquidation earnings, adjusted downward when the DAO actually spends that equity layer to cover deficits. The revenue inputs are: Liquidation protocol fees. These are mechanically collected as part of liquidation flows and routed to protocol-controlled accounting. Even if the fee is collected on the collateral side, the economic driver is the liquidation of a debt position. If repaying and unwinding debt in a given reserve systematically generates fee revenue for the protocol, that reserve should accumulate more first-loss capacity ahead of its Umbrella stakers. SVR revenue. SVR is explicitly a liquidation-adjacent revenue stream that exists because the protocol produces time-sensitive liquidation opportunities and uses oracle infrastructure; absent recapture, that value tends to leak externally. When SVR revenue is realized in liquidation-heavy regimes, it is economically appropriate to treat it as part of the same liquidation-linked earnings base that can fund equity capacity. The output is expressed in the reserve’s underlying units, consistent with how deficits and slashing are accounted for in Umbrella. Design and guardrails The goal is not to maximize deficitOffset with respect to reserve revenue, but to keep it economically defensible and operationally safe. The oracle is intentionally simple: it observes and aggregates realized liquidation-linked revenue attributable to a given reserve, defined as the debt asset being repaid, across two sources: liquidation protocol fees and SVR revenue. It then applies a conservative “reinvestment” factor (e.g., 30%) and uses that to incrementally increase the reserve’s deficitOffset on a periodic schedule. Importantly, while deficitOffset is expressed in the debt asset’s units, liquidation-linked revenue is realized in different units: liquidation protocol fees are collected from the collateral side of liquidations, and SVR proceeds are realized in WETH regardless of the debt asset that was repaid. Converting these revenue streams into a debt-asset-equivalent buffer can introduce measurement noise and, therefore, requires an optimized valuation scheme. For instance, when aggregating revenue with respect to the current collateral/WETH price, compared to the liquidation-reported collateral/WETH price, underlying revenues in dollar terms are 33% and 29% lower for USDC and USDT, respectively, given the underlying delta risk employed. The “meaning” of those revenues as future deficit coverage capacity depends on the treasury’s instantaneous risk posture. The DAO does not hold a purely stable-denominated treasury; it holds a mix of stables and volatile assets. As a result, the effective amount of liquidation-linked revenue that can be credibly treated as first-loss capacity for a stable-denominated deficit depends on the delta the treasury is currently running, i.e., how exposed it is to ETH/BTC price moves relative to what is already stable. For that reason, the oracle does not treat revenue denomination as a simple spot conversion. Instead, it explicitly conditions the credited value of liquidation-linked revenue on the treasury’s current asset distribution by maintaining an effective delta profile in BTC and WETH derived from observed holdings (~0.5). Liquidation-linked revenues are then valued through that lens: the oracle values the portion of revenue that is effectively “stable-equivalent” given the treasury’s current delta, and uses that adjusted amount to drive deficitOffset denomination, and thus growth. This makes the buffer calibration consistent with the DAO’s actual capacity to absorb future deficits under its prevailing balance-sheet exposure, rather than assuming away conversion and mark-to-market risk. The following plot portrays this effective growth in deficit offset for USDC and USDT subject to the constraints and valuation techniques expressed above: !output - 2026-02-04T133123.394 (2).png On the contrary, assets such as WETH and GHO exhibit materially lower effective revenue from liquidation events, and, as such, expected deficit offset growth will be smaller. From GHO’s perspective, the underlying reserve itself is considerably smaller, thus in relative terms the scaling of deficit offset should somewhat align with observed USDC and USDT behavior, while for WETH, the underlying risks stemming from uncorrelated collateralized WETH debt positions are materially smaller than that of USDC and USDT given the absolute demand differences, and alternatively liquidations stemming from hypothetical slashing events can induce considerable effective deficit offset growth in this sense. !output - 2026-02-04T172130.027 (1).png Rather than reacting to individual events, the oracle calculates revenue over a rolling window and only applies parameter changes every few days. On-chain constraints provide the primary safety rails: a maximum per-update, per-reserve delta bounds how much deficitOffset can move in a single change, and a timelock/cooldown ensures updates cannot be executed more frequently than the configured interval. Finally, the mechanism explicitly handles “consumption” of the equity layer. If the DAO ends up covering a realized deficit through the deficitOffset path (i.e., treasury funds are used to repay the offset-layer deficit), the reserve’s deficitOffset is not treated as permanently accumulated. Instead, the parameter reverts (or resets) to a baseline level specified in the associated governance configuration, reflecting the fact that the offset capacity has been utilized and should not be double-counted as continuing first-loss protection. Why this improves Umbrella’s long-run incentive structure This mechanism strengthens Umbrella’s economic legibility by tying realized liquidation upside to the equity buffer that sits ahead of stakers. Slashing remains the correct tool for large losses. The improvement is that the protocol’s realized liquidation upside is no longer disconnected from the equity buffer that is explicitly meant to protect stakers from moderate, regime-linked deficits. Over time, reserves that reliably generate liquidation-linked earnings will mechanically accumulate more first-loss capacity. That makes Umbrella positions in those reserves safer in a principled way: not because risks have disappeared, but because the protocol has consistently generated and retained earnings that can fund first loss. In turn, a stronger, earned equity layer should support more stable participation, improve coverage durability, and reduce the frequency of slashing events that are difficult to justify when the protocol is net-profitable through the same liquidation regimes that produced the deficit. In short, the oracle converts liquidation profitability into reserve-level capital formation ahead of Umbrella. It aligns the distribution of liquidation “wins” and “losses” with the hierarchy Umbrella already encodes, using a conservative feedback rule that is transparent, auditable, and amenable to governance oversight. Near-term parameter action Independent of the long-run oracle policy, current conditions argue for a near-term normalization of deficit offsets on the largest stablecoin debt reserves. Since Umbrella went live, USDC and USDT have been material contributors to protocol revenue through liquidation-linked activity, accounting for 95% of such revenue. Yet the currently configured deficit offsets on these reserves remain relatively low compared to (i) the scale of liquidation-linked revenues they have generated and (ii) the practical role the offset is meant to play as the DAO’s first-loss layer ahead of stakers. In that context, the present configuration risks forcing Umbrella to absorb losses on deficits that are economically small relative to the surplus the protocol has already accumulated from the same liquidation engine. A pragmatic step is therefore to increase deficit offsets to a higher, more representative level, such that the equity layer meaningfully reflects current protocol earnings capacity and reduces the likelihood of repeated “small-to-mid” slashing episodes in liquidation-heavy regimes. This does not remove slashing as a backstop for severe tail outcomes; it simply ensures that the system’s senior buffer is sized commensurate with the reserve’s demonstrated profitability and the DAO’s balance-sheet intent. Under the revenue quantifications outlined above, that maps naturally to the following concrete offset targets. | Reserve | Instance | Current Deficit Offset | Recommended Deficit Offset | | --- | --- | --- | --- | | USDC | Ethereum Core | 100,000 | 1,300,000 | | USDT | Ethereum Core | 100,000 | 1,600,000 | | WETH | Ethereum Core | 50 | 77 | | GHO | Ethereum Core | 100,000 | 115,000 | In parallel, the DAO should clear the currently outstanding deficits through the offset path via the steward, so that the reserves return to a clean baseline before the oracle-driven regime is introduced. Concretely, this entails covering the following realized deficits: | Reserve | Instance | Current Deficit | Current Deficit ($) | | --- | --- | --- | --- | | USDT | Ethereum Core | 10,134 | 10,134 | | USDC | Ethereum Core | 51,185 | 51,185 | | WETH | Ethereum Core | 8.1 | 18,320 | | CRV | Ethereum Core | 394,356 | 111,980 | | ENS | Ethereum Core | 5,768 | 39,400 | Once cleared and offsets are raised, the proposed revenue-indexed oracle can operate from a stable reference point, with subsequent offset growth reflecting ongoing realized liquidation-linked revenue and consumption reflecting future deficit-offset usage. Disclosure Chaos Labs has not been compensated by any third party for publishing this proposal. Copyright Copyright and related rights waived via CC0.

Title: [ARFC ADDENDUM] Mandatory Disclosures and Conflict-of-Interest Voting Norms Author: ACI (Aave Chan Initiative) Date: 2026-02-03 --- Summary This ARFC addendum proposes a governance-framework update to strengthen transparency and conflict-of-interest (COI) norms across Aave governance. It introduces: Mandatory disclosures for any participant currently receiving, or who has previously received, compensation from the Aave DAO, as well as any candidate seeking compensation. A clear statement that COI voting restrictions cannot be enforced onchain, and should instead be treated as a social-contract norm. A universal expectation of ethical abstention on matters where a voter has a material COI. Motivation Aave governance relies on credible neutrality, informed participation, and trust in process. As the DAO grows, the number of compensated contributors and service providers increases, which is healthy. However, without clear, consistent disclosure and COI norms, governance can drift into perceived capture or legitimacy debates that harm the DAO, the protocol, and the $AAVE token. Valuation models apply a discount to uncertainty. Clear disclosure and COI norms reduce that uncertainty by improving transparency, accountability, and the perceived legitimacy of outcomes. Specification 1. Mandatory disclosure requirements Disclosure is mandatory for: Any individual or entity with an active compensation stream from the Aave DAO. Any individual or entity that has received compensation from the Aave DAO in the past. Any individual or entity applying to be compensated by the Aave DAO, including as an author, co-author, or beneficiary of a proposal. Disclosures must be provided in: 1. the forum profile disclosure field (delegate profile), and/or 2. a dedicated service provider presentation thread (or equivalent standardized location), and 3. an explicit “Disclosure” section in any ARFC, TEMP CHECK, Snapshot, or AIP the disclosing party authors, co-authors, or materially benefits from. Minimum disclosure content: Entity or role (delegate, service provider, contributor) Nature of compensation (stream, grant, retroactive, consulting) Status (active or past) Relevant scope (workstream or mandate) Address disclosure (voting power only) Any entity or individual must publicly disclose all addresses under their control that hold Aave voting power or receive delegated Aave voting power. For privacy and safety reasons, addresses that hold $AAVE but do not carry voting power (i.e., all voting power delegated to a third-party address) are out of scope. Recommended standardized disclosure sentence: “Disclosure: I currently receive, or have previously received, compensation from the Aave DAO via [stream/grant/contract], related to [scope]. Voting power addresses under my control: [0x…], [0x…].” 2. COI voting restrictions are social, not onchain COI voting restrictions cannot be reliably enforced at the onchain voting level. Any attempt to encode broad COI restrictions at the protocol layer is likely to introduce complexity, edge cases, and enforcement ambiguity that creates more issues than it solves. Therefore, COI voting restrictions should be treated as a social contract rule: Delegates and voters are expected to follow ethical abstention norms. The community is encouraged to treat votes cast under material COI as lacking legitimacy from an ethical standpoint, even though they remain technically valid onchain. The community, delegates and voters are invited to use their voting power to counteract restrictions violation 3. Ethical abstention due to COI should be universal Ethical abstention is a baseline governance norm. It applies universally whenever a voter has a material conflict of interest, regardless of topic, author, or outcome. A material conflict of interest includes, but is not limited to: Any direct or indirect financial exposure that could be meaningfully affected by the vote (streams, grants, fees, revenue share, equity, token arrangements, or contingent compensation). Any employment, advisory role, mandate, or contractual relationship with an entity materially impacted by the decision. Any situation where the voter receives a non-trivial private benefit from the outcome that is not broadly shared by $AAVE token holders. Expectation: If a voter has a material conflict of interest, they MUST not cast a YAE or NAY vote, ABSTAIN votes cast are tolerated. If they do vote YAE or NAY anyway, that vote does not count under this framework. It must be treated as invalid for legitimacy purposes and excluded from any community-recognized “clean” tally, quorum or outcome assessment, even if excluding it would change the result. For AIPs, if a voter has a material conflict of interest, they MUST not cast a vote. 4. Proposal power should not be restricted This addendum does not propose restricting proposal power. Rationale: Proposal power is necessary for executing work, coordinating upgrades, and progressing governance. The neutrality concern is primarily about voting outcomes under COI, not about enabling proposals to be drafted and discussed or created. Restricting proposal power would increase operational friction and reduce execution throughput. 5. Implementation and enforcement approach Implementation is procedural and forum-based: Improve “Disclosure” expectation to the governance posting templates for ARFCs, TEMP CHECKs, and Snapshot threads. Encourage delegates and service providers to maintain up-to-date profile disclosures. Moderation must remind participants of missing disclosures. Disclaimer ACI is a service provider to the Aave DAO and is compensated for its mandates. This addendum is presented in the interest of improving governance legitimacy, transparency, and durable alignment. Next Steps 1. Publish a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC Addendum Snapshot, 2. If the ARFC snapshot outcome is YAE, proposal will be canon.

[ARFC] Focussing the Aave V3 Multichain Strategy - Phase 1 Author: ACI Date: 29/01/2026 Summary This ARFC is the continuation of TEMP CHECK Focussing the Aave V3 Multichain Strategy , after successfully passed the TC Snapshot. The proposal plans to provide an execute a multichain strategy for Aave V3 that will freeze the following networks, as a start: 1. zkSync 2. Metis 3. Soneium This proposal sets to reduce operational overhead and governance burden by addressing instances that are clearly non viable today. Motivation Aave V3 maintains multiple live deployments across different networks, each of which introduces: Ongoing operational and monitoring requirements Governance overhead for parameter updates and asset maintenance Risk surface area, even when usage is minimal Over time, it has become clear that a small subset of instances contributes very little user activity, TVL, and revenue, while still requiring a non-trivial amount of attention from service providers and governance participants. The zkSync, Metis, and Soneium deployments fall firmly into this category. These instances exhibit: Low and persistent usage No signs of organic growth No credible short-term path to becoming meaningful contributors to the Aave ecosystem Continuing to operate these markets in their current state provides little upside while consuming attention better spent elsewhere. Policy for Future Aave V3 Deployments We would like to highlight the significant value an Aave deployment provides to a new chain. As the largest DeFi protocol, the value and stimulating effect on the onchain ecosystem that a properly planned Aave deployment can bring is significant. The work involved in a deployment and the substantial ongoing effort from service providers and governance participants has at times been under appreciated, yet in light of the above revenue numbers we must bring this back into focus. The upfront and recurring costs mean the DAO must prioritize deployments that generate sufficient revenue to justify the time and risk involved. We therefore propose that for any new Aave deployment the chain on which we are deploying guarantees a revenue floor of $2m per annum for all new deployments. Conclusion We believe that the above remediation measures will help to focus the DAO on high revenue opportunities, ensure Aave shares in upside from successful instance deployments, reduce the number of low value deployments going forward, ensure that Aave is fairly compensated for the value it brings to our partners, and reduce risk and operational overhead by offboarding poor performing instances. Disclaimer ACI is not presenting this proposal on behalf of any third party and is not compensated for creating this proposal. Next Steps 1. Publish a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. 2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via CC0.

[ARFC] Deploy Aave V3 to MegaETH Summary We are reopening the ARFC to deploy Aave V3 on MegaETH with updated terms and parameters to be defined by Risk SPs. The original thread established that MegaETH is an EVM-compatible, real-time L2 still finalizing core infra, including Chainlink oracles. As progression has been made, and the upcoming launch of MegaETH’s Mainnet approaches, the DAO should consider preparing an Aave V3 MegaETH deployment. Motivation Launching on MegaETH at Day 0 positions the protocol to capture the network’s earliest activity and convert it into meaningful supply and borrowing demand. Incentives distributed under governance-defined KPIs give the DAO a direct lever to tie rewards to behaviors that increase protocol revenue. The MegaETH deployment is a material revenue opportunity for the DAO, with early traction, deep liquidity, and strong utilization that can support strong revenue streams. Specifications Aave will be live on MegaETH at mainnet Day 0. The initial token listing and parameters have been updated based on the latest risk analyses. | Parameters | Value | Value | Value | Value | Value | Value | Value | | :---- | :---- | :---- | :---- | :---- | :---- | :---- | :---- | | Asset | WETH | BTC.b | USDT0 | USDM | wstETH | wrsETH | ezETH | | Isolation mode | No | No | No | No | No | No | No | | Borrowable | No | No | Yes | Yes | No | No | No | | Collateral Enabled | No | No | No | No | No | No | No | | Supply Cap | 50,000 | 120 | 50,000,000 | 50,000,000 | 12,000 | 10,000 | 10,000 | | Borrow Cap | 46,000 | - | 46,000,000 | 46,000,000 | - | - | - | | Debt Ceiling | - | - | - | - | - | - | - | | LTV | - | - | - | - | - | - | - | | LT | - | - | - | - | - | - | - | | Liquidation Bonus | - | - | - | - | - | - | - | | Liquidation Protocol Fee | 10% | 10% | 10% | 10% | 10% | 10% | 10% | | Variable Base | 0.0% | - | 0.0% | 0.0% | - | - | - | | Variable Slope1 | 2.50% | - | 5.0% | 5.0% | - | - | - | | Variable Slope2 | 8.00% | - | 10.0% | 10.0% | - | - | - | | Uoptimal | 90.0% | - | 90.0% | 90.0% | - | - | - | | Reserve Factor | 15% | - | 10% | 10% | - | - | - | | Stable Borrowing | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | | Flashloanable | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | Siloed Borrowing | No | No | No | No | No | No | No | | Borrowable in Isolation | No | No | Yes | Yes | No | No | No | | E-Mode | WETH/Stablecoins, wstETH/WETH, wrsETH/WETH, ezETH/WETH | BTC.b/Stablecoins | wstETH/Stablecoins, WETH/Stablecoins, BTC.b/Stablecoins | wstETH/Stablecoins, WETH/Stablecoins, BTC.b/Stablecoins | wstETH/WETH, wstETH/Stablecoins | wrsETH/WETH | ezETH/WETH | E-Mode Configurations WETH Stablecoins #1 | Parameter | Value | Value | Value | | :---- | :---- | :---- | :---- | | Asset | WETH | USDT0 | USDM | | Collateral | Yes | No | No | | Borrowable | No | Yes | Yes | | Max LTV | 80.50% | - | - | | Liquidation Threshold | 83.00% | - | - | | Liquidation Bonus | 5.50% | - | - | BTC.b Stablecoins #2 | Parameter | Value | Value | Value | | :---- | :---- | :---- | :---- | | Asset | BTC.b | USDT0 | USDM | | Collateral | Yes | No | No | | Borrowable | No | Yes | Yes | | Max LTV | 70.00% | - | - | | Liquidation Threshold | 75.00% | - | - | | Liquidation Bonus | 6.50% | - | - | wstETH Stablecoins #3 | Parameter | Value | Value | Value | | :---- | :---- | :---- | :---- | | Asset | wstETH | USDT0 | USDM | | Collateral | Yes | No | No | | Borrowable | No | Yes | Yes | | Max LTV | 75.00% | - | - | | Liquidation Threshold | 79.00% | - | - | | Liquidation Bonus | 6.50% | - | - | wstETH Correlated #4 | Parameter | Value | Value | | :---- | :---- | :---- | | Asset | wstETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 94.00% | - | | Liquidation Threshold | 96.00% | - | | Liquidation Bonus | 1.00% | - | wrsETH Correlated #5 | Parameter | Value | Value | | :---- | :---- | :---- | | Asset | wrsETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Bonus | 1.00% | - | ezETH Correlated #6 | Parameter | Value | Value | | :---- | :---- | :---- | | Asset | wrsETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Bonus | 1.00% | - | CAPO | Asset | maxYearlyRatioGrowthPercent | ratioReferenceTime | MINIMUMSNAPSHOTDELAY | | :---- | :---- | :---- | :---- | | wstETH | 9.68% | Monthly | 7 | | wrsETH | 6.67% | Monthly | 14 | | ezETH | 10.89% | Monthly | 14 | Oracles Chainlink price feeds are available on MegaETH. Incentive and Revenue Structure There are two options for the incentive and revenue structure provided by MegaETH. Option 1 - Points Program + Revenue Guarantee (with Rollover) User Incentives MegaETH will distribute 30 million points to Aave users on MegaETH during the mainnet launch period. Revenue Guarantee For each of the first 5 years after the Aave market launches on MegaETH, the DAO is guaranteed at least USD $2,000,000 per year in protocol revenue generated by the MegaETH Aave market. If annual revenue is below $2,000,000, MegaETH will pay the difference to the DAO within 30 days after the end of that year. If annual revenue exceeds $2,000,000, the excess rolls forward and counts toward meeting the $2,000,000 minimum in future years. There is no cap on how much excess revenue can roll forward, and excess revenue may roll over across multiple years. Example Year 1 revenue: $5,000,000 $2,000,000 satisfies Year 1 guarantee $3,000,000 rolls forward to Year 2 Year 2 revenue: $1,000,000 The $3,000,000 carried forward from Year 1 covers the full Year 2 guarantee No payment is required from MegaETH in Year 2 Option 2 - Revenue Guarantee Only (Points Not Guaranteed) User Incentives No points program is guaranteed under this option. However, MegaETH may, at its sole discretion, choose to run user incentive or points campaigns in the future. Any such incentives are not committed, not guaranteed, and not part of this option. Revenue Guarantee For each of the first 5 years after the Aave market launches on MegaETH, the DAO is guaranteed at least USD $2,000,000 per year in protocol revenue generated by the MegaETH Aave market. If annual revenue is below $2,000,000, MegaETH will pay the difference to the DAO within 30 days after the end of that year. If annual revenue exceeds $2,000,000, the excess does not carry forward and does not offset future years. Example Year 1 revenue: $5,000,000 $2,000,000 satisfies Year 1 guarantee The additional $3,000,000 does not carry forward Year 2 revenue: $1,000,000 MegaETH pays $1,000,000 to reach the $2,000,000 minimum MegaETH shall have no payment obligation unless and until the DAO approves the launch proposal and the Aave market is actually deployed on MegaETH with USDM listed under parameters defined at the AIP stage. The annual revenue guarantee period shall commence from the Aave market launch date on MegaETH. If Option 1 is selected, the points campaign will run only after the MegaETH mainnet is live and will be distributed over a defined campaign window. Next Steps Next steps are to collect community feedback on the preferred option, and to proceed with the risk assessment analysis for initial launch parameters and the initial asset set. Once the community is ready to escalate this proposal to snapshot, the voting options will be: Option 1 (Points Program + Revenue Guarantee with Rollover) Option 2 (Revenue Guarantee without Rollover) NAE (Do not proceed with MegaETH deployment under these terms) ABSTAIN Disclaimer Aave Labs is not compensated by MegaETH, nor affiliated with them. Copyright Copyright and related rights waived under CC0. Relevant Links Original MegaETH ARFC discussion: [\[ARFC\] Deploy Aave v3 on megaETH](https://governance.aave.com/t/arfc-deploy-aave-v3-on-megaeth/21329) MegaETH Tempcheck Snapshot: https://snapshot.org/\#/s:aavedao.eth/proposal/0xab1d9c42264c89e1b8f0d807c9ff971f8c3f9f5cc0323072d9e970c110d1e39b MegaETH Tempcheck discussion: [\[TEMP CHECK\] Deploy Aave v3 on megaETH](https://governance.aave.com/t/temp-check-deploy-aave-v3-on-megaeth/21155) BGD Technical Analysis: https://governance.aave.com/t/bgd-aave-megaeth-infrastructure-technical-evaluation/23905

Summary This document develops a formal framework for timely deficit realization on Aave by introducing an autonomous Risk Oracle that detects and deterministically resolves a specific liquidation failure mode: accounts with minimal remaining collateral (“dust”) and substantial outstanding debt. These accounts are economically insolvent, yet can remain mechanically non-deficit for extended periods because third-party liquidation is not exogenously profitable once the residual collateral is too small to cover gas and execution risk. Under Aave v3.3’s deficit semantics, where deficit is realized only when collateral is exactly zero, this dust state can induce large and persistent deficit latency. We propose a state-contingent mechanism in which an off-chain Risk Oracle monitors reserve and account-level dynamics and, upon observing a dust state, triggers a highly constrained on-chain executor (“ClinicSteward”) that performs a deliberately loss-tolerant liquidation/cleanup. The objective is not to “improve liquidation profitability,” but to minimize the time between the economic accrual of bad debt and its on-chain realization as a reserve deficit, thereby reducing timing surface area for Umbrella cooldown dynamics and improving the coherence of reserve-level coverage accounting. Problem statement Economic insolvency vs. realized deficit Aave’s deficit is not defined as “the moment an account becomes insolvent” in an economic sense. Instead, deficit is a mechanism-level event: the protocol records bad debt only once a liquidation process ends with absolutely zero collateral remaining while debt still exists. This is an intentionally objective definition and it is structurally compatible with Umbrella’s automated deficit handling. However, this definition introduces a practical edge case. Accounts can become insolvent and remain liquidatable while still retaining a strictly positive amount of collateral, often so small it is economically meaningless, thereby preventing the “zero collateral” condition from being met. In these states, bad debt is real, but mechanically latent, existing in the system’s balance sheet in economic terms while not yet being expressed as an on-chain deficit event. The dust regime: why liquidation stalls The deficit-latency failure mode is driven by a simple economic discontinuity. Liquidations are executed by third parties who are optimizing for private profitability. When the remaining collateral is extremely small, the liquidation bonus cannot compensate for gas costs and execution risk. At that point, finishing the liquidation becomes a public good, improving protocol accounting and deficit timeliness, but it is not privately rational to execute. This is the “dust regime”: accounts that are liquidatable and meaningfully indebted, yet unprofitable to clean up because the residual collateral is too small relative to fixed execution costs. Crucially, this is not primarily a function of the magnitude of the deficit. Even if the latent deficit is very large, the account may still sit untouched if the remaining collateral available to seize is near zero. From the perspective of an external liquidator, both an expected $100 deficit and a $10M deficit can be equally non-urgent if the expected collateral payout is dominated by gas. Why this persists despite other v3.3 improvements In addition to the enshrined “deficit” system, Aave v3.3 materially improved forced cleanup logic and reduced the probability of “dusty” end states by making liquidation closer to position-wide and by reverting cases that would strand tiny leftovers. In particular: 1. the default 50% close factor is applied to the whole position, not per asset, making it easier to liquidate small positions without cascading into dust. 2. liquidations up to 100% CF are allowed when the user’s debt/principal on the reserve being liquidated is below MINBASEMAXCLOSEFACTOR_THRESHOLD 3. introduces MINLEFTOVERBASE and reverts liquidations that would leave debt or collateral below the threshold unless one side is exactly zero. (MINLEFTOVERBASE = MINBASEMAXCLOSEFACTOR_THRESHOLD / 2 However, because Aave liquidations in practice remain asset-parameterized (collateral asset and debt asset are specified per call), and because positions can be cross-margined across multiple reserves, there remain plausible pathways in which liquidation resolves the economically meaningful portion of a position while leaving a small remainder of collateral that blocks deficit realization. In particular, bespoke liquidation choices and reserve-specific constraints can still strand dust in multi-asset accounts. The result is that a position can accrue bad debt during a stress event, but the reserve’s deficit is only realized weeks or months later, purely due to liquidation unprofitability in the dust tail. In practice, we have observed instances consistent with this pattern: positions that were effectively insolvent at the time of a stress event remained non-deficit for an extended period because they retained a minimal residual collateral balance that made completion unprofitable for external liquidators: 1. During the 10.10 drawdown event, this account effectively arbitraged the deviation in the reported oracle price and the onchain price of ENS and CRV assets, via utilizing WETH as collateral to maximally borrow such assets and run away with debt, leading to bad debt accrual. The $61.6K (5760 ENS) deficit event itself, however, was only internalized on December 6th, nearly two months after the bad debt was accrued. !image - 2026-01-16T160240.076.png 2. Similarly, the following account had WETH debt collateralized by AAVE and some marginal amount of USDT, resulting in the vast majority of the position being liquidated on 10.10 outside of 0.0003 USDT in collateral and some 1.38 WETH in debt, i.e., bad debt. The $4.6K deficit itself, however, was only realized on January 3rd, 2026, nearly three months after the bad debt was factually accrued. !image - 2026-01-16T160243.250.png Why this matters for Umbrella Umbrella’s design introduces cooldown-based exit dynamics for slashable backstop capital. This means the timing of deficit realization matters, not just the eventual accounting outcome. When deficits are realized late, the protocol’s on-chain view of reserve solvency lags the economic reality of losses. This expands the window in which sophisticated actors can condition cooldown and withdrawal behavior on information that is not yet reflected in the mechanism layer. If governance ever wants to compress cooldown, especially as Umbrella matures and automation improves, then minimizing deficit latency becomes directly relevant. The more promptly deficit events are forced to occur when economically implied, the less exploitable the timing surface area remains. Proposed mechanism Overview We introduce a two-layer system designed to eliminate deficit latency caused by dust-collateral positions: The first layer is a Deficit Realization Risk Oracle that operates off-chain, continuously monitoring account states alongside reserve configurations. Its role is to detect a narrow and conservative dust condition: accounts that are liquidatable (HF < 1), have strictly non-zero but minimal remaining collateral, and still carry material debt. When such accounts appear, the risk oracle groups them by an executable liquidation route (debtAsset, collateralAsset) and triggers cleanup automatically by submitting transactions to a constrained on-chain executor via batchLiquidate. The second layer is the Aave ClinicSteward, an on-chain constrained executor that exposes a minimal, permissioned action space for liquidation/repayment operations funded by the Aave Collector. Critically, it enforces a hard USD-denominated budget ceiling (“maximum allowance”) per deployed reserve instance, alongside asset allowlists and strict custody constraints. In the deficit realization use case, the steward is primarily used as a last-mile liquidation finisher, clearing the final dust collateral so that v3.3’s post-liquidation logic can immediately realize any remaining debt as a protocol deficit. These constraints are what keep the mechanism honest. The goal is not to compete with liquidators in normal conditions, nor to subsidize broad liquidation activity. It is to resolve a narrow failure mode where the account has already crossed into insolvency, but deficit recognition is delayed because the last dust collateral balance makes the position mechanically “non-zero collateral,” and therefore economically unattractive to finish externally. ClinicSteward specification: constrained action space The executor’s mandate is narrow: force collateral to exactly zero (in the protocol’s accounting sense) by completing the final dust-level cleanup on accounts that are already insolvent. The key distinction versus legacy “bad debt cleanup” usage is that this variant is not intended to repay the debt stock in any meaningful way. Instead, the liquidation performed is nominal and exists to remove the final collateral remainder; once collateral is zero, the remaining debt is expected to be realized as protocol deficit automatically under v3.3. This is what allows Collector usage to be factually minimal. The steward may need to pull a small amount of a debt asset to execute the liquidation call (and it may momentarily over-approximate), but it is not designed to absorb the loss by repaying principal. The loss is recognized at the protocol layer as deficit once the collateral is cleared, and any unused underlying plus seized collateral (received as aTokens) is routed back to the Collector deterministically. Most importantly, this is bounded at the governance layer through the ClinicSteward’s “maximum allowance” / available budget mechanism. Each deployed steward instance has an explicit USD-denominated budget ceiling controlling the total value that can be pulled from the Collector. Any execution that would exceed the remaining budget reverts, and the budget can only be renewed or adjusted through the steward’s admin controls (i.e., under governance authorization). For the deficit-realization use case, this ceiling can be configured orders of magnitude smaller than traditional cleanup budgets precisely because the steward is paying for completion, not repayment. Risk Oracle policy: continuous monitoring and automatic batch execution Rather than operating as a one-off “queue builder,” the Risk Oracle runs continuously over the account set and triggers cleanup as soon as accounts enter (and persist in) the dust condition. In practice, it maintains an always-updating watchlist of accounts that satisfy the eligibility criteria: liquidatable status, non-zero but minimal remaining collateral, and meaningful debt. It executes opportunistically when either a batch reaches a practical size threshold or a time-based trigger fires, avoiding the need to wait for perfect batching. Execution is routed directly through the ClinicSteward’s batchLiquidate entrypoint. Because the steward’s liquidation primitive is asset-parameterized, the Risk Oracle groups eligible users by a specific liquidation route (debtAsset, collateralAsset), then submits batchLiquidate(debtAsset, collateralAsset, users, useAToken) for each group. This keeps the on-chain call surface simple and aligns with how liquidation must be specified in Aave: one debt asset repaid against one collateral asset per call. This maps cleanly to the steward’s intended operational pattern. batchLiquidate pulls an over-approximation of required debt funds from the Collector, attempts to liquidate each user in the batch, and then returns any unused underlying as well as any seized collateral (received as aTokens) back to the Collector. The overall spend envelope remains tightly bounded by the steward’s availableBudget mechanism, so any attempt to exceed the configured maximum allowance reverts. In this design, the Risk Oracle is the permissioned operator (or one of a small set of operators) holding CLEANUP_ROLE, and is therefore the only entity authorized to invoke batchLiquidate. Conclusion Aave v3.3 makes deficit an objective, on-chain primitive, but it still inherits a practical edge case: deficit is only realized once collateral is exactly zero. In the dust tail, liquidatable accounts with minimal residual collateral and meaningful debt can require the last step to be completed, which is not profitable for external liquidators. Consequently, bad debt can remain mechanically unrealized for weeks or months. This latency matters for Umbrella because cooldown-based exits make timing a first-order concern: delayed deficit recognition increases the window where the protocol’s on-chain solvency view lags economic reality. The Risk Oracle and ClinicSteward close this gap by automating the last-mile cleanup. The Risk Oracle continuously detects dust states and triggers batchLiquidate, while the steward enforces strict permissions and a hard, governance-set budget ceiling. The result is faster, budget-bounded deficit realization and reduced timing surface area for Umbrella. Disclosure Chaos Labs has not been compensated by any third party for publishing this research paper and ensuing risk oracle. Copyright Copyright and related rights waived via CC0.

[ARFC] Deploy Aave v3 on Mantle Author: ACI Date: 2025-01-07 --- Proposal updated with latest Risk Service Providers recommendations on 2026-01-15 and also updated to include Tokenlogic's contributions about GHO, GSM Parameters and Budget. Proposal edited on 2026-01-19 to update the proposal with latest forum discussion. Snapshot will be posted again. Simple summary The current [ARFC] proposes deploying Aave V3 on Mantle Network. Motivation Mantle Network is an EVM-compatible Layer 2 scaling solution for Ethereum (rollup), enabling existing Ethereum contracts and tools to operate with minimal modifications. By leveraging a modular architecture, Mantle combines an optimistic rollup design with innovative data availability solutions to reduce costs while maintaining Ethereum’s security. Data availability is managed by an external DA layer, currently powered by EigenDA technology through Mantle DA, with plans to fully adopt EigenDA upon its mainnet stable launch. By deploying on Mantle, Aave can take advantage of Mantle’s integration with Bybit products, enabling seamless access to Bybit’s 30 million active users. This creates a significant opportunity to broaden Aave’s user base and make DeFi more accessible to a wider audience. Mantle currently boasts a TVL of approximately $570 million, while its flagship LST (mETH) holds a TVL of $1.85 billion. More details here. Benefits of deploying on Mantle Accessibility and Distribution As Mantle is closely integrated with Bybit, Aave’s deployment on Mantle positions the protocol in front of an expanding audience. - This integration creates a gateway for tens of millions of potential new users to access Aave’s lending and borrowing products, making DeFi simpler and more accessible than ever before. Incentive campaigns Mantle’s ongoing incentive program, Metamorphosis Season 2 offers a powerful catalyst for user engagement and liquidity growth within the ecosystem. - Restaking mETH into cmETH, participants earn Powder—soon to be convertible into COOK, the governance token of the mETH Protocol—and gain exposure to multiple streams of yield from staking, restaking, and additional protocol rewards. cmETH also accruing value through EigenLayer, Karak, Symbiotic and Veda points. Specification Risk Parameters will be provided by Service Providers and this section will be updated accordingly. ARFC updated 2026-01-15 Specification | Parameters | Value | Value | Value | Value | Value | Value | Value | Value | Value | Value | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Asset | WETH | WMNT | USDT0 | USDC | USDe | GHO | sUSDe | fBTC | syrupUSDT | wrsETH | | Isolation mode | Yes | Yes | No | No | No | No | No | No | No | No | | Borrowable | Yes | No | Yes | Yes | Yes | Yes | No | No | No | No | | Collateral Enabled | Yes | Yes | No | No | No | No | No | No | No | No | | Supply Cap | 30,000 | 5,000,000 | 50,000,000 | 10,000,000 | 20,000,000 | 20,000,000 | 20,000,000 | 50 | 70,000,000 | 18,000 | | Borrow Cap | 28,000 | - | 47,500,000 | 9,500,000 | 17,500,000 | 18,000,000 | - | - | - | - | | Debt Ceiling | 30,000,000 | 2,000,000 | - | - | - | - | - | - | - | - | | LTV | 80.50% | 40.00% | - | - | - | - | - | - | - | - | | LT | 83.00% | 45.00% | - | - | - | - | - | - | - | - | | Liquidation Bonus | 5.50% | 10.0% | - | - | - | - | - | - | - | - | | Liquidation Protocol Fee | 10% | 10% | 10% | 10% | 10% | - | 10% | 10% | 10% | 10% | | Variable Base | 0.0% | - | 0.0% | 0.0% | 0.0% | 2.0% | - | - | - | - | | Variable Slope1 | 2.50% | - | 5.0% | 5.0% | 5.25% | 3.0% | - | - | - | - | | Variable Slope2 | 8.00% | - | 10.0% | 10.0% | 12.0% | 40.0% | - | - | - | - | | Uoptimal | 90.0% | - | 90.0% | 90.0% | 85.0% | 90.0% | - | - | - | - | | Reserve Factor | 15% | - | 10% | 10% | 25% | 10% | - | - | - | - | | Stable Borrowing | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | | Flashloanable | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | Siloed Borrowing | No | No | No | No | No | No | No | No | No | No | | Borrowable in Isolation | No | No | Yes | Yes | Yes | Yes | No | No | No | No | | E-Mode | 5 | - | 1, 2, 3, 4 | 1, 2, 3, 4 | 1, 2, 3, 4 | 1, 2, 4 | 1 | 3 | 4 | 5 | E-Mode Configurations sUSDe Stablecoins #1 | Parameter | Value | Value | Value | Value | Value | | --- | --- | --- | --- | --- | --- | | Asset | sUSDe | USDe | USDT0 | USDC | GHO | | Collateral | Yes | Yes | No | No | No | | Borrowable | No | No | Yes | Yes | Yes | | Max LTV | 90.00% | 90.00% | - | - | - | | Liquidation Threshold | 92.00% | 92.00% | - | - | - | | Liquidation Bonus | 4.00% | 4.00% | - | - | - | USDe Stablecoins #2 | Parameter | Value | Value | Value | Value | | --- | --- | --- | --- | --- | | Asset | USDe | USDT0 | USDC | GHO | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | Max LTV | 90.00% | - | - | - | | Liquidation Threshold | 93.00% | - | - | - | | Liquidation Bonus | 2.00% | - | - | - | fBTC Stablecoins #3 | Parameter | Value | Value | Value | Value | | --- | --- | --- | --- | --- | | Asset | fBTC | USDT0 | USDC | USDe | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | Max LTV | 75.00% | - | - | - | | Liquidation Threshold | 79.00% | - | - | - | | Liquidation Bonus | 8.00% | - | - | - | syrupUSDT Stablecoins #4 | Parameter | Value | Value | Value | Value | | --- | --- | --- | --- | --- | | Asset | syrupUSDT | USDT0 | USDC | GHO | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | Max LTV | 90.00% | - | - | - | | Liquidation Threshold | 92.00% | - | - | - | | Liquidation Bonus | 4.00% | - | - | - | wrsETH Correlated #5 | Parameter | Value | Value | | --- | --- | --- | | Asset | wrsETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Bonus | 1.00% | - | CAPO | Asset | maxYearlyRatioGrowthPercent | ratioReferenceTime | MINIMUMSNAPSHOTDELAY | | --- | --- | --- | --- | | syrupUSDT | 8.45% | Monthly | 7 | | sUSDe | 15.19% | Monthly | 14 | | wrsETH | 6.67% | Monthly | 14 | GHO Stablecoin Facilitator & Bridging Mint an additional new 20M GHO to fund the remoteGSM on Mantle. OwnableFacilitator Mint Cap: 100M GHO (No change from Plasma proposal) Additional Mint: 20M GHO (additional to Plasma Mint) GhoReserve Deploy GhoReserve on Mantle to hold bridged GHO initially. Configure stataUSDT0 GSM as an entity with a draw capacity of 20M GHO. Deploy a GhoDirectMinter facilitator on Ethereum to enable GHO issuance for Mantle. Mint Cap: 20M GHO As required, future Minting of GHO on Ethereum, to be supplied into the remoteGSM on Mantle, will be performed via direct submission of AIPs. CCIP Bridge Configuration: Bucket Capacity: 20M GHO Inbound Capacity: 1.5M GHO Outbound Capacity: 1.5M GHO Refill Rate: 300 GHO/sec Currently, the CCIP Bridge to Mantle Network is v1.5 and requires upgrading to v1.6 before GHO lanes are to be established. TokenLogic will work closely with Chainlink to sync upgrade timelines and extend the new GHO lanes to/from Mantle. GSM Parameters (stataUSDT0) | Parameter | Value | | --- | --- | | GHO Bucket Cap | 10M GHO | | stataUSDT0 Exposure Cap | 8.5M | | Freeze Lower Bound | $0.990 | | Freeze Upper Bound | $1.010 | | Unfreeze Lower Bound | $0.995 | | Unfreeze Upper Bound | $1.005 | | Mint GHO Fee | 0% | | Burn GHO Fee | 0.15% | USDT deposits into stataUSDT0 trigger GHO transfers using Ethereum-held inventory via GSM. GHO Steward Configuration GhoAaveSteward updateGhoBorrowCap: ±100% updateGhoBorrowRate: ±5% on optimal usage ratio, base variable rates, slopes updateGhoSupplyCap: Up to +100% GhoGsmSteward updateGsmExposureCap: ±100% updateGsmBuySellFees: ±0.5% per side (FixedFeeStrategy) Both stewards remain callable only by the GHO steward protocol. Budget The Aave and Mantle teams will each provide incentive budgets to support the growth of Aave Protocol for the initial 6-month period post-launch, subject to achieving growth expectations and prevailing market conditions. Mantle: 8M units of MNT value at around 8.8M USD, assuming MNT is trading at $1.10ea. Aave DAO: To provide incentive rewards via the pre-approve Extended Ahab Budget facility and additionally, 1.5M GHO via the Aave Liquidity Committee to promote GHO’s adoption on Mantle. For GHO, Ethereum: Asset: aEthLidoGHO 0x18eFE565A5373f430e2F809b97De30335B3ad96A Amount: 1.5M Spender: Aave Liquidity Committee (ALC) 0xA1c93D2687f7014Aaf588c764E3Ce80aF016229b Method: approve() aEthLidoGHO on the Aave Collector contract to the ALC address. Disclaimer This proposal is powered by Skywards. The ACI is not directly affiliated with Mantle and did not receive any compensation for creating this proposal. Next Steps 1. Publication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. 2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via CC0.

[ARFC] Onboard Strata srUSDe PT tokens to V3 Core Instance Author: ACI Date: 2025-12-01 ---- Proposal has been updated with latest Risk Parameters by Service Providers on 2025-01-16 Summary This proposal seeks to onboard the Strata srUSDe PT tokens to the Aave V3 Core Instance, after successful [[TEMP CHECK] Onboard Strata srUSDe January expiry PT tokens to V3 Core Instance](https://governance.aave.com/t/temp-check-onboard-strata-srusde-january-expiry-pt-tokens-to-v3-core-instance/23359). Taking into account timelines for onboarding we are targeting onboarding the next expiry after the January expiry PT token once they go live. Motivation Given both the popularity of PT token collateral on Aave and the adoption of the srUSDe PT token by LPs on Pendle, we believe this would be an attractive collateral token for Aave users. We believe that Aave users would welcome the addition of a PT token from the Ethena ecosystem with circa 50% higher yields than sUSDe PT tokens at the time of writing. Specification Proposal has been updated with latest Risk Parameters by Service Providers on 2025-01-16 | Parameter | Value | | --- | --- | | Asset | PT-srUSDe-1APR2026 | | Isolation Mode | No | | Borrowable | No | | Collateral Enabled | No | | Supply Cap | 50,000,000 | | Borrow Cap | - | | Debt Ceiling | - | | LTV | - | | LT | - | | Liquidation Bonus | - | | Liquidation Protocol Fee | 10.00% | | E-Mode Category | PT-srUSDe Stablecoins, PT-srUSDe USDe | Initial E-Mode Risk Oracle | Parameter | Value | Value | | --- | --- | --- | | E-Mode | Stablecoins | USDe | | LTV | 89.5% | 91.2% | | LT | 91.5% | 93.2% | | LB | 4.5% | 2.6% | Linear Discount Rate Oracle | Parameter | Value | | --- | --- | | initialDiscountRatePerYear | 6.72% | | maxDiscountRatePerYear | 24.01% | PT-srUSDe Stablecoins E-mode | Asset | PT-srUSDe-1APR2026 | sUSDe | USDT | USDe | USDC | | --- | --- | --- | --- | --- | --- | | Collateral | Yes | Yes | No | No | No | | Borrowable | No | No | Yes | Yes | Yes | | LTV | Subject to Risk Oracle | Subject to Risk Oracle | - | - | - | | LT | Subject to Risk Oracle | Subject to Risk Oracle | - | - | - | | Liquidation Bonus | Subject to Risk Oracle | Subject to Risk Oracle | - | - | - | PT-srUSDe USDe E-mode | Asset | PT-srUSDe-1APR2026 | sUSDe | USDe | | --- | --- | --- | --- | | Collateral | Yes | Yes | No | | Borrowable | No | No | Yes | | LTV | Subject to Risk Oracle | Subject to Risk Oracle | - | | LT | Subject to Risk Oracle | Subject to Risk Oracle | - | | Liquidation Bonus | Subject to Risk Oracle | Subject to Risk Oracle | - | Contract address to be updated once new expiry is live. Risk Parameters Risk parameters will be provided by Risk Service Providers and the proposal will be updated accordingly. Useful Links https://docs.pendle.finance/ProtocolMechanics/YieldTokenization/PT Disclaimer ACI is not directly affiliated with Pendle and did not receive compensation for the creation of this proposal. Some ACI employees may hold Pendle tokens. Next Steps 1. Publish ARFC to get feedback from both community and Service Providers. 2. if ARFC Snapshot pass, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived under CC0

Summary Before a proposal is brought to a vote by a 3rd party, the proposer must indicate they wish to submit that proposal a vote. Motivation Recent events have highlighted this gap in the proposal rules. Submitters should have time to revise proposals and should not have their name attached to a proposal they have not chosen to submit. I am open to consider other proposal related rules that the community thinks should be included. Details The proposer must indicate they wish to have a proposal submitted before a 3rd party can submit it for a vote, such as by replying “formally submitting” on the proposal’s forum thread. Specification As this proposal pertains to governance guidelines, it does not require any on-chain action or protocol change. Disclaimer Codeknight is not presenting this ARFC on behalf of any third party and is not compensated for creating this ARFC. Next Steps 1. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is YAE, this proposal will be considered canon, and the guidelines will be adopted. Copyright Copyright and related rights waived via CC0.

[ARFC] Orbit Program Renewal - Q1 and Q2 2026 Author: ACI (Aave Chan Initiative) Date: 2025-12-20 --- Summary Proposing the latest renewal of the Orbit program for recognized delegates, compensating them with GHO, associated with their future governance activity during Q1 and Q2 2026( From 2026-01-01 new date when [[ARFC] Orbit Program Renewal - Q3 and Q4 2025](https://governance.aave.com/t/arfc-orbit-program-renewal-q3-and-q4-2025/23289) ends, until 2025-06-30). The reason as mentioned previously is because extending period coverage will bring more reliance and predictability for delegates plaform. Motivation Orbit recognizes the added value of the Delegates in the decentralization & diversity of the Aave DAO. This compensation allows them to focus on Aave and keep their contribution efforts to our governance. The ACI proposes the extension of Orbit for a both Q1 and Q2 2026, from 2026-01-01 to 2026-06-30, as mentioned previously on [[ARFC] Orbit Program Renewal - Q3 and Q4 2025](https://governance.aave.com/t/arfc-orbit-program-renewal-q3-and-q4-2025/23289). As a reminder from previous Orbit rounds, a new cutoff had been set, starting at AIP 224, to apply again previous rules of a minimum of 20k voting power and 85% vote ratio on all Snapshots and AIP to be considered elegible to Orbit. As a reminder again,for transparency purposes, Orbit periode coverage will be 2 times per year (Q1 and Q2 together, and Q3 and Q4 together), with the aim of reducing governance bloat. Additional Compensation @EzR3al has been actively moderating Discourse and contributing to several DAO-oriented initiatives, including implementing forum add-ons and, most recently, the vote-tracking widget. These contributions have added tangible value to the ecosystem. Creating an ad hoc service provider stream would be disproportionate, but we do want to recognize and reward specific community members who consistently contribute for the benefit of the Aave ecosystem. We would like to submit for governance approval a 100% increase in @EzR3al’s Orbit compensation to reflect the additional involvement and work delivered. Specification Period Coverage: Q1 and Q2 2026 from 2026-01-01 to 2026-06-30 Eligible Platforms: - EzR3al: 0x8659d0bb123da6d16d9394c7838ba286c2207d0e - StableLab: 0xecc2a9240268bc7a26386ecb49e1befca2706ac9 - IgnasDefi: 0x3DDC7d25c7a1dc381443e491Bbf1Caa8928A05B0 - Areta:0x8b37a5Af68D315cf5A64097D96621F64b5502a22) Budget: 150,000 GHO (aEthLidoGHO) Relevant Links: - ACI’s Orbit tracker Additional considerations: As a reminder, Service Providers will not be considered elegible to Orbit Program. Funds are distributed based on 180 days, as seen on budget and as specificied on motivation section. Next Steps 1. Gather community feedback on this ARFC. 2. If consensus is achieved, escalate this proposal to the ARFC snapshot stage. 3. If the ARFC snapshot outcome is YAE, proceed to the AIP stage for implementation and funding allocation in cooperation with Aave Finance service providers via an ad-hoc AIP vote or bundled in one of their treasury management AIPs. Disclosure The ACI is independent and has not received any form of compensation from related parties for the drafting of this proposal. Copyright Copyright and related rights waived under Creative Commons Zero (CC0)

Title: [ARFC] $AAVE token alignment. Phase 1 - Ownership Author: Ernesto Boado (co-founder @bgdlabs) Date: 2025-12-21 Summary This is an Aave Governance proposal for AAVE token holders to request receiving control of Aave’s brand assets (domains, social handles, naming rights, etc), on a DAO-controlled vehicle (defined at a later stage) with strong anti-capture protections. Hence, asking for any party controlling them at the moment to deliver them both in ethos and in practice, no matter who that party is. Motivation Aave’s origins and long-term direction have consistently been framed around decentralization: a project initially funded via a decentralized mechanism (ICO), to be owned and governed by token holders through a real DAO, ideally self-sustainable, with both value and accountability expected to be inherent to the Aave DAO itself. For years, the community has operated under the implicit expectation of alignment between contributors (e.g. Service Providers) and the DAO. In practice, for example, Aave Labs has been implicitly considered as a good-faith steward of communications channels, or important gateways such as aave.com on behalf of the broader ecosystem. Or BGD Labs, has been acting as implicit steward of others like the aave-dao Github organisation, where multiple contributors maintain different repositories. But that implicit understanding, no matter who the third-party is, is not a healthy or beneficial for $AAVE long-term, as the fact of making the delegation stewardship explicit, is un-doubtfully only positive to $AAVE. Moreover, recent events have raised concerns on other community members in these forum, that these brand assets are being used to enable private monetisation and to support products the DAO has no practical say on, and is not the main value-recipient. This proposal is therefore intended to bring explicit clarity and DAO control to how Aave-branded assets and intellectual property are, first, owned, and second, can be used, and the terms for it. Specification The proposal to vote is simple: should the Aave DAO and AAVE token holders regain full control over Aave’s brand, naming rights, and associated assets? With any third party currently controlling these assets (Aave Labs, BGD Labs, anybody), transferring them to the DAO via an appropriate DAO-controlled legal wrapper. These “assets” rights include but are not limited to: The DAO deciding on “Aave” naming rights for products and organisations, not any third parties. * Examples: Usage of “Aave Labs”, “Aave App”, “Aave Web App”, “Aave Pro” or “Aave Horizon”. * This also includes representational titles, such as using executive titles of Aave (e.g., “CEO of Aave”) without proper clarification of separation. The DAO having ownership and control over all communication channels using “Aave” or implicitly associated names. This includes but is not limited to the “aave” handle on X, the Aave Discord, “aave” on Instagram, and any other social or public channel. The DAO having control and ownership over domains, including but not limited to aave.com, and any others with direct association (e.g., onaave.com). The DAO having ownership over online organisations, including but not limited to GitHub or npm. Example, “aave” and “aave-dao” Github organisations, “aave” npm, etc. Additionally, this proposal approves the intention to establish strict mechanisms so that no third party can misuse these assets or privately benefit from them, implicitly or explicitly, with legally enforceable recourse by the DAO if such a situation arises. And to seek legal advice if any of the counterparties don’t facilitate the process of ownership transfer. This practical setup should be implemented by a provably neutral third party, independent from all Aave Service Providers, and legally accountable to AAVE token holders’ interests. Copyright Copyright and related rights waived under CC0.

[ARFC-Addendum] Update Merit for Round 41 - Adding OKX Author: ACI (Aave Chan Initiative) Date: 2025-12-10 --- Simple Summary This addendum proposes updates to the Boosters for Merit Round 41 to add OKX Wallet. Motivation To support the sGHO integration on the OKX Wallet, we propose updating the Aave Aligned Frens Booster to include OKX users and the OKX team. They will join the existing Aave Aligned Frens: Gate.io and Infinity Specification Boosters Update The following changes will be applied: Aave Aligned Frens Booster will be to Infinity, Gate.io and OKX team. Next Steps 1. Escalate this [ARFC-Addendum] proposal to a Snapshot vote for formal approval. 2. If [ARFC Addendum] is approved in the Snapshot phase, the proposal will be canon and changes will be applied retroactively to Merit Round Disclaimer The Aave Chan Initiative independently proposes “Merit” without external compensation. Copyright Copyright and related rights waived under Creative Commons Zero (CC0).

[ARFC] Onboard USDG to Aave V3 Core Instance Author: ACI Date: 2025-10-17 --- Proposal updated with latest Risk Parameters provided by Risk Service Providers 2025-12-04 Summary We propose the onboarding of USDG, a USD-backed stablecoin issued by Paxos, on Aave V3 Core Instance. This listing would initially enable users to deposit USDG to earn yield and borrow USDG as a stable asset. Collateral usage will be considered at a later date following review by Aave's Risk Management teams. TEMP CHECK has passed as well as TEMP CHECK Snapshot Motivation USDG is a regulated stablecoin backed 1:1 by cash and short-term U.S. Treasuries, designed with regulatory compliance and transparency as core principles. As a trusted stablecoin from Paxos, a regulated financial institution with a strong track record, USDG has gained significant adoption across various platforms, demonstrating market confidence and growing utility. Key differentiators: 1. Regulatory compliance: USDG is fully regulated and issued by Paxos, a New York State Department of Financial Services regulated entity. 2. Transparency: Regular attestations verify USDG's reserves are fully backed by cash and short-term U.S. Treasuries. 3. Chainlink price feed: Live and available for use in Aave integrations. Specification Risk Parameters will be provided by Risk Service Providers and proposal will be updated accordingly. | Parameter | Value | | --- | --- | | Asset | USDG | | Isolation Mode | No | | Borrowable | Yes | | Collateral Enabled | No | | Supply Cap | 30,000,000 | | Borrow Cap | 25,000,000 | | Debt Ceiling | - | | LTV | - | | LT | - | | Liquidation Bonus | - | | Liquidation Protocol Fee | - | | Variable Base | 0% | | Variable Slope1 | 6.00% | | Variable Slope2 | 50% | | Uoptimal | 80% | | Reserve Factor | 20% | USDG Overview: Ticker: USDG Fiat backed stablecoin Issuer: Paxos Backing assets: USD cash and short-term U.S treasuries. Audits: Multiple third-party audits Price Oracle: Chainlink USDG Listed on: Major centralized and decentralized exchanges. Use Cases: 1. Deposits enabled for yield generation 2. Borrowing enabled as a low-volatility asset Incentives: Paxos is considering incentive programs to boost adoption and enhance the competitiveness of USDG borrowing rates compared to other stablecoin assets on Aave. Detailed incentive structures will be shared with Aave DAO contributors and the community in the ARFC stage. Disclosure The current proposal has been powered by Skywards. ACI is not affiliated with Paxos and has not received compensation for the creation and review of this proposal. Next Steps 1. Publication of a standard ARFC to continue collecting community & service provider feedback before escalating proposal to ARFC snapshot stage. 2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via [CC0]

[TEMP CHECK] Focussing the Aave V3 Multichain Strategy Author: ACI Date: 19/11/2025 --- Summary This Temp Check proposes an updated multichain strategy for Aave V3 that: 1. Increases the Reserve Factor on underperforming instances to boost revenue. 2. Winds down the zkSync, Metis, and Soneium instances. 3. Establishes a clear $2,000,000 annual revenue floor for new instance deployments. Motivation Aave maintains several V3 instances which each carry operational costs and present risk surface area. It is believed that the revenue generated by several of these instances is not sufficient to offset the costs and risks they incur. Over time the multichain expansion strategy has seen mixed results and as expressed in the recent State of the Union post, we hold the view that it has not been the total success which it was hoped to be. We instead believe that Aave should focus on those chains which present the highest opportunity for revenue generation going forward and take remedial action to improve revenue on instances which are currently underperforming. !output-2.png Figure 1 - TVL by chain, as of 11/11/2025 and excluding Ethereum mainnet instances. !output.png Figure 2 - Annualised revenue by chain, calculated based on past 30 days rolling revenue as of 11/11/2025 and excluding Ethereum mainnet instances. Table 1 - Contribution of instances to Aave V3 TVL and revenue. |Chain|Rolling 30D Revenue (USD)|Annualized Revenue (USD)|TVL (USD, millions)|TVL as % of total|Revenue as % of total| |---|---|---|---|---|---| |Ethereum|$11,693,762|$142,274,104|$44,260|81.10%|81.60%| |Plasma|$783,430|$9,531,732|$3,700|6.78%|5.47%| |Base|$386,687|$4,704,692|$1,800|3.30%|2.70%| |Arbitrum|$487,627|$5,932,795|$1,870|3.43%|3.40%| |Avalanche|$296,886|$3,612,113|$1,050|1.92%|2.07%| |Linea|$249,104|$3,030,765|$766|1.40%|1.74%| |Polygon|$235,421|$2,864,289|$315|0.58%|1.64%| |BNB Chain|$60,121|$731,472|$373|0.68%|0.42%| |Optimism|$44,914|$546,454|$179|0.33%|0.31%| |Scroll|$42,398|$515,842|$23|0.04%|0.30%| |Gnosis|$26,293|$319,898|$123|0.23%|0.18%| |Sonic|$16,619|$202,198|$81|0.15%|0.12%| |Celo|$4,796|$58,351|$23|0.04%|0.03%| |Soneium|$4,269|$51,940|$4|0.01%|0.03%| |zkSync|$1,682|$20,464|$14|0.03%|0.01%| |Metis|$275|$3,346|$8|0.01%|0.00%| |Total|$14,334,284|$174,400,455|$54,589||| As can be seen from the above plots and table, there are several instance deployments which are significantly underperforming from both a revenue and TVL point of view. Reserve Factor Increases on Underperforming Instances We propose that Reserve Factors will be set at an increased floor on all underperforming instances, currently generating less than $3M annualized revenue, namely: Polygon, Gnosis, BNB Chain, Optimism, Scroll, Sonic, and Celo. Full details of Reserve Factor adjustments for all affected chains and assets will be provided at ARFC stage. Table 2 - Recommended Reserve Factor floors. | Asset category | Reserve Factor | | --- | --- | | Stablecoins (excl. USDC/USDT) | 25% | | WETH | 20% | | USDC / USDT | 15% | | GHO | 10% | If no meaningful improvement in revenue is observed within the next 12 months following these RF adjustments, ACI will consider initiating offboarding procedures for the affected instances in order to focus resources exclusively on current and future high-revenue deployments. Shutdown of Aave V3 on the three lowest revenue instances The zkSync, Metis, and Soneium instances have proven to lack product market fit, with annualized revenue of approximately $3,000-50,000. In addition to the low revenue, some of these chains require additional engineering effort for any new asset onboardings, which, given current service provider workload and low pay-off, is not currently feasible. Policy for Future Aave V3 Deployments We would like to highlight the significant value an Aave deployment provides to a new chain. As the largest DeFi protocol, the value and stimulating effect on the onchain ecosystem that a properly planned Aave deployment can bring is significant. The work involved in a deployment and the substantial ongoing effort from service providers and governance participants has at times been under appreciated, yet in light of the above revenue numbers we must bring this back into focus. The upfront and recurring costs mean the DAO must prioritize deployments that generate sufficient revenue to justify the time and risk involved. We therefore propose that for any new Aave deployment the chain on which we are deploying guarantees a revenue floor of $2m per annum for all new deployments. Conclusion We believe that the above remediation measures will help to focus the DAO on high revenue opportunities, ensure Aave shares in upside from successful instance deployments, reduce the number of low value deployments going forward, ensure that Aave is fairly compensated for the value it brings to our partners, and reduce risk and operational overhead by offboarding poor performing instances. Disclaimer ACI is not presenting this proposal on behalf of any third party and is not being compensated for creating this proposal. Next Steps 1. Period of comment on this TEMP CHECK. 2. TEMP CHECK Snapshot vote. 3. If TEMP CHECK is a YAE, publish a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. 4. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via CC0.