Aave Governance

[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.

Proposal updated by ACI to reflect latest Specifications 2025-10-30 Summary LlamaRisk proposes an update to the Aave V3 Core Umbrella target liquidity levels, prompted by a roughly 54% increase in total debt since the mechanism launched 4 months ago. The significant growth in USDC and USDT borrowing has rendered the initial coverage levels outdated. To align with current market conditions, the recommendation is to increase the target liquidity for USDT to 130 million and decrease the target for GHO to 8 million. In contrast, the targets for USDC and WETH will remain unchanged. This addresses the observed shifts in borrow activity and ensures coverage levels are appropriate for the current risk exposure. In addition to adjusting existing modules, we propose expanding Umbrella's scope to include three high-impact assets: wstETH, USDe, and WBTC. This expansion would bring assets accounting for 98.12% of total borrows under Umbrella's protection. In the medium term, the associated increase in annual emissions would be offset by the ongoing depreciation of legacy staking modules. Introduction It has been four months since the launch of Umbrella, which has proven successful, with all existing modules reaching their target coverage levels. However, since the initial insurance caps were recommended, market dynamics have shifted, particularly for USDC and USDT; both have seen significant supply and borrow activity growth on the Aave V3 Core instance. Beyond these assets, others such as wstETH and USDe represent a substantial share of Aave’s TVL, highlighting the need to expand Umbrella’s coverage to include them. As a result, the scope is to re-evaluate the existing insurance cap recommendations for currently covered assets, in light of updated liquidity and risk conditions, and to propose new coverage paths for additional high-impact assets on the Aave V3 Core instance. This expansion would support the gradual phase-out of stkAAVE coverage while maintaining overall coverage levels and optimizing the efficiency of the emissions. Existing Umbrella Modules Coverage Evolution Since its launch, the total debt on the Aave V3 Core instance has grown significantly, from $13.8B to $21.3B, marking a \~54% increase. The four assets currently covered under Umbrella, USDC, USDT, WETH, and GHO, now account for $18.7B, or 87.7% of total borrows. While it may appear that most of Aave’s borrow exposure is already secured through Umbrella, it's important to recognize that the initial insurance recommendations were made based on significantly lower borrow caps set nearly five months ago. Given the substantial increase in total debt since then, the original caps no longer reflect current market conditions. The individual growth trajectories of the covered assets since Umbrella’s launch are detailed here: WETH and GHO have maintained relatively stable supply and borrow levels since the launch of Umbrella. In contrast, USDC and USDT have experienced significant growth in both supply and borrow activity. In response to this demand, their respective caps were raised multiple times: USDC supply cap increased from $4.8B to $7.5B, and the borrow cap from $4.32B to $7B USDT supply cap rose from $5.25B to $9.5B, and borrow cap from $4.72B to $8.8B. Adjusted Coverage Estimations Following the changes, new liquidity targets for each asset under Umbrella were determined using our VaR methodology, which simulates extreme market stress using historical price data to generate synthetic shock scenarios. It models user liquidations under these shocks to estimate each asset’s liquidation capacity (the maximum debt that can be liquidated profitably for liquidators). Based on the simulation run done on September 29, 2025, we present the liquidation capacity changes overlaid with the asset borrow cap changes: | Asset | Liquidation Capacity Change | Borrow Cap Change | |----|----|----| | USDC | 50,400,000 USDC → 117,700,000 USDC | 4,320,000,000 USDC → 7,000,000,000 USDC | | USDT | 12,200,000 USDT → 42,730,000 USDT | 4,720,000,000 USDT → 8,800,000,000 USDT | | WETH | 6,900 WETH → 697 WETH | 2,700,000 WETH → 2,900,000 WETH | | GHO | 5,000,000 GHO → 18,220,000 GHO | 180,000,000 GHO → 180,000,000 GHO (unchanged) | Over the four months since the initial simulation run on May 15, 2025, the liquidation capacity for USDC, USDT, and GHO has increased substantially, while WETH capacity has declined. These shifts are primarily explained by changes in borrower distribution: when a larger share of debt is concentrated in a few large borrowers, liquidity capacity decreases as fewer liquidatable positions fall within the inlier set defined by the Interquartile Range (IRQ) method. In the case of WETH, the decline in liquidation capacity was further exacerbated by market conditions. Increased price volatility of ETH resulted in a shortage of WETH liquidity in secondary markets. At the same time, the long validator exit queue created a parallel shortage of LST/ETH liquidity on DEXs. This is particularly relevant since the two largest WETH borrowers, accounting for \~47% of WETH borrows, engage in LST/LRT looping strategies at low health factors of [1.02] As a result, the availability of profitable liquidation opportunities in WETH diminished. Moreover, shock simulations indicate that GHO, USDC, and USDT were among the most stable assets, experiencing minimal negative price movements. WETH, while showing a mild average drawdown of approximately -0.057% under stressed scenarios, still demonstrates relatively stable and predictable behavior. This stability suggests that, although their current liquidation capacity is low, WETH and GHO remain manageable from a risk perspective due to their robust shock resilience during market stress. To put the overall numbers into perspective, the changes in total debt and borrow cap coverage since the initial deployment are as follows: | Asset | Initial Total Debt Coverage\ | Current Total Debt Coverage\ | Initial Borrow Cap Coverage | Current Borrow Cap Coverage | |:---|:---|:---|:---|:---| | USDC | 135,400,000 USDC | 183,368,556 USDC | 3.13% | 2.62% | | USDT | 150,250,000 USDT | 153,486,582 USDT | 2.46% | 1.74% | | WETH | 31,900 WETH | 39,294 WETH | 1.18% | 1.35% | | GHO | 17,000,000 GHO | 32,351,731 GHO | 9.44% | 17.97% | \Total debt coverage is the sum of liquidity capacity and the current Umbrella Module deposits.* Based on the details presented above, new target liquidity recommendations for the existing Umbrella Modules are as follows: | Asset | Current Target Liquidity | Current Liquidity | Recommended Target Liquidity | |:---|:---|:---|:---| | USDC | 66,000,000 USDC | 65,668,556 USDC | 66,000,000 USDC (unchanged) | | USDT | 104,000,000 USDT | 110,756,582 USDT | 130,000,000 USDT | | WETH | 25,000 WETH | 38,597 WETH | 25,000 WETH (unchanged) | | GHO | 12,000,000 GHO | 14,131,731 GHO | 8,000,000 GHO | For USDC, the increase in liquidity capacity has proportionally tracked the borrow cap expansion, and a similar pattern is observed for GHO. In contrast, WETH coverage has been maintained primarily through substantial deposits into its Safety Module. The main exception is USDT, where current borrow cap coverage has declined. Based on these observations, we recommend increasing USDT’s target liquidity while reducing GHO’s target liquidity by 33%, as its existing liquidity capacity is already sufficient. To accommodate the higher USDT target liquidity, we propose that the DAO adjust incentive emissions for the USDT Umbrella modules. With these changes, the maximal emissions would be increased by 920K aUSDT per year, partially offset by a reduction of 400K GHO per year in GHO module emissions. This adjustment would preserve the current APY ranges, maintain spend efficiency for the DAO, and ensure continued attraction of sufficient staked liquidity. No changes are recommended for the WETH module at this time, as its deposits remain comfortably above the target coverage level, and neither a target liquidity increase nor additional incentives are required to sustain participation. Expansion of Umbrella Modules There are currently 32 assets on Aave V3 Core with non-zero borrow balances that are not yet included under Umbrella coverage. However, only a subset of these, six assets, have borrows exceeding $50M, making them the most relevant candidates for near-term inclusion. These include wstETH ($1.1B), USDe ($882M), WBTC ($220M), DAI ($133M), RLUSD ($88M), and USDtb ($54M). Based on observed growth trends, several stablecoin borrow markets, notably USDe, RLUSD, and USDtb, have shown meaningful increases in 2025. As part of the next phase of Umbrella expansion, we propose adding wstETH, USDe, and WBTC to the coverage framework, while continuing to monitor the other emerging stablecoins for future inclusion. Following the addition of these three assets, the Umbrella Safety Module would encompass assets that collectively account for approximately 98.12% of total borrows on Aave V3 Core, equivalent to $20.9B in outstanding debt. After this expansion, only $390M in borrowings would remain outside Umbrella's scope. The table below outlines our target liquidity recommendations for the proposed assets. | Asset | Current Borrow Cap | Liquidation Capacity | Recommended Target Liquidity | Total Debt Coverage | Coverage of Borrow Cap | |----|----|----|----|----|----| | wstETH | 480,000 wstETH | 2,950 wstETH | 9,050 wstETH | 12,000 wstETH | 2.5% | | USDe | 2,500,000,000 USDe | 0 USDe | 43,920,000 USDe | 43,920,000 USDe | 1.76% | | WBTC | 28,000 WBTC | 454 WBTC | 250 WBTC | 704 WBTC | 2.51% | According to our methodology, the liquidation capacity for USDe is effectively zero, partially due to insufficient market liquidity to liquidate USDe borrow positions profitably under shock scenarios. Albeit, USDe exhibited zero shock deviation, suggesting stable pricing behavior even in stressed conditions. In contrast, wstETH showed the highest simulated price shock at -0.058%, which still represents a relatively mild drawdown. WBTC demonstrated greater resilience, with a smaller shock value of -0.04%, indicating stronger stability during market stress situations. To support the inclusion of these new assets into the Umbrella Safety Module, we estimate the following maximum annual emissions required to maintain sufficient risk-adjusted yield at target liquidity levels: 50 awstETH (\~$255K), 773K aUSDe ($780K), and 0.5 aWBTC ($57K), targeting Umbrella APY of 0.55%, 1.76%, and 0.2% at target liquidity. This would result in an additional annual cost of approximately $1.09M to the DAO. Conclusion & Recommendations We recommend the following adjustments and additions to the Umbrella Safety Module to better align with current market conditions and borrow activity. Once implemented, these changes will increase the total annualized Umbrella emissions from $8.74M to $10.35M, while expanding coverage by an additional $192M. Reserves amounting to 98.12% of total borrows on Aave V3 Core would become covered by Umbrella. Ultimately, this increase in emissions would be offset by the ongoing deprecation of legacy staking modules, which currently cost the DAO approximately $42.6M per year. Therefore, this transition reflects a more capital-efficient and scalable approach to risk management within the Aave protocol. Revised Recommendations | Staked asset | Covered asset | Target Liquidity | Max emission (rewards at target liquidity) | Umbrella APY range (up until excess liquidity) | Total APY (Aave + Umbrella)\* | Cooldown/unstake window | Deficit offset | |----|----|----|----|----|----|----|----| | aUSDe | USDe | 20,000,000 USDe | 550,000 aUSDe/year | 1.83%-5.5% | 6.14%-9.81% | 20/2 days | 100,000 USDe | | aWBTC | WBTC | 250 WBTC | 1.5 aWBTC/year | 0.39%-1.2% | 0.42%-1.23% | 20/2 days | 0.5 aWBTC | | aUSDT | USDT | 104,000,000 USDT → 130,000,000 USDT | 3,670,000 → 4,587,500 aUSDT/year | 2.35%-7.05% | 7.37%-12.07% | - | - | | GHO | GHO | 12,000,000 GHO → 8,000,000 GHO | 1,200,000 → 800,000 GHO/year | 6.66%-20% | 6.66%-20% | - | - | \* Aave APY reflects the 1-year average Supply APY. Based on the revised parameters, the updated borrow coverage for the newly onboarded assets, USDe, and WBTC, is as follows: | Asset | Current Borrow Cap | Total Debt Coverage (Liquidation Capacity + Target Liquidity) | Coverage of Borrow Cap | |----|----|----|----| | USDe | 2,500,000,000 USDe | 20,000,000 USDe | 0.8% | | WBTC | 28,000 WBTC | 704 WBTC | 2.51% | Next Steps Incorporate feedback and escalate ARFC to a Snapshot vote. If the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Disclaimer This review was independently prepared by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk is not directly affiliated with the protocol(s) reviewed in this assessment and did not receive any compensation from the protocol(s) or their affiliated entities for this work. The information provided should not be construed as legal, financial, tax, or professional advice.

[ARFC] Remove USDS as collateral and increase RF across all Aave Instances Author: ACI Date: 2025-11-17 --- Summary This ARFC proposes removing USDS as collateral and increasing RF across all Aave instances. USDS generates negligible revenue while its issuance model introduces asymmetric risks that could impact Aave's stability. The proposal implements the following: Set LTV to 0%. Set reserve Factor to 25%. Removal from all stablecoin e-Modes. Motivation Motivation for these changes is driven by both reducing revenue from USDS borrows, and changing risk profile bringing into doubt the suitability of the asset as collateral. 1. Low Profitability Data shows a decline in revenue each month, with $543,528 since Q1 2025, and current annualised revenue of $135,260 based on revenue since the beginning of Q4. With quarterly revenue data showing a sharp decline since the beginning of the year, we believe that current revenue is far below the scale required to justify current risk exposure. |Instance | Q1 | Q2 | Q3 | Q4| |--- | --- | --- | --- | ---| |Cove V3 | $87,948 | $127,768 | $96,556 | $17,417| |Prime V3 | $156,205 | $47,999 | $9,276 | $359| |Total | $244,153 | $175,767 | $105,832 | $17,776| To combat this decline in revenue we propose raising RF to 25% which would increase Aave revenue by +150% on the same borrow volume. 2. Potential Risks from Issuance Model With the new Stars being created within the Sky ecosystem, the risk profile of USDS is changing. Given these changes characterised by credit lines at low or zero cost, and the risk surface area presented by the yield strategies being utilised, we believe that the risk profile has increased to a degree which is outside of what is acceptable for Aave collateral. Alongside the increase in RF we propose setting LTV to 0% in order to remove Aave’s exposure to USDS as collateral. Combined, we believe these measures bring the risk/reward of USDS back in line with other assets on Aave. Specification Pending confirmation by Risk Service Providers we propose the following parameter updates: | Instance | Current LTV | Proposed LTV | Current RF | Proposed RF | | --- | --- | --- | --- | --- | | V3 Core | 75 % | 0 % | 10% | 25% | | V3 Prime | 0% | 0% | 10% | 25% | Alongside the above we propose that USDS is removed from all e-Mode configurations across all instances. Proposal will be updated with latest Risk Service Providers feedback. Disclaimer The current proposal has been created by ACI independently. ACI 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 under CC0

[ARFC] Winding down Lend & Migration Contract Date: 2025-09-15 Author: ACI --- Summary The current proposal intends to terminate any operations related to Lend and the Migrator Contract, realloacting all unspent budgets, assets, and any remaining token/emission into the Ecosystem Reserve, while ensuring minimal disruption to users and/or integrations. Motivation This proposal is following up on promises made in Aavenomics Part 1, freeing almost $100 million worth of AAVE to be used for further ecosystem growth and partnerships. As announced multiple times over the past years and half a decade after opening the LEND to AAVE migration contract, it’s time to close the LEND chapter and focus on AAVE. This proposal will remove all remaining AAVE—305k tokens at the time of writing—from the migration contract and redirect them to the ecosystem reserve. Given that the community has had multiple years of notice, we consider it fair to close down the migration process. Additional communication and clear timeline for ending migration window is outlined below. Specification If the proposal pass the effective timeline of final possible migration to be December 31, 2025. Relevant service providers will engage in final communication campaign with the final migration date. Migration contract should be turned for shut down on December 31, 2025. All remaining AAVE tokens within migration contract should be redistributed back to the Aave DAO treasury. Further ARFC can then be proposed for relevant distribution of AAVE tokens for growth and ecosystem incentives. Useful Links: https://etherscan.io/address/0x317625234562b1526ea2fac4030ea499c5291de4 Discloure ACI is publishing this proposal independently, and did not receive any type of compensation for its creation. 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, work with relevant service providers to communicate and implement the timeline proposed in this ARFC. Copyright Copyright and related rights waived via CC0.

Introduction Introducing Chaos Risk Agents, a new governance-aligned orchestration and validation middleware between Risk Oracles and the Aave protocol, designed to consume risk updates while preserving full control under DAO ownership. Developed jointly by Chaos Labs and BGD Labs. The Risk Agents framework enables: Same strict on-chain validations for injecting Risk Oracle values into Aave’s production protocol. Support for both generic validations (e.g., delays) and custom logic (e.g., numeric threshold constraints). Simplified setup and management of Risk Oracle data consumption. A single Agent Hub smart contract per network governs small self-contained smart contract adapters (Agents) for each type of risk recommendation update. Better isolation of permissions, with each Agent receiving only the permissions required to execute its task. Full Aave DAO ownership and control, with the ability to accept or reject Risk Oracle updates. Context Over the last two years, Aave has progressively integrated Risk Stewards—an infrastructure layer comprised of smart contracts capable of making limited adjustments to parameter configurations. The goal of Risk Stewards is to streamline well-defined parameter updates without requiring governance proposals, while maintaining strict operational and security boundaries. Presently, Risk Stewards are responsible for processing risk recommendations for a range of parameters including supply and borrow caps, interest rates (e.g., slope2 values), and CAPO values across multiple assets and Aave instances. These updates are executed either manually by risk providers (i.e., “manual” risk stewards), or through Chaos Risk Stewards, which directly plug into Risk Oracles to expose real-time recommendations not limited by operational overhead. While the existing system has served Aave more than well, several limitations exist: Limited generalization: Almost every Risk Stewards activation requires ad-hoc replication of the entire architecture. This results in meaningful overhead for Aave SPs (e.g., ACI, Chaos Labs, BGD Labs). Limited infrastructure visibility: Tracking all active Risk Stewards, as well as their covered assets and constraints, can be challenging at times. Current Risk Stewards Architecture The Chaos Risk Agents framework generalizes and modularizes the process of ingesting Risk Oracle data within Aave. It eliminates redundant deployments, centralizes validation logic, and improves visibility across all risk automation layers. The result is a cleaner, more maintainable architecture that allows Aave to expand real-time risk management capabilities, ensuring consistent, verifiable execution of parameter updates. Specification Architecture Risk Agent Base Architecture The architecture involves four components: Risk Oracle. This component is technically external to the Risk Agents framework, and provides risk recommendations that validate and apply in the target system. Target system. The Aave protocol or any of its internal components. More precisely: - The data source for the current protocol’s data. Smart contract exposing the currently applied risk configurations on the target system. E.g., the Pool on Aave v3. - Configuration target. Smart contract with logic to apply new risk configurations on the target system. In Aave v3’s case, this would be the Pool Configurator. - Access control registry. The smart contract granting roles for each agent, and with full control over whether they can do anything over the protocol. In the case of Aave v3, this would be the ACLManager smart contract. Agent Hub. Singleton smart contract to be (optionally) shared by all systems of Aave in one network: - Registers/configures independent agents. - Validates mandatory/optional global constraints, for example, minimum delays. - Entry point for automations. - Defines the global lifecycle of validation/injection. Agent contracts. Independent smart contracts, designed to be compact. With self-contained, specific logic to execute the programmed risk updates. Agents include mainly ad-hoc validations for the specific type of update, and “interpretation” on how to inject the update into the protocol, once/if validations pass. Risk Stewards Architecture (with Chaos Risk Agents) --- In addition to the immediate benefits to the production systems on Aave v3, the Risk Agents middleware provides a generalized framework that can be applied to any other system requiring it on Aave in the future. For example, any risk parameter configuration on GHO, like some of the existing GHO stewards, can be easily migrated to use the same Aave Agent Hub or a separate instance. The same applies to any risk configuration on the upcoming v4 protocol. Generic modules Frequently, certain types of validations are common between different risk parameter updates, for example, those involving numeric constraints like caps. However, these validations are less generic than the ones available on the Hub. For that reason, the Risk Agents middleware also introduces the concept of Generic Modules: smart contracts that can be built and deployed once, allowing different Agents to plug into them for additional validations, removing the need to reimplement/redeploy them from scratch on every instance. An example of such of a Generic Module is the RangeValidationModule , which allows for an agent to send a reference integer value, a new value, and validate that the latter is within an allowed range. The module is aware of the optional multi-market nature of each Agent (e.g., caps updates for all assets of a v3 pool), so it also allows both defaults and granular configurations of constraints. Security Risk Agents have been independently audited already by Zellic. Additionally, we encourage security providers of the community (e.g., Certora) to review the final Risk Hub/Agents Aave’s instance, being already familiar with the existing Risk Stewards. Active Risk Oracles All existing and future Risk Oracles deployed on Aave will be integrated with and interact with Aave through the Chaos Risk Agents infrastructure. The set of currently active/approved Risk Oracles are as follows: | Oracle | Function | Parameter(s) Set | Relevant Assets | | --- | --- | --- | --- | | Slope 2 Dynamic Risk Oracle | Adjusts the borrowing cost of yield-bearing assets in the event of sudden liquidity shocks | slope2 | USDC, USDT, USDe, and wETH on Ethereum Core and Linea; Full list here | | CAPO Risk Oracle | Governs price cap on yield-bearing assets relative to base asset | maxYearlyRatioGrowthPercent, snapshotRatio | Yield-bearing assets (e.g., LSTs, LRTs) across all Aave Instances | | Pendle PT Risk Oracle | Determines discount rate for asset pricing and governs liquidation mechanics for PT-assets based on asset maturityKillswitch to halt lending activity in oracle mispricing / liquidity exhaustion scenarios | liquidation threshold, LTV, liquidation bonus , discount rate | PT Assets (PT-sUSDe, PT-USDe) | | Interest Rate Risk Oracle (WETH) | Adjusts the borrowing cost of WETH on Prime | slope1 | WETH (Prime Instance) | | Supply/Borrow Cap Risk Oracles | Adjusts supply and borrow caps based on various factors including market health, utilization, and available liquidity | supplyCap , borrowCap | Various assets across all Aave instances | 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.

[TEMP CHECK] Onboard Strata srUSDe January expiry PT tokens to V3 Core Instance Author: ACI Date: 2025-11-04 Summary This proposal seeks to onboard the Strata srUSDe January expiry PT tokens to the Aave V3 Core Instance. 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. With current srUSDe PT token TVL of $134m, it is one of the larger Ethena ecosystem PT tokens. Given recent reduction in sUSDe yield, 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 PT-srUSDe-15JAN2026: https://etherscan.io/address/0x1fb3c5c35d95f48e48ffc8e36bcce5cb5f29f57c 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 proposal to gather community and Service Providers feedback. 2. Publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived under CC0

Summary As outlined in the AL Service Provider Proposal, the security effort for Aave V4 was expected to proceed via a separate proposal. This ARFC asks the DAO to ratify a security budget of up to 1.5M. Aave Labs will pay invoices upfront and later request reimbursement via the Aave Finance function in proof of every invoice. The scope covers a layered security program coordinated around V4’s feature‑complete codebase, including independent researcher reviews, multiple manual reviews by audit firms, formal verification campaigns, invariant test suite, and a security contest. Motivation Aave V4 reached feature complete in July and entered internal review with multitrack security preparations. DAO service providers received early access to the prototype for targeted testing. This budget funds the final phase of external review and hardening ahead of public testnet and mainnet rollout. Relative to 2021–2022 reviews on V3, market pricing has expectedly risen. However, because V4’s codebase is smaller and more modular, auditor quotes were actually lower than initially expected. While no code is flawless, the program is designed to materially mitigate risk through layered review, formal methods, and adversarial testing. Specification Scope A layered program designed to strengthen V4 through diverse methodologies and independent perspectives: 1. Independent Security Researchers * Four private reviews, targeted code reviews focused on critical paths, edge cases, and integration surfaces. * One public manual review covering the full protocol. 2. Manual Review (multiple firms) * Four end‑to‑end manual reviews covering the full protocol are expected, although more may be needed. * Staggered and overlapping schedules to reduce correlated blind spots. 3. Formal Verification (Certora) * Property‑based proofs on core contracts and safety invariants aligned to the V4 feature set. 4. Invariant Test Suite (audit firm) * Design and implementation of a reusable invariant suite, with fuzzing and scenario generators to strengthen continuous testing during maintenance. 5. Security Contest * Community contest on a curated scope to surface adversarial insights and broaden reviewer diversity. RFQ and Selection Process A two‑round, tight‑scoped RFQ was conducted, receiving 20 total proposals from firms and independent researchers. Round 1 gathered baseline quotes and methodologies; Round 2 focused on cost efficiency. Final selections were made based on experience, methodology, and budget. Budget and Payment Terms Cap: Up to 1.5M (GHO‑equivalent) for the complete V4 security program described above. Pre‑financing: Aave Labs will pay all invoices upfront. Any unused funds, from the approved cap, that are not invoiced, will be kept by the DAO. Reimbursement: Through the Aave Finance function, against itemized actuals up to the approved cap. Cancellations: Any audit engagement deemed no longer necessary will be cancelled, not submitted for reimbursement and reallocated back to the Aave DAO. Disclaimers Aave Labs submits this as a technical service provider. Decisions on funding and deployment rest with the Aave DAO. Copyright Copyright and related rights waived via CC0.

Simple Summary Present to the Aave DAO a proposal for BGD to renew our involvement as a development and security coordinator services provider (previous finished 1st October 2025), together with a new contribution direction: (codename) Project E. --- --- Motivation During the last months, it has become evident that the DAO is in a pretty different stage than it was before, amongst others: Arguably, for the first time, all sub-systems of Aave are in a very advanced stage of maturity: the liquidity protocol, governance, safety module (Umbrella), the GHO stablecoins, and cross-chain communication. We want to believe this is partially due to our contribution to them. Since our initial proposal of Aave <> BGD Labs, even as a technical contributor, we have advocated for budget sustainability (e.g., projects like Umbrella are testimony to it). The ecosystem is economically better than ever, with growing (+$140m estimated) yearly revenue, and high-profit margins even if continuously investing in growth. It is easy to make the case for the Aave DAO to be the most sustainable decentralised DeFi system out there, at scale. From discussions in this forum last months, in what concerns the liquidity protocol product, the focus of the DAO will tend to be progressively towards the upcoming v4 version by @AaveLabs. v3 will remain fully functional and performant for the foreseeable future, but we understand the priority will not be improving it radically anymore. The organisation of the DAO and its contributors seems to be evolving, in kind of an inflection point (e.g., topics proposed discussed HERE). This directly affects our contribution line to the DAO, being a service provider until now, touching almost all components of it during the last 3 and a half years. After having completed our previous engagement for services now on 1st October (recap HERE), we now present a two-sided follow-up proposal adapted to the current state of the DAO and BGD Labs: 1. A similar component on previous renewals focused on maintenance and continuous development of different components of the Aave ecosystem. 2. Introducing to the community Project E, a different line of product by BGD Labs, but highly related to Aave. --- --- Specification Part 1. Aave <> BGD Phase 6 continuous scope Our proposed scope of services includes the following: Development/activation of any Aave v3 upgrade during the engagement duration. In addition to finishing development and security procedures on the proposed v3.6, we will activate that version in production if governance approves. Additionally, even if Aave v3 should not have many more big-scope upgrades, we will develop any upgrade we think is required during this period, e.g., if any security-related issues arise. More expansions of Aave to new networks. Even if the community has been more selective during the past months regarding new networks to host Aave, precisely at the end of our Phase 5, one of them has shown tremendous success: Aave v3 Plasma. We believe the role of service providers like us working on this expansion behind the scenes to meet pretty tight timelines while maximising quality is in good part to blame for this success. During this new Phase 6, we will continue working on expansion to new networks, some of which are already in the works. Friendly forks support. During Phase 5, we defined, executed, and coordinated extensive procedures for friendly forks requiring high support from the DAO to configure and run their instance. One of them (Ink) will enter its final phase pretty soon, and then our role will be that of technical coordinator from the Aave DAO: supporting the usage of the infrastructure of the DAO, upgrades, proposals, and any required ad-hoc advice. Additionally, we will have the capacity to support via this flow one extra friendly fork requiring similar terms to Ink’s. Umbrella expansion. During the previous Phase 5, we have developed Umbrella v1.1, to be presented to the community in the following days. During this upcoming Phase 6, we will prepare and activate this new version in production if governance approves. Additionally, now that Umbrella is consistently on Target Liquidity for the initial assets, we will proceed with the expansion of the system to other networks. a.DI improvements. We will work on some improvements on a.DI (Aave Delivery Infrastructure), in this case, focused on having extra security and reliability. Technical components of v2 off-boarding. During Phase 5, we have progressed to the final phase of Aave v2 deprecation, with all assets soon to be frozen, and other technical changes (e.g., changing Close Factor to 100%) also performed. During Phase 6, we will support the DAO with the rest of the steps deprecating v2, to reduce the number of versions running in parallel once v4 is in production with v3. Technical analysis of assets to be listed on Aave. During Phase 5, we kept improving the asset analysis flow, not only in content, but also, for example, doing ad-hoc analysis on cross-chain versions of the same asset, something more common lately for listings. Additionally, we initiated new quality flows like the AAcA (Aave Asset Class List), directly related to assets’ analysis. During Phase 6, we will continue working on this side of the asset onboarding stream. Support risk teams from the technical side. We will support risk teams using the technical infrastructure to do risk changes, mainly via the risk stewards flow (manual, automated). As commented on the Phase 5 recap, we have already prepared a technical revamp/simplification of the risk stewards, so during Phase 6, we will activate it and migrate all the previous components via a maintenance proposal. Additionally, we will support risk teams in any reasonable technical requirement oriented to risk. Governance proposals reviews. Similar to previous scopes, we will keep reviewing governance proposals before they go on-chain, a flow that gives a lot of value to the community, by: - Reviewing all proposals by other SPs before they are created on-chain. This gives a very high assurance that everything being voted on is secure and of quality. - Simplifying the review of on-chain reviewers (Certora), allowing them to focus on the most critical aspects during the limited voting period. - We have a very important presence, also advising other contributors on how to better organise proposals, not only pure code review. Continuously improve DAO’s tooling. Similar to any other previous phases, we will keep improving the different tooling of the DAO: aave proposals, helpers, Aave Seatbelt, address book, permissions book, and all others. Iterate on the SVR direction. During Phase 6, we expect SVR to expand to new networks, and we will support both the DAO (execution-wise) and Chainlink (advising from the Aave DAO perspective) during the process. Aave protocol security coordinator (bug bounty, Safe Harbor, ad-hoc initiatives). During Phase 6, we will act as reviewers on the Aave bug bounty program in the same projects as until now, and in addition, we will present to the community a different bug bounty framework, streamlining/optimizing all procedures. We will also act as technical contact from the DAO side for the Safe Harbor agreement in relation to all projects we are involved. Participate in the planning of any potential v3 off-boarding strategy. If the DAO approves any off-boarding plan of v3 in favour of v4 in the future, we can support by advising the DAO on what, in our opinion, is a responsible way of doing it, without disturbing operations of the DAO. --- DURATION: given that the Aave v3 lifetime is not clear at the moment, the duration of the scope for services is still the same as previous scopes, 6 months, but with an extra longer stream component to not have any interruption of services afterwards, but that can be cut unilaterally by any of the parties (DAO/BGD Labs) at any point. The start date is when the previous engagement ended, 1st October 2025. BUDGET: 2’200’000 in stablecoins and 3’000 AAVE, 60% paid up-front and 40% streamed during the 6-month engagement. We have reduced the budget (approximately 10%) from previous scopes, as the changes on the v3 side are expected to be less frequent/sizeable by default. If this would not be the case, we would propose a separate budget correction. --- What is NOT part of the scope Similar to previous phases, we want to be explicit on what is not included in our line of contribution: We are a technical provider of the community; we don’t do any type of business development/or growth, which should be the responsibility of other parties. We don’t do formal security reviews on major developments of other contributors. We offer our security advisory for projects solely benefiting the Aave DAO, but on bigger scopes (e.g., Aave v4), that is up to parties engaged specifically on security, like Certora or other external third parties. We will only provide best-effort feedback on the design of projects that we don’t lead, but it is not our responsibility to make any type of design decisions or move them to production, unless we think it is reasonable for us to do so. E.g., in a case like sGHO on our previous Phase 5, we spent more resources reviewing again and again a project that was compensated to another service provider, which we would have done ourselves from scratch. And that is detrimental for both the DAO and ourselves. We only work on projects with a TEMP CHECK Snapshot passed (e.g., reviews). With the activity on the DAO increasing day by day, unless a filtering of projects is applied, it is not manageable for us to support any project in the pre-TEMP CHECK stage, unless we identify a clear need from our side. This scope includes EVM-only contributions. Any non-EVM ad-hoc requirement would need to be evaluated aside, as it is not our core expertise and would affect the delivery of all items in scope. We are not running services on behalf of the DAO; we design them to be run in a decentralised manner, or by parties with the proper role to do so. Any tool we decide to run on our infrastructure (e.g., hosting of one instance of the Aave Governance v3 interface or Umbrella’s) is our own decision, outside of the scope of engagement. We don’t produce centralised backend services for the DAO. We prepare the existing technical infrastructure (e.g, Aave v3 instances) for a system fully controlled by the Aave DAO, or if following a friendly fork framework, whenever the configuration is not totally custom (e.g., main pool dynamics heavily changed, major custom code components and flows). A full explanation of our approach to friendly forks is HERE. We only build user interfaces for the DAO on those projects that we believe are simply not complete without that part of the infrastructure. For example, we think a project like Umbrella requires the DAO to own a UI, no matter who then runs it. Similar applies to the Aave Governance v3 UI. But for any additional cases, we reserve the right to decide if any interface infrastructure is produced for the DAO or is exclusive property of BGD Labs, whether those using Aave smart contracts or not. Terms of Service A formal Terms and Conditions document for the engagement for services between the Aave DAO and BGD Labs can be found HERE. However, we would like to highlight again the same high-level points as in the previous phases: Major projects’ IP and licensing belong to the Aave DAO. The core software (e.g., all on-chain smart contracts to be used by the DAO in production after governance proposals) we create during our continuous engagement are licensed to the Aave DAO governance smart contracts, both using the BUSL approach as on Aave v3 Origin, or more open source licenses if we think expanding the usage of Aave peripheral technology only helps the DAO. To insist on the previous fundamental implication: - The Aave DAO is the sole owner of the intellectual property and licensing of those projects. - It is entirely up to the DAO to decide how to use and/or commercialise them, not BGD Labs. - Our benefit from those projects is the fee we receive from the DAO for developing the software. BGD doesn’t decide what gets activated/applied in Aave. We create the software and the technical proposals to activate said software, but it is and will always be up to the DAO governance to decide if that software should be enabled in production. No software is flawless, but we pursue it. Historically, no major problem has been detected in the developments we did for the DAO, but it is impossible to assure from our side that all software will be flawless. However, we have a firm commitment to always following solid security standards and procedures, to minimise any potential impact. We compromise to not work with competitors of Aave on any core business that could hurt the DAO. We are an independent company with potentially our own projects outside of this scope, but given our involvement, especially in the core Aave v3 protocol, we agree not to provide services to any competitor of Aave (other DeFi lending protocols) in core smart contracts development or security during these 6 months in scope. --- --- --- Part 2. Introducing Project E Project E (codename) is a suite of DeFi products to be created and owned by BGD Labs, some of them using Aave technology as a base, while others not Regarding those Project E projects using Aave technology as base, this will include, amongst others: One or multiple Aave v3 instances, exploring different use cases and configurations (e.g., types of assets listed, like RWAs, or other more DeFi exotic assets) that are not suitable for Aave DAO instances. Same as other cases like Horizon, this will require customisation on top by BGD. In the future, and depending on how Aave Labs proposes a model of usage of v4, potentially Aave v4 spokes will be curated/customised/controlled by BGD Labs. What is the rationale of Project E? The strength of BGD Labs is being independent, regardless of whether it historically only contributed to the Aave DAO. We see Project E as a suite of future products owned by BGD Labs, meaning keeping full independence from anybody else. This allows us to have pure creative freedom, while (more details later), giving back to the DAO. By having full control of our own instance/s, similar to other cases like Horizon, we can cover extra use cases and configurations, while the Aave DAO benefits from technology adoption. We really believe Aave technology is top quality, so it is just natural for us to use it in the Project E suite of projects as one of the bases. In practice, this means we propose getting permission from the DAO to use the active version of Aave v3 (v3.5 or v3.6 if approved), akin to other projects like Horizon or Ink’s instance, but also other formats like being whitelisted to customise/curate/run spokes on the upcoming v4 model, or maybe using the Aave Umbrella codebase. What are the terms? A more detailed version of the terms can be found HERE, but the following is a summary of its substance. Aave DAO → Project E Project E gets permission to use the current Aave technology as a base of its products, for example, licensing on the Aave v3 codebase. Project E carries no cost to the DAO: no type of upfront payment/stream from the DAO to BGD Labs, no incentives, no security expenditures, no required participation from service providers to the DAO; zero. The point is that BGD Labs compensates the Aave DAO with revenue sharing for using the technology and/or participating in its dynamics (e.g., v4 spokes); not the DAO paying BGD Labs for doing it. Aave DAO <- Project E For the lifetime of any Project E system using as a base core Aave DAO contracts (or using Aave DAO infrastructure, like e.g., v4 spokes), 55% of all the on-chain revenue generated by that system goes back to the Aave DAO; 45% to Project E. In what concerns the usage of future v4 infrastructure in the future, we are glad to abide by any to-be-defined terms by the community in the future, for entities running spokes or other models, as long as those terms are fair and equalitarian for everybody. For the sake of clarity and given the community opposition in the past, no product of the Project E suite using base Aave DAO technology (e.g., v3 codebase, running/curating a v4 spoke, etc) will have any new token like AAVE associated with it. The Aave DAO is free to backport changes from Project E systems base on Aave technology to its own insfrastructure. --- FAQ And FAQ can be found on the associated forum post HERE --- --- Disclosures BGD Labs has no meaningful commercial relation with entities that could create any type of conflict of interest within the scope of this proposal. --- --- Next steps If this proposal is approved here on Snapshot, proceed with AIP for the component requiring transferring the budget for the services to be provided by BGD Labs.

[ARFC] AAVE Buybacks program: An update Author: ACI (Aave Chan Initiative) Date: 2025-10-22 --- Summary This ARFC proposes to enshrine a long-term AAVE buyback program funded by protocol revenue. The program will establish a $50M annual budget with flexible execution parameters, enabling strategic capital deployment by the Aave DAO to further accumulate AAVE tokensnd extending the existing buyback program indefinitely. Motivation The Aave Protocol has demonstrated strong revenue generation and treasury growth. With the expiry of the existing buyback initiative, and the strong success of the program, we think it is a opportune time to enshrine a buyback program to further ehance Aavenomics. The systematic buyback program will continue to add: 1. Value Accrual: Create consistent buy pressure for AAVE tokens using protocol revenue. 2. Treasury Optimization: Convert idle assets into productive capital supporting ecosystem growth financed by debt. 3. Market Stability: Provide programmatic demand with adaptive execution based on market conditions. Specification: Program Structure Annual Budget: $50,000,000 Lead: Tokenlogic and Aave Finance Committee (AFC) Weekly Execution Range: $250,000 - $1,750,000 in AAVE purchases The AFC will have discretion to adapt buyback volume within a 75% range, based on the following factors: - Market conditions and liquidity - Token price volatility - Strategic timing considerations - Available protocol revenue Tokenlogic will be leading the program with the support of AFC and ACI. Leveraging AFC reserves for growth The AFC will have the mandate to operate AAVE, wBTC, and wETH reserves to support growth initiatives by debt creation. The HF of these positions must always be maintained above 2 as a floor, and higher as the maintenance debt level. This proposal gives mandate to the AFC to mobilize currently unstaked wETH from the frontier program to finance growth initiative as collateral This proposal gives mandate to the AFC to mobilize collector held BTC-equivalent reserves to finance growth initially. The AFC has a mandate to create credit lines using the AAVE codebase exclusively, such as main Aave instances and approved by governance friendly forks, convert to yield-bearing equivalents, and vote delegation with its reserves. Funding Sources Protocol revenue allocation ($50M/year) Useful Links [[ARFC] Aavenomics implementation: Part one](https://governance.aave.com/t/arfc-aavenomics-implementation-part-one/21248) Disclosure ACI (Aave Chan Initiative) has not received 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] Orbit Program Renewal - Q3 and Q4 2025 Author: ACI (Aave Chan Initiative) Date: 2025-10-21 --- Summary Proposing the renewal of the Orbit program for recognized delegates, compensating them with GHO, associated with their governance activity during Q3 and Q4 2025 ( From 2025-07-01, last date, until 2025-12-31). The reason 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 Q3 and Q4 2025, from 2025-07-01 to 2025-12-31. As a reminder from previous Orbit round, 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. From now on, Orbit periode coverage will be semi-annually or 2 times per year (Q1 and Q2 together, and Q3 and Q4 together), with the aim of reducing governance bloat. Specification Period Coverage: Q3 and Q4 2025 from 2025-07-01 2025 to 2025-12-31 Eligible Platforms: - EzR3al: 0x8659d0bb123da6d16d9394c7838ba286c2207d0e - stablelabs: 0xecc2a9240268bc7a26386ecb49e1befca2706ac9 - IgnasDefi: 0x3DDC7d25c7a1dc381443e491Bbf1Caa8928A05B0 Budget: 90,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] Evolving Resilience: Security Services for Aave Current Infrastructure <> Certora Author: Certora Date: October 7, 2025 Summary Since March 2022, we’ve maintained a continuous partnership with the DAO. Now halfway through our fourth year, Aave is stronger than ever — with continued potential for growth. We propose a 12-month extension of our engagement as primary security partner for Aave’s current infrastructure, continuing to safeguard protocol governance and assisting with incident response. Our proposal for supporting Aave v4 is posted separately. To support the maintenance of Aave’s current infrastructure, we propose: 1. Full ownership over AIP reviews - reviewing every AIP initiated on-chain. 2. 24/7 availability for incident response, supporting the technical providers in the investigation and mitigation of emerging bugs. 3. Acting as a signer in both the governance guardian and the protocol emergency guardian. All reviews of smart contract changes to new or existing infrastructures and products are outside the scope of this agreement, and will be contracted on an as-needed basis at the weekly rate listed below. This proposal also does not include any work on Aave v4, which we have addressed in a separate proposal. Note that this proposal is based exclusively on BGD Labs’s suggestions and prior discussions related to security needs. We have currently dedicated a team of 3 full-time equivalents for audits and one part-time resource to governance reviews (~40 days/year or ~0.1 FTE), which we manage as a team of 6 people who are fully ramped and available to support Aave v3, providing the redundancy necessary for 24x7x365 support. In addition, Certora provides a dedicated Technical Account Manager who acts as the single point of contact for all aspects of the engagement. Looking forward to the coming year, we will allocate 0.2 FTE security engineers for governance reviews, and we will continue to maintain 1 technical account manager who acts as the single point of contact for all parties in the Aave ecosystem. We will also reserve a team of 2 security researchers who are available on demand for bug fix reviews and incident response. We expect this team to be available for consultation ~2.5 days/month. In addition, we will continue to participate as a signer in both the governance guardian and the protocol emergency guardian. Price The price for the above scope is $238k made in stablecoins. Payment shall be delivered via dedicated payment streams vested linearly over one year. A 30-day termination is possible after a vote. Smart contract audits for new or existing infrastructure and products are not included within this scope of work given that we do not anticipate any further upgrades to the existing infrastructure. If an upgrade that requires more than 2 days to review is required, we will scope and price such engagements separately using the 32%-discounted price of $20,400/week for a team of 2 experienced security researchers.Certora commits to initiate any requested audit project within two weeks from the date of the request. Price Explanation (provided for transparency) Our annual price for a dedicated security researcher or formal verification engineer is $780,000. Dedicating 0.2 FTEs to governance reviews and applying a 32% discount to our pricing, we arrive at a final price of $106k for our on-going governance support. We have also added an additional $11k/month for the coming 12 months to ensure Certora’s availability and on-going support for incident response and bug fix reviews. Combining the governance reviews and monthly retainer, we have a final price of $238k. No extra charge has been added for participating as a guardian. Disclosures In the interest of full transparency, we feel it is important to disclose that Certora is now working with the Compound DAO as one of 2 security providers supporting the DAO. To ensure the integrity of our service and to respect the confidentiality of our partners, we have assigned separate teams to each project and implemented internal procedures to ensure that Certora maintains an “ethical wall” to avoid any conflict of interest or information leakage between the teams working with the Aave and Compound DAOs. Background and Motivation In the past 3.5 years we have continuously served the DAO as a security provider, assisting with dozens of new feature deployments and protocol improvement upgrades Sept 2022 - Sept 2023, Sept 2023 - Sept 2024, Sept 2024 - Sept 2025, preventing several critical bugs from going live and assisting with mitigation of live bugs upon emergence. Alongside continuous security reviews and formal verification, we: 1. Conducted several focused research and investigation efforts of components and features within the ecosystem, sharing findings with developing teams and recommending remediations. 2. Led community efforts to review and formally verify new and existing Aave code. This included extensive education of the independent researchers community on the protocol and ecosystem as a whole. 3. Took full ownership of on-chain AIP reviews, reviewing so far 369 proposals, finding 12 bugs. 1. Continuously working with BGD Labs to improve their AIP review tooling - Seatbelt. 2. Developed a complementary tool called Quorum, that helps highlight potential failure points and ensure the robustness of the layered review process. 4. Assist in incident investigations and mitigation efforts. 5. Acting as signers for both the governance guardian and protocol emergency guardian, performing emergency and operational actions on numerous occasions. With the current engagement coming to an end, we propose our services for the fourth time, offering new contribution channels to the ecosystem in addition to the existing ones. Specification The payload will create a payment stream to the address 0x0F11640BF66e2D9352d9c41434A5C6E597c5e4c8 for a duration of 365 days starting from the date of the execution. Create a payment stream of $238,000 Gho to 0x0F11640BF66e2D9352d9c41434A5C6E597c5e4c8 The payment stream will vest linearly from the starting date mentioned above for 365 vesting days. Next Steps 1. Gather community feedback on this ARFC. 2. If consensus is reached, escalate this proposal to ARFC snapshot stage. 3. If ARFC snapshot outcome is YAE, escalate to AIP stage. Disclaimer Certora is presenting this ARFC independently and is not compensated by any third party for creating this ARFC. Copyright Copyright and related rights waived via CC0.

Title: [ARFC] Evolving Resilience: Security Services for Aave v4 <> Certora Author: Certora Date: October 7, 2025 Summary Since March 2022, we’ve maintained a continuous partnership with the DAO. Now halfway through our fourth year, Aave is stronger than ever — with continued potential for growth. We propose a 12-month engagement as Aave’s primary security partner for Aave v4, safeguarding protocol upgrades, preventing critical bugs, and ensuring smooth governance execution. Our offering includes continuous review, incident response, and tooling improvements, backed by a full-time team and three and a half years of proven results. Our proposal for continuing our support for Aave's current infrastructure is posted separately. We propose to extend our existing services to Aave V4, while further expanding our engagement to include the Aptos instance and on-going support for V4 pre- and post-release. The service includes: 1. A full-time dedicated team available to consult, research, and review maintenance work and new developments. 2. Full ownership over AIP reviews after the v4 production release - reviewing every AIP initiated on-chain. 3. 24/7 availability for incident response, supporting the technical providers in the investigation and mitigation of emerging bugs. 4. Acting as a signer in both the governance guardian and the protocol emergency guardian. Note that the scope includes all currently planned and future v4 instances for all supported blockchains, and our proposal is based exclusively on Aave Labs' suggestions and prior discussions related to security needs. We have currently dedicated a team of 3 full-time equivalents and one part-time resource to governance reviews (~40 days/year or ~0.1 FTE), which we manage as a team of 6 people who are fully ramped and available to support Aave, providing the redundancy necessary for 24x7x365 support. Given that Aave v4 is not yet released, we assume that governance proposal review for v4 will not be necessary until later in the term, and we have excluded the cost of v4 governance reviews from our current pricing. However, once v4 is released, we will provide governance reviews for v4, and we will update pricing for the subsequent year based on the volume of governance work. For the upcoming year of v4 support, we expect: 2 full-time equivalent security researchers available for smart contract reviews and governance reviews 1 full-time equivalent formal verification engineer In addition, Certora provides a dedicated Technical Account Manager who acts as the single point of contact for all aspects of the engagement. Looking forward to the coming year, we also propose the following extensions to our existing scope of work in an effort to continuously improve our security support for the Aave v4 ecosystem: Certora will assume responsibility for the configuration and management of all on-chain monitoring solutions. Our team’s in-depth knowledge of the functionality of the protocol and our insight into governance changes positions us uniquely to work with 3rd party monitoring tools to ensure high fidelity on-chain monitoring for the upcoming production release of v4. Certora will develop a high-coverage, fuzzed test suite for Aave v4 using the best tools available for invariant-based fuzz testing. Certora will develop and maintain this testsuite as part of our on-going audits of the v4 contracts. Our testsuite is designed to ensure comprehensive coverage of the threat model that we develop for each contract during our manual audits, and it will leverage any existing work already done on the v4 contracts. The combination of formal verification, manual audit, and fuzzing provide three different vectors of security coverage for each Aave v4 contract. This combined methodology (manual + formal + fuzz) is an innovative approach to ensuring web3 protocol security, and it is an approach that Certora is pioneering to elevate the industry standard for comprehensive protocol security. The addition of the two service components above adds an additional 1.5 FTE to our service engagement with the Aave DAO. Hence, Certora will be providing a dedicated team of 4.5 FTEs and 1 dedicated technical account manager to support Aave for the duration of this engagement. Price The price for the above scope is $2.39M made in stablecoins. Payment shall be delivered via dedicated payment streams vested linearly over one year. A 30-day termination is possible after a vote. Price Explanation (provided for transparency) Our annual price for a dedicated security researcher or formal verification engineer is $780,000. Certora will be providing a dedicated team of 4.5 FTEs for this engagement. Our existing engagement reflects a ~32% discount that we offer to Aave to reflect our commitment to Aave’s security. Unlike previous years, we request full payment using the Gho stablecoin as we believe that aligns best with the DAO’s preferences. Disclosures In the interest of full transparency, we feel it is important to disclose that Certora is now working with the Compound DAO as one of the main two security providers supporting the DAO. To ensure the integrity of our service and to respect the confidentiality of our partners, we have assigned separate teams to each project and implemented internal procedures to ensure that Certora maintains an “ethical wall” to avoid any conflict of interest or information leakage between the teams working with the Aave and Compound DAOs. Background and Motivation In the past 3.5 years we have continuously served the DAO as a security provider, assisting with dozens of new feature deployments and protocol improvement upgrades (Sept 2022 - Sept 2023, Sept 2023 - Sept 2024, Sept 2024 - Sept 2025), preventing several critical bugs from going live and assisting with mitigation of live bugs upon emergence. Alongside continuous security reviews and formal verification, we: 1. Conducted several focused research and investigation efforts of components and features within the ecosystem, sharing findings with developing teams and recommending remediations. 2. Led community efforts to review and formally verify new and existing Aave code. This included extensive education of the independent researchers community on the protocol and ecosystem as a whole. 3. Took full ownership of on-chain AIP reviews, reviewing so far 369 proposals, finding 12 bugs. 1. Continuously working with BGD Labs to improve their AIP review tooling - Seatbelt. 2. Developed a complementary tool called Quorum, that helps highlight potential failure points and ensure the robustness of the layered review process. 4. Assist in incident investigations and mitigation efforts. 5. Acting as signers for both the governance guardian and protocol emergency guardian, performing emergency and operational actions on numerous occasions. With the current engagement coming to an end, we propose our services for the fourth time, offering new contribution channels to the ecosystem in addition to the existing ones. Specification The payload will create a payment stream to the address 0x0F11640BF66e2D9352d9c41434A5C6E597c5e4c8 for a duration of 365 days starting from the date of the execution. Create a payment stream of $2,390,000 Gho to 0x0F11640BF66e2D9352d9c41434A5C6E597c5e4c8 The payment stream will vest linearly from the starting date mentioned above for 365 vesting days. Next Steps 1. Gather community feedback on this ARFC. 2. If consensus is reached, escalate this proposal to ARFC snapshot stage. 3. If ARFC snapshot outcome is YAE, escalate to AIP stage. Disclaimer Certora is presenting this ARFC independently and is not compensated by any third party for creating this ARFC. Copyright Copyright and related rights waived via CC0.

[ARFC-Addendum] Update Merit for Round 33 - Adding Gate.io Author: ACI (Aave Chan Initiative) Date: 2025-10-13 --- Simple Summary This addendum proposes updates to the Boosters and reward structure for Merit Round 33, again, after successfully voted and passed [[ARFC-Addendum] Update Merit for Round 30](https://governance.aave.com/t/arfc-merit-a-new-aave-alignment-user-reward-system/16646/99), to add Gate.io. Motivation Since the new Aave Aligned Frens Booster » boost has been implemented, to reflect new partners, we need to update the ARFC Addendum. Specification Boosters Update The following changes will be applied: Aave Aligned Frens Booster will be to Infinity and Gate.io 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 applied to Merit Round 33. Disclaimer The Aave Chan Initiative independently proposes “Merit” without external compensation. Copyright Copyright and related rights waived under Creative Commons Zero (CC0).

itle: [ARFC] USDC (old) deprecation on Gnosis Chain Instance Author: @kpk Created: 2025-09-30 EDIT: Changes in the proposed parameters, following feedback from Risk Service Providers. Summary This publication proposes the deprecation of the legacy USDC market on the Aave Gnosis Chain deployment. The deprecation will be executed by freezing the reserve (preventing new deposits, borrows, or collateral usage) and immediately increasing the Reserve Factor (RF) to 80%. This aligns with the broader ecosystem effort to establish USDC.e (Circle-supported) as the canonical USDC representation on Gnosis Chain, consolidating liquidity and improving capital efficiency across Aave markets. --- Motivation The Gnosis Chain ecosystem has grown significantly since the initial deployment of assets on the Aave GC instance. With Circle-supported USDC.e now established as the canonical USDC representation, it is important to accelerate the transition away from legacy USDC to prevent liquidity fragmentation and enhance capital efficiency. To promote the migration from USDC to USDC.e and concentrate liquidity in a single canonical market, this proposal introduces a progressive parameter adjustment schedule: 1. Freeze the market — Preventing new positions from being created and new deposits. 2. Reserve Factor Increase — USDC’s (old) RF will be increased to 80%, incentivising lenders to migrate to USDC.e. --- Specification The following table shows the current parameters and proposed adjustments for USDC (old) in the first AIP (updated upon receiving feedback from both @LlamaRisk and @ChaosLabs): |Parameter|Current|Proposed| | --- | --- | --- | |RF|40%|80%| The USDC (old) reserve will be frozen — preventing new deposits, borrows, or collateral enablement. The Reserve Factor will be immediately increased to 80%, redirecting most of the yield to the protocol and incentivising migration to USDC.e. Existing positions remain unaffected, but users are encouraged to unwind and migrate voluntarily to USDC.e. Disclosure kpk has not received payment for this proposal. kpk is a delegate within the Aave community. 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 Snapshot outcome is YAE, escalate this proposal to AIP stage Copyright Copyright and related rights waived via CC0.

[ARFC] Service Provider Compensation Reform for V4 Alignment Author: ACI Date: 2025-10-10 Summary This ARFC proposes a comprehensive reset of all active Aave service provider compensation streams to better align contributors with the success of the Aave ecosystem ahead of the Aave V4 launch. The proposal maintains the same total annual compensation levels for each provider while introducing a one-year vesting component tied to clear key performance indicators (KPIs). Motivation As stated in the State of the Union post, Aave DAO should seek to ensure that the service providers who contributed significantly to Aave’s success are directly aligned with the protocol’s growth and long-term sustainability. The goal of this reform is to reset and unify the compensation framework for all key service providers, ensuring alignment with Aave V4 delivery milestones and improving transparency around deliverables. Key motivations: 1. Alignment with AAVE performance – linking compensation to measurable outcomes. 2. Preparation for V4 – establishing a synchronized, goal-driven working structure across contributors. 3. Simplicity and fairness – resetting all streams equally for a one-year term. 4. Long-term alignment – variable revenue sharing proposed in the State of the Union will be postponed to V4 rollout and finalized thereafter. Note: While aligned and considered a key service provider of the Aave DAO, BGD Labs has preferred to opted out of the compensation reform and crafted its own proposals. The ACI respects their decision and will support their standalone proposal. Specification The following structure will apply to all primary Aave service providers: | Provider | Annual Stream (Reset) | KPI Vesting (1 year) | Immediate Grant | | --- | --- | --- | --- | | ACI | Same as previous stream | $750K AAVE vested 12mo, KPI-based | $250K AAVE (90d TWAP) | | TokenLogic | Updated to 2.5M GHO | $750K AAVE vested 12mo, KPI-based | $250K AAVE (90d TWAP) | | LlamaRisk | Same as previous stream | $750K AAVE vested 12mo, KPI-based | $250K AAVE (90d TWAP) | | Chaos Labs | Same as previous stream | $750K AAVE vested 12mo, KPI-based | $250K AAVE (90d TWAP) | Overall compensation reform parameters All current service provider payment streams are stopped and replaced with new streams, effective immediately upon AIP execution. Each provider receives $250K worth of AAVE (90-day TWAP) distributed at proposal execution. Each provider receives $750K worth of AAVE vested linearly over 12 months, subject to KPI success. KPI performance threshold: 85% success rate of defined deliverables completed within official deadlines. KPI Definitions ACI Skywards TEMP CHECK business case + ARFC publication + Snapshots + Draft AIP payload delivered for review within deadlines. TokenLogic Monthly buyback management execution completed, and Finance AIP payload submitted on time each month. LlamaRisk ARFC risk reviews delivered within the defined review period and aligned with publication deadlines. Chaos Labs ARFC risk reviews delivered within the defined review period and aligned with publication deadlines. Incentives The KPI-linked vesting ensures that each provider remains motivated and outcome-oriented throughout the V4 development cycle. This structure simplifies future variable alignment mechanisms expected for V4 (e.g. revenue-based components) while immediately aligning contributors through AAVE token exposure. AAVE Streams The AFC will set up the AAVE streams via Llamapay vesting service, leveraging their AAVE reserves sourced from buybacks. Every month, KPI compliance will be monitored. If a service provider stays below the 85% threshold for two consecutive months, their stream will be terminated by the AFC, and undistributed AAVE will return to the AAVE DAO. Disclosure This proposal is based on the Aave State of the Union initiative and is not sponsored or compensated by any service provider. ACI authored this proposal in coordination with the involved contributors for DAO consideration. Next Steps 1. Collect community and Risk Service Provider feedback on the ARFC. 2. If the Snapshot outcome is YAE, escalate to an AIP for implementation. 3. Begin vesting streams and apply KPI monitoring through the governance framework. Copyright Copyright and related rights waived via CC0

Title: \[TEMP CHECK\] Onboard frxUSD to Aave v3 Ethereum Core Instance Author: Frax Core Team Date: 2025-09-16 Simple Summary This proposal seeks to onboard Frax USD (frxUSD) as a new stablecoin asset on the Aave v3 Ethereum Core Instance. frxUSD is fully backed by tokenized U.S. Treasury assets held by top-tier institutions like BlackRock and Superstate and is redeemable 1:1 for USD through enshrined custodians. Motivation/Background About frxUSD frxUSD is a fiat-redeemable stablecoin issued by the Frax Protocol, fully backed 1:1 by tokenized U.S. Treasury funds managed by institutional custodians like BlackRock and Superstate. Its bankruptcy-remote structure ensures unparalleled stability, and it is mintable/redeemable directly through licensed partners and soon directly on the frax.com interface itself to any user in the world (fiat wires will require KYC/AML). frxUSD is mintable/redeemable 1:1 for cash, USDC, and USDT directly from the issuer, Frax Protocol. Additionally, frxUSD offers a unique revenue-sharing mechanism, allowing up to 100% of its underlying T-Bill yield (currently 4.1%) on unborrowed frxUSD assets in Aave pools to be shared with Aave DAO. This revenue can be utilized as protocol income or distributed as incentives for depositors, providing flexibility for governance decisions. Benefits of Listing frxUSD Adding frxUSD to Aave v3 on the Ethereum Core Instance would provide the following benefits: Stable Collateral Base: Institutional-grade reserves reduce protocol risk. Guaranteed Incentives: 100% of T-Bill yield (4.1% APY) from unborrowed frxUSD assets deposited in Aave pools would be used as incentive for participants. Regulatory Compliance: Positioned as a payment stablecoin under the GENIUS Act. Proof of Liquidity and Deposit Commitments Frax Finance commits to supporting the launch of frxUSD on Aave v3 Ethereum with meaningful liquidity: Initial Liquidity Commitment: At least $1M+ in frxUSD deposits will be provided to Aave within the first month of deployment, ensuring strong utilization and borrow availability from day one. Engaged LP Community: Frax has an active community of liquidity providers who have expressed strong demand for frxUSD on Aave Ethereum. Many are recurring participants in lending markets and are expected to migrate capital into this market upon launch. Sustainable Incentive Model: frxUSD’s underlying RWA yield (from tokenized U.S. Treasuries) enables sustainable protocol incentives. portion or full reward from unborrowed frxUSD held in Aave pools can be directed toward depositors. This aligns long-term usage incentives with real-world income rather than relying on token emissions. Specifications frxUSD Token Contract Address: Ethereum: [0xCAcd6fd266aF91b8AeD52aCCc382b4e165586E29] Chain: Ethereum We are open for recommendations from Aave risk management teams. 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 provider 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. Copyright Copyright and related rights waived under CC0.

Summary In collaboration with Aave’s growth teams, this publication proposes a flexible funding arrangement to support incentive commitments made by Service Providers when securing strategic partnerships. Motivation In recent times, the DAO service providers have negotiated many beneficial opportunities reinforcing Aave Protocol's dominant market position across the broader industry. These opportunities align with the Road to 80% north star and strategically position Aave for sustained medium term growth. Partnerships with Kraken, Binance, Plasma, X Layer and others each require contribution from the Aave DAO in varying capacity during the bootstrapping phase. To reduce governance overhead associated with individual funding requests, this publication establishes a flexible funding mechanism to support bootstrapping efforts and strengthen Aave Protocol’s position across key ecosystems. With Plasma, Ink, X Layer and other deployments either live, or soon to be deployed, this publication aims to make available near term funding while a wider-reaching proposal is being prepared. Importantly, this publication serves to address immediate operational priorities. With a preference to retain ETH and to distribute rewards in GHO where practical, or in assets aligned with each bootstrapped market, we propose adjusting Ahab’s budget to better support near-term Aave Protocol bootstrapping efforts. This adjustment enhances flexibility in how the DAO’s capital is utilized. For illustrative purposes only, borrow capital at net zero or near zero cost (GHO), distribute incentives to users whilst continuing to accrue yield on existing stablecoins (eg: USDT0 on Plasma) and then use future revenue (eg: GHO on Core) to repay settle liabilities. Doing this allows the DAO to benefit from earning yield on existing assets whilst arbitraging stablecoin funding rates. Whilst maintaining sufficient collateral, the DAO benefits from enhanced cashflow management flexibility. Through the distribution of GHO, GHO is introduced to a new user base, with future GHO revenue expected to cover liabilities. If needed, other Allowances, such as those mentioned in the specification section, can be utilised to manage the Aave position and, to some extent, support GHO’s peg. With conservative health factor(s) and having sufficient Allowances in place, the Aave Finance Committee (AFC) has the ability to provide support for the peg by optimising when swaps are performed. Specification This proposal upon AIP execution implements the following: Aave Helper Asset Budget (Ahab) Asset: aEthWETH 0x4d5F47FA6A74757f35C14fD3a6Ef8E3C9BC514E8 Amount: 6,000 Spender: Ahab 0xAA2461f0f0A3dE5fEAF3273eAe16DEF861cf594e Method: approve() aEthWETH on the Aave Collector contract to the Ahab address For USDT0, Plasma: Asset: aPlaUSDT0 0x5D72a9d9A9510Cd8cBdBA12aC62593A58930a948 Amount: 3M Spender: Ahab 0xAA2461f0f0A3dE5fEAF3273eAe16DEF861cf594e Method: approve() aPlaUSDT0 on the Aave Collector contract to the Ahab address. For USDe, Plasma: Asset: aPlaUSDe 0x7519403E12111ff6b710877Fcd821D0c12CAF43A Amount: 2M Spender: Ahab 0xAA2461f0f0A3dE5fEAF3273eAe16DEF861cf594e Method: approve() aPlaUSDe on the Aave Collector contract to the Ahab address. For GHO, Ethereum: Asset: aEthGHO 0x7519403E12111ff6b710877Fcd821D0c12CAF43A Amount: 10M Spender: Ahab 0xAA2461f0f0A3dE5fEAF3273eAe16DEF861cf594e Method: approve() aEthGHO on the Aave Collector contract to the Ahab address. This proposal upon passing ARFC Snapshot vote, it grants the AFC, led by TokenLogic, the ability to perform the following on the Ahab SAFE: Actively manage collateral and debt positions on Aave Protocol Create incentives campaigns on Aave Protocol that utilise @ACI to distribute rewards to users Balance incentive campaign expenditure and DAO cashflow, to facilitate supporting strategic opportunities. The DAO entrusts TokenLogic to manage the respective budget in collaboration with respective Growth teams and AFC members, and in doing so balance supporting strategic opportunities and cashflow commitments. Disclosure TokenLogic does not receive any payment for this proposal. 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 Snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

!telegram-cloud-document-4-5929489522231352464 Summary TokenLogic proposes a 12-month early renewal of our financial services partnership with the Aave DAO, commencing on November 1st, 2025. This renewal reflects the expanded scope of our collaboration, encompassing Treasury Management, GHO Growth and Analytics. Under this renewed mandate, TokenLogic will continue to manage the DAO’s finances, drive GHO and sGHO adoption, and provide in-depth analytics across the Aave ecosystem. The early renewal will not affect the current engagement which remains in place until 15th December 2025. Scope of Work Treasury Management TokenLogic focuses on ensuring the Aave DAO’s expenses and initiatives are funded efficiently. We support financial planning, budgeting, forecasting, risk management, and capital optimization to safeguard long-term stability. Our responsibilities span cash flow management, treasury operations, expense payments, and financial analysis, providing data-driven insights that guide strategic decision-making and business growth. Core Functions Financial Planning & Analysis: Develop short-medium term financial strategies, create budgets, and forecast future financial performance; Cashflow Management: Manage cash flow to ensure the company has sufficient funds to operate, pay suppliers, and invest in growth; Budget Allocation: Allocate budgets to different initiatives (e.g. Ink, Plasma, X Layer) to ensure financial goals/commitments are met and resources are used efficiently; Funding and Capital Management: Determine the preferred way to manage the DAO funding needs by using a combination of cashflow and debt to support operations whilst maintaining exposure to underlying asset performance; Risk Management: Identify and manage financial risks, ensuring the company's financial stability and long-term prospects; Incentive Management: Work with the ACI team to submit incentive grant requests on behalf of Aave, provide input into strategic initiatives tenders alongside ACI and Aave Labs, and continue to design how incentives are distributed across Aave Protocol; and, Umbrella/Safety Module: Monitor users interactions with Umbrella and the Safety Module, review the yield relative to the broader market and define emissions to optimise Aave DAO's expenses. Strategic Importance As Aave continues to grow, we are witnessing an increase in the volume of strategic opportunities that requires thorough analysis and holistic oversight to determine which initiatives are to be pursued and how capital is allocated across initiatives often led by different Service Providers. Decision Support: Provide management with critical financial data and insights to support informed strategic and operational decisions; Profitability & Growth: Focus on improving profitability and generating cash, transforming the finance function into a valuable contributor to the business; Capital Management: Implement Buybacks, manage stkAAVE and stkABPT emissions, sGHO emissions, deploy assets to reduce incentive spend, utilise loans as needed to support Aave DAO's investments and strategic interests; Liquidity Management: Subject to the availability of capital, reduce the cost of AAVE and GHO liquidity by providing direct liquidity provisions; Data Driven: Use analytic services and technology to gather, synthesize, and visualize financial data, enabling data-driven decision-making throughout the organization; and, Aave Protocol Configuration: Work with various teams to design the initial configuration of new instances of Aave v3 and v4 to strategically position Aave to maximise growth. Aave Savings Rate (ASR): Fund and maintain the ASR to ensure competitiveness in the broader market whilst balancing broader business revenue and expenses. Asset Management Tooling Continue to expand the Aave Finance Steward functionality and introduce new asset management tooling to optimise and expand how the DAO manages its capital. To streamline the DAO's financial operations, TokenLogic shall provide the following functionality: Bridge Steward: Permitting Aave Finance Stewards to move funds between Treasury addresses without taking custody of funds. Swaps Steward: Permitting Aave Finance Stewards to swap funds held within the Treasury directly on their respective networks. Position Management: Actively manage collateral position(s) on Aave Protocol to avoid liquidation. Liquidity Provisioning: Provide liquidity for both AAVE and GHO in secondary markets. Yield Optimisation: Ability to allocate liquidity across different strategies to reduce the dependency on voting and liquidity incentives. GHO Growth (Incl. sGHO) After solidifying GHO strength and utility within the ecosystem, the next chapter of GHO's growth will focus on continuing to unlock new use cases and improving the overall financial viability of GHO. TokenLogic will continue to introduce GHO to new networks, deepen integrations across CEXs and introduce GHO as a payment option with various wallet providers. DeFi Integrations: Focusing on growing liquidity and utility across networks where GHO is available; CEX Integrations: Continue onboarding GHO to CEXs and extending utility beyond Spot trading to Earn, Trading Accounts and other opportunities; Institutional Sales: Continue to work with large institutions seeking to access credit at reliable terms; sGHO Migration: Work with various partners to migrate integrations, wallets, protocol integrations, from the current version of sGHO to the newer ERC4626 sGHO when live. RemoteGSM: Develop and deploy the RemoteGSM to support the launch/growth on GHO in collaboration with other service providers; Facilitators: Develop and deploy facilitators to support the issuance of GHO to new networks, remoteGSMs, upgraded GSMs and service institutional demand via customised Aave v4 markets in collaboration with other service providers; Payment Integrations: Work with wallet providers to promote the integration of GHO as both a savings vehicle via sGHO and as payment token; Aave v4: Design how GHO will be integrated into v4 to create a yield curve that supports both facilitator Minting and Supplying into the hubs whilst also presenting users with attractive savings opportunities; and, Line-of-Credit: Support teams seeking a line of credit via customised Spokes on v4; After the successful launch of sGHO earlier this year by reconfiguring stkGHO's parameters, sGHO has attracted over 180M in user deposits representing ~53% of GHO's circulating supply. When the new sGHO is live, TokenLogic will lead efforts to migrate current sGHO users with support from ACI and bootstrap the adoption of sGHO across DeFi and CeFi. Liquidity TokenLogic will continue to lead the Aave Liquidity Committee (ALC), performing the operational lift of calibrating votes and administrating incentives across various platforms to direct incentives towards GHO liquidity pools. Our key responsibilities include: DEX Liquidity: Strategically determine pool type, asset pairing, amount of liquidity and the target yield required to achieve the desired amount of DEX liquidity; Operations: Claiming rewards, performing swaps and creating quests to receive votes; Optimise Liquidity Incentives: Monitoring, model and calculate the amount of incentives required to achieve robust market depth; and, Optimise Vote Incentives: Optimizing the deployment of the DAO’s strategic voting assets, re-locking assets, acquiring boost to optimize the impact of strategic assets. Gho Risk Stewards As GHO Stewards, TokenLogic will oversee the holistic up-keep of critical parameter configurations, including the Borrow Rate, GSM Caps and Fees, ensuring optimal functionality and sustainability. Parameter Optimisation: Strategic focus will be placed on managing the borrow rate and peg relationship to maintain the resilience of the peg by retaining funds within the GSMs, whilst promoting the ongoing use of GHO within evolving market dynamics.; Synchronised Growth: Position GHO within the broader market to grow sustainably, whilst maintaining the peg and encouraging user growth via different instances of Aave Protocol; and, Peg Stability: Continuously monitor and maintain GHO’s peg across CEXs and DEXs by analyzing liquidity, trading volumes, incentive effects, and broader market conditions. The TokenLogic team will collaborate closely with other service providers to create balanced, effective solutions that benefit the protocol as a whole. Analytics and Performance Metrics Whilst continuously developing new analysis and expanding the offering throughout the year, TokenLogic provides a comprehensive overview of GHO and Aave DAO's finances via the Aave Portal. The transparency and granularity provides access to key metrics on protocol performance, health, GHO dynamics, and market analysis. During Phase II, TokenLogic will continue to expand the data analysis offering and introduce the following new features: User Portal: A Service Provider portal enabling competitor performance tracking and monitoring of strategic partnerships, easily accessible and shareable across teams. Eg : Track incentives, revenues, and rebates offered by the DAO to external partners. API Service: Provide users access to TokenLogic's data via both downloadable CSV file and also import data via an API Endpoint; Performance Metrics: A deeper dive into the operational efficiency of the business enabling conventional valuation models to be applied; Revenue Generation: Detailed insights highlighting which collaterals types and use-cases are primarily responsible for creating protocol revenue. User Retention: After attracting new users, or post incentive campaign, assess user retention in terms of duration, revenue generation and acquisition cost to support the refinement of future growth initiatives. The Aave Portal will serve as an important tool for informed decision-making and in-depth analysis of the Aave ecosystem. To further engage and educate the community, this initiative will be complemented by detailed threads/articles released throughout the mandate, promoting awareness and understanding of the platform’s developments. Specification Early Renewal Summary This proposal creates a new and separate engagement stream, that operates in parallel with the current engagement, which remains active through December 15, 2025. Renewal Term: November 1st, 2025 – October 31st, 2026 Duration: 12 Months Annual Contract Value: $2,500,000 USD Amount: 2,500,000 aEthLidoGHO Payment Method: Linear Stream from Treasury Recipient Address: 0xAA088dfF3dcF619664094945028d44E779F19894 Disclosure This ARFC is submitted by the TokenLogic independently and without third-party compensation or sponsorship. 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 Snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] Onboard USDai & sUSDai to Aave V3 Plasma & Arbitrum Instance Author: @ACI Date: 2025-09-24 Summary We propose the onboarding of USDai and sUSDai on Aave V3 Plasma & Arbitrum Instance. This listing would initially enable users to deposit USDai and sUSDai to earn yield and borrow them as stable assets in a USDt-only E-Mode. Motivation USDai and sUSDai are innovative stable assets backed by AI hardware infrastructure and idle reserve assets, designed to merge real-world infrastructure finance with DeFi. As emerging stablecoins with strong venture backing and early adoption momentum, USDai and sUSDai represent a differentiated design that expands Aave’s exposure to innovative collateral types while offering users stable units of account and new yield-bearing options. Key differentiators: 1. Hardware-backed design: Both tokens leverage GPU/AI compute hardware as collateral, creating a new RWA category. 2. Dual-token structure: - USDai serves as the stablecoin for payments and borrowing. - sUSDai accrues yield from lending to AI firms and low-risk asset allocations. 3. Growing ecosystem: Planned launch on Plasma with $500M in deposits ready for deployment on Plasma mainnet. Arbitrum is Already the main Hub for usd.ai echosystem and Aave is set to take a lion's share of their liquidity and associated borrowing volume Specification Risk Service Providers will provide Risk Parameters and proposal will be updated accordingly. Incentives: The USDai team is considering incentive programs to boost adoption and enhance the competitiveness of USDai and sUSDai borrowing rates compared to other stablecoin assets on Aave Plasma. There are additional incentives planned as part of the launch of USDai on Plasma. Detailed incentive structures will be shared with Aave DAO contributors and the community in the ARFC stage. Disclosure ACI are not affiliated with USDai and have not received compensation for the creation and review of this proposal. 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 provider 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. Copyright Copyright and related rights waived via CC0

Summary Proposal for the pre-approval of Aave v3.6, to authorise starting with the final development and 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: Liquid eMode exclusive collaterals. Liquid eMode exclusive borrowables. Liquid eMode exclusive LTV0 behaviour. Introducing renounce functionality on aToken allowance & credit-delegation. Liquidating aTokens no longer enables them as collateral. Receiving aTokens via transfer no longer enables them as collateral. Aligning tokens with OZ approval flow event emission. Removal of ISOLATEDCOLLATERALSUPPLIER_ROLE role. Context Historically, the major “sub-versions” of Aave v3 have targeted different parts of the protocol. Sometimes, adding new features, others making architectural changes, others focusing purely on security, and others improving user or developer experience. The following is a quick recap of the past versions proposed and applied in production: Aave v3.1. Infrastructural, very oriented to security improvements, with the introduction of virtual accounting and the deprecation of stable rate borrowing. Aave v3.2. Feature-rich, focusing on the introduction of Liquid eModes, which radically changed the usage and configuration of assets listed on Aave pools. Aave v3.3. Again, infrastructural, but this time focused on optimising liquidations and starting to account for bad debt accrued on the protocol (deficit). Aave v3.4. A bit of an exception, as it has a pretty good balance between UX/DevEx-oriented changes and infrastructure. The rationale is that, given the criticality of the liquidations component touched on in v3.3, we decided not to include certain features and optimisations we had in a very advanced stage of development and pack them together in v3.4. Aave v3.5. Again, infrastructural, but this time focused exclusively on rounding & precision. Aave v3.6 doesn’t really introduce completely new mechanisms, but improves those added in previous upgrades. Specifically, doubles down on the learnings from Aave v3.2 and introduces some changes that were originally omitted to reduce scope, for example, improving how risk parameters can be configured on assets. Aave v3.6 features 1. Liquid eModes improvements The majority of changes introduced in v3.6 are focused on improving the configuration workflows of liquid eModes. On prior versions of the Aave protocol, the default reserve configuration always supersedes the eMode configuration. In practice, this meant: For an asset to be collateral inside an eMode, it must be collateral outside as well. For an asset to be borrowable inside an eMode, it must be borrowable outside as well. If an asset is set to ltv = 0 on the reserve configuration, it would be considered as ltv = 0 inside the eMode as well, and LTV0 rules* would apply. (*) On Aave v3 ltv0 assets are on one hand, as expected ltv = 0, but in addition to that some ltv0-rules apply: ltv0 assets cannot be enabled as collateral. ltv0 collateral has to be withdrawn first. This means that if the position consists of ltv0 and non ltv0 collaterals, trying to withdraw or transfer the non ltv0 collateral will revert. While this current approach was the natural evolution of the 3.0 behavior, it also made certain scenarios impossible to configure. Currently, it is impossible to list an asset and make it: exclusively borrowable in some eMode. exclusively collateral in some eMode. cap exposure via LTV0 rules exclusively for usage outside eMode, or exclusively inside a specific eMode. This limitation is artificial, and only exists because upgrades have historically been applied gradually with as minimal but impactful changes as possible. Therefore, in Aave v3.6, the next minimal increment is to remove this limitation. On Aave v3.6, the reserve configuration no longer overwrites the eMode configuration. In addition to that, the eMode configuration was extended by an ltvzerobitmap that allows enabling ltv0-rules for a specific asset on a specific eMode. -> Motivation for the change The motivation behind this feature is two-fold. Firstly, it allows for more granular control, making reasoning about risk easier. Secondly, it resolves some actual issues risk teams currently face: If they want to make an asset collateral inside an eMode only, they still need to enable it as collateral outside of eMode. So they configure it with a very low LT as a workaround, which is not ideal. If they want to make an asset borrowable only inside of an eMode, they still need to enable it to be borrowable outside of eMode. There is currently no workaround, which is the reason why some assets are borrowable, although there is no clear general use-case for it. Being able to flag an asset as LTV0 only in a specific eMode, or more importantly, only outside of it, can give great benefits in risk control and would have been useful in the past. We think that given that possibility greatly improves risk control while also providing a way to off-board assets from an eMode. --- 2. Changes in automatic collateral behaviour 2.1. Liquidate aTokens Liquidating aTokens will no longer automatically enable the received asset as collateral. On-chain observations show that the current behaviour was never relied upon, but significantly increases gas cost for the liquidators. Therefore, we decided to drop it. Users who would want to liquidate and enable as collateral could still do so in a single transaction via multicall if desired. -> Motivation for the change The current behavior was flagged by various auditors on multiple releases of the Aave protocol, as it creates strange situations on paper: when a user fully liquidates himself, their excess debt will be counted as a deficit, but they will be left with the bonus accounted as collateral. After checking on-chain data, we found that: No one ever relied on this behaviour. Liquidations become around 25k gas cheaper when removing it. Given the gas-sensitive nature of liquidations, we therefore decided that simply dropping the behavior is the best course of action. 2.2. Isolated collateral supplier In Aave V3.2, we introduced an ISOLATEDCOLLATERALSUPPLIER_ROLE role for certain permissioned entities to deposit an isolated collateral and automatically enable it as collateral. This was done from a conservative point of view to still allow the flow, but the feature was never actively needed/used, and increases gas cost and code complexity. Therefore, in v3.6, isolated collaterals are simply not automatically enabled as collateral. -> Motivation for the change We checked on-chain data for usage and realized that the role was only ever given twice to the MigrationHelperMainnet and Legacy ParaSwapLiquiditySwapAdapter. While the first one still has some transactions, migrating only isolated assets is not a common use case. The second one has not been used for over two years. Again, on-chain data revealed that there was essentially no usage. On the flipside, the feature increased gas cost for every single transfer, so we think it's a very reasonable thing to remove it. 2.3. Automatic enable as collateral on transfer When receiving an aToken via transfer, the receiver will no longer be automatically enabled as collateral. In previous versions of the Aave protocol, a transfer would enable a received asset as collateral automatically if possible. On-chain analysis shows that for the vast majority of transfers, the enabling as collateral is usually non-intentional: the vast majority of users never borrow any assets against assets received on transfer. By removing this feature, aToken transfers become a lot more gas efficient, which in turn has effects on the whole ecosystem, improving user experience in e.g., boosted pools. All major integrations that rely on aToken transfers already handle the case of an asset not being enabled as collateral, as there are already edge cases in which the automation will not work (isolation & ltv0). While v3.6 changes the behavior on transfer, supply/ deposit flows remain untouched, as we evaluate that path as more sensitive integration-wise. -> Motivation for the change The automatic enabling as collateral on transfer feature was causing unnecessary gas costs and was not being used by the majority of users. By removing this feature, transfers are becoming much more gas efficient(~18% or ~25k) and improving user experience in integrations that heavily rely on transfers (e.g., boosted pools). We've been checking with major integrations, and there should not be any impact on them. The only occasion found was in a Defisaver contract, which the team confirmed they can easily adapt to the new behavior. Our rationale for changing vs not changing is the following: The feature is rarely relied upon by users. The majority of interfaces & integrations work with the underlying and then use deposit. If integrations want to rely on this feature, they still can by using the position manager or deposit on behalf. The gas saving is significant (~18% or ~25k), transfers being the backbone of some other contracts (stataTokens & weth gateway) means the gas saving will be perceivable there as well. The code simplification is very significant. Finally, there should not be any type of scenario where integrations have any major problem, given that any contract handling aTokens directly will definitely have an outflow path defined. --- 3. Renounce allowance We introduce a new function renounceDelegation(address delegator) on the VariableDebtToken, as well as renounceAllowance(address owner) on the AToken. This way, any given integration can call these functions to "burn" excess allowance by setting borrowAllowance and allowance back to zero. -> Motivation for the change In the current state of the Aave ecosystem, it is quite common to have pending dust allowance for aTokens and credit delegation. This stems from the fact that a/v tokens are rebasing, and usually, it is not known exactly how much allowance will be needed at the time of execution. To mitigate that, integrations are over-approving, which in turn lets the unused “dust” allowance hanging, something not really optimal security-wise for those integrators. --- 4. OZ alignment The transferFrom function on AToken no longer emits an Approval event. This is a gas optimization that aligns with OpenZeppelin's ERC20 standard implementation, where transferFrom is not required to emit an Approval event. The allowance is still correctly updated. The _decreaseBorrowAllowance function on the DebtTokenBase no longer emits a BorrowAllowanceDelegated event. This change was made to align with the logic of OpenZeppelin's ERC20 implementation regarding allowance updates. This reduces gas costs for operations that decrease borrow allowance, such as borrowing on behalf of another user. The BorrowAllowanceDelegated event is now only emitted on explicit approval via approveDelegation or delegationWithSig, which is analogous to how the Approval event is handled in OpenZeppelin's ERC20 contract. -> Motivation for the change The current behaviour was highlighted by multiple auditors in the past as not being aligned with most of the other contracts out there (most notably modern OZ). By removing the event emission, the code is better aligned with the rest of the ecosystem, while at the same time saving some (~2k) gas for integrations that heavily rely on transferFrom (e.g., all Paraswap adapters). --- 5. EMode Category label The v3.6 upgrade does NOT change anything on the label configuration, but simply includes a deprecation notice as a soft deprecation. We highly recommend to update UI code to handle the eMode selection based on a different logic than the on-chain label, but the on-chain label will remain for the foreseeable future. -> Motivation for the change The eMode category label was first introduced in Aave v3.0. Over time, eModes have been extended via liquid eModes in Aave v3.2 and further improved in this Aave v3.6. Emodes are now much more dynamic than they originally were; thus, the fixed label that is set on creation is starting to fall out of date. In addition to that, there now exist multiple eModes for the same subset of assets, making naming via a fixed label far more complex, as can be seen by the existing, often clashing, labels, with differentiation suffixes. While eMode labels made sense initially, they no longer do. With growing adoption of liquid eModes, we'd like to encourage integrations to generate reasonable labels based on the configuration instead of relying on the on-chain naming.

Summary This publication proposes onboarding MetaMask's mUSD stablecoin to the Core instance of Aave v3 on Ethereum and Linea. Motivation MetaMask USD (mUSD) is a dollar-denominated stablecoin natively integrated into MetaMask. mUSD is issued by Bridge, a Stripe company, and stablecoin issuance and orchestration platform. On-chain MetaMask USD is powered by M0, a decentralized stablecoin infrastructure and liquidity platform. mUSD will be deeply integrated into MetaMask’s wallet, offering users a seamless, dollar-denominated stablecoin experience for holding, spending, and transacting in web3. Key properties Wallet-native: deeply integrated across MetaMask UX and supported dapps. Multi-chain at launch: Ethereum Mainnet and Linea and will play a foundational role in the growing Linea DeFi ecosystem and network expansion. Interoperable: designed for cross-chain liquidity via the M0 network. Transparency-first: reserve management by Bridge with real-time reporting. mUSD is fully backed 1:1 by high-quality, liquid dollar-equivalent assets. Bridge provides real-time transparency reporting, with independent attestations to follow. The launch aligns with new U.S. regulatory clarity under the GENIUS Act. Payments & MetaMask Card mUSD supports on-ramps, swaps, bridging, and will soon be spendable via the MetaMask Card at millions of Mastercard merchants. Specification Ticker: mUSD Contract address Ethereum: 0xacA92E438df0B2401fF60dA7E4337B687a2435DA Contract address Linea: 0xacA92E438df0B2401fF60dA7E4337B687a2435DA Chainlink oracle: soon Audits: https://github.com/m0-foundation/mUSD/tree/main/audits Project: https://metamask.io Docs: https://github.com/m0-foundation/mUSD/blob/main/README.md Twitter: https://x.com/MetaMask | Parameters | Value | Value | | --- | :---: | :---: | | Network | Ethereum | Linea | |Isolation mode| No | No | |Borrowable| Yes | Yes | |Collateral enabled| No | No | |Supply Cap | 10,000,000 | 70,000,000 |Borrow Cap | 8,000,000 | 60,000,000 | |Debt Ceiling| - | - | |LTV| - | - | |LT| - | - | |Liquidation Penalty |-|-| |Liquidation Protocol Fee|-|-| |Variable Base| 0% | 0% | |Variable Slope1| 6.50% | 6.50% |Variable Slope2| 60% | 60% | |Uoptimal| 80% | 80% | |Reserve Factor| 20%| 20%| |Stable Borrowing| Disabled | Disabled | |Flashloanable | Yes | Yes | |Siloed Borrowing| No | No | |Borrowed in Isolation| No | No | Risk Parameters will be provided by Risk Services Providers at the earliest possible and ARFC will be updated with that feedback. DEX liquidity is to be provided in the coming days to aid Risk Service providers in providing their analysis. Disclosure TokenLogic does not receive any payment for this proposal. 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 Snapshot outcome is YAE, an AIP will implement proposal. Copyright Copyright and related rights waived via CC0.

[ARFC-Addendum] Update Merit for Round 30 Author: ACI (Aave Chan Initiative) Date: 2025-09-18 --- Simple Summary This addendum proposes updates to the Boosters and reward structure for Merit Round 30. These changes are designed to reflect current market dynamics and improve the effectiveness of the Merit program. Motivation We want to create a new « Aave Aligned Frens Booster » boost, to reflect those partners, users and other third parties/protocols that are Aave aligned and have trusted Aave and Aave DAO when it comes to their resources. Specification Boosters Update The following changes will be applied: Add an Aave Aligned Frens Booster for an additional 5% rewards Initial Aave Aligned Frens Booster will be to InfiniFi 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 to Merit Round 30. Disclaimer The Aave Chan Initiative independently proposes “Merit” without external compensation. Copyright Copyright and related rights waived under Creative Commons Zero (CC0).

Title: \[ARFC\] Endorse the Asset Classification Framework (AAcA) Author: LlamaRisk Date: 2025-09-11 Summary Following a community discussion, a formalization proposal by @bgdlabs, and an ARFC that passed the snapshot vote, we proposed this document to establish the Aave Asset Class Allowlist (AAcA). This framework is intended to be a collaborative tool maintained by Aave’s Service Providers to streamline and standardize the asset onboarding process. We’re opening this draft for the DAO’s feedback, as we have already started circulating it amongst SPs. Motivation The core principle of the AAcA is to group assets into logical categories based on their shared characteristics and collective risk profiles. This structured approach provides several key benefits: Clarity and Consistency: It creates a shared language for all stakeholders, from community members to risk service providers. Systematic Risk Assessment: By grouping similar assets, risks can be evaluated more systematically, allowing consistent risk parameters across a class. Deliberate Governance: It forces the DAO to make a conscious and deliberate decision before onboarding a new asset class, ensuring strategic alignment and risk awareness. The framework is organized into six primary groups: Stablecoins, Wrapped Assets, Staking & Restaking Derivatives, Protocol Tokens, Tokenized Financial Instruments, and Uncategorized Assets. Each class within these groups is defined with a clear description, its current approval status, and examples of assets that fit the category. Approved classes are those that have been formalized based on currently or previously onboarded assets. Approved assets are still subject to analysis to determine if they are individually eligible for onboarding. Not Approved classes are those that have already been reviewed and have been explicitly not approved due to factors such as technical considerations and/or legal implications, among others. Not Analyzed classes are new categories introduced by recently proposed assets, suggested for future consideration, but not yet formally part of the Aave allowlist. These require assessment, community discussion and formal approval (via ARFC) before onboarding an asset of that class. Specification Aave Asset Class Framework 1. Stablecoins This group includes all assets designed to maintain a stable value relative to a fiat currency, subdivided by their stabilization mechanism and yield properties. | Class Name | Description | Status | Example Assets | |----|----|----|----| | Fiat-Pegged Stablecoins | | | | | Reserve Backed Stablecoin | Fiat-pegged assets backed by verifiable reserves, such as cash, cash equivalents, and other financial instruments. | Approved | AUSD, BUSD-T, cEUR, cUSD, EURC, EURe, EURS, FDUSD, frxUSD, m.USDC, m.USDT, openUSDT, PYUSD, RLUSD, USD1, USDbC, USDC, USDC.e, USD//C, USDT, USDT0, USDtb | | CDP Stablecoin | Fiat-pegged assets backed by a surplus of crypto assets, managed via a collateralized debt position (CDP) mechanism. | Approved | crvUSD, DAI, GHO, lisUSD, LUSD, USDS | | Actively Managed Stablecoins | | | | | Actively Managed Stablecoin | Assets whose peg relative to fiat or its underlying is maintained through different strategies (e.g., delta-neutral positions) or vault mechanisms. | Approved | USDe, USR, scBTC, scETH, scUSD | | Algorithmic Stablecoins | | | | | Algorithmic Stablecoin | Assets whose peg is maintained through algorithmic mechanisms. | Approved | | | Yield-Bearing Stablecoins | | | | | Diversified Yield Stablecoin | Stablecoins that generate yield for holders from diversified, Aave-vetted strategies applied to underlying reserve assets. | Approved | fxSAVE, syrupUSDC | | Concentrated Yield-Bearing Stablecoin | Stablecoins that generate yield for holders from their underlying reserve assets being deployed to narrowly defined strategies. | Approved | sUSDe, sDAI, sUSDS | 2. Wrapped Assets This group includes tokens representing another underlying asset on a 1:1 basis, differentiated by their utility. | Class Name | Description | Status | Example Assets | |----|----|----|----| | Native Wrappers | ERC-20 assets that represent a wrapped version of a network or protocol token, for purposes such as non-rebasing or interim receipts. | Approved | WAVAX, WBNB, WETH, WPOL, Ws, WXDAI, eUSDe, tUSDe | | Bridging Wrappers | ERC-20 assets that represent tokens bridged from a secondary chain, differentiated by their custom bridge infrastructure and non-standardized mechanisms. | Approved | BTC.b, BTCB, cbBTC, SolvBTC, tBTC, WBTC | 3. Staking & Restaking Derivatives This group includes all liquid tokens derived from Proof-of-Stake (PoS) staking or restaking activities. | Class Name | Description | Status | Example Assets | |----|----|----|----| | LST (Liquid Staking Token) | Liquid receipt tokens representing staked assets in a Proof-of-Stake (PoS) system. | Approved | cbETH, ETHX, LsETH, MaticX, osETH, rETH, sAVAX, weETH, wstETH, LBTC, stS, wstLINK | | LRT (Liquid Restaking Token) | Liquid receipt tokens representing assets deposited into a restaking protocol like EigenLayer. | Approved | eBTC, ezETH, pufETH, rsETH, rstETH, wrsETH, xSolvBTC | | Leveraged LST | Liquid staking tokens with leveraged yield optimization. | Approved | tETH, wOS | 4. Protocol Tokens This group includes tokens integral to a protocol’s function, governance, or utility. | Class Name | Description | Status | Example Assets | |----|----|----|----| | Governance | Tokens whose primary utility is directing a protocol’s governance through voting. | Approved | 1INCH, AAVE, ARB, BAL, CRV, ENS, KNC, LDO, MKR, OP, SCR, STG, UNI | | Protocol Utility Token | Assets that facilitate key functions within a protocol, such as staking, collateral, or operator rewards. | Approved | CELO, FXS, GNO, LINK, Metis, RPL, SNX, ZK | 5. Tokenized Financial Instruments This group includes tokenized derivatives and representations of traditional financial assets, including Real-World Assets (RWAs). | Class Name | Description | Status | Example Assets | |----|----|----|----| | Tokenized Derivatives | | | | | Principal Token (PT) | Non-yield-bearing tokens representing the principal component of a deposited asset from a yield-splitting protocol. | Approved | PT-eUSDE-29MAY2025 | | Tokenized Real-World Assets (RWAs) | | | | | Tokenized Commodity | Assets that are collateralized by physical commodities. | Approved | XAUt | | Tokenized Securities | A tokenized representation of traditional securities such as Exchange-Traded Funds. | Not Approved | bCSPX | 6. Uncategorized Assets This group is for unique asset types that do not fit into the other categories. | Class Name | Description | Status | Example Assets | |----|----|----|----| | #### Uncategorized | e.g. Memecoin; these are tokens based on internet memes that typically lack fundamental utility and derive value primarily from social consensus. | Not Approved or Not Analyzed | Disclaimer LlamaRisk 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.

Summary This publication presents the Aave Liquidity Committee (ALC) Phase VII Funding request. Since the last update in April, GHO has experienced significant growth across supply, integrations, and ecosystem adoption. This proposal seeks to sustain and accelerate that momentum while lowering the overall budget requirements compared to the previous phase. Phase VI Update GHO Supply and Peg Since the last update, GHO has grown from 200M circulating supply to over 315M. This marks the fastest expansion since launch. Importantly, despite this rapid growth, the peg has never been stronger. Over the last months, GHO has consistently remained within 15 bps of $1.00, reflecting deep liquidity and strong demand. !image This stability enabled the ALC to raise the lower end of the GSM bands, further tightening peg control. GSMs are now back above 20M in supply, providing a strong backstop. !image Prime Instance The Prime instance has seen strong adoption with more than 155M GHO supplied, unlocking borrowing opportunities for curated collateral and users and continues to be one of the most important drivers of GHO utility. The chart below shows GHO's growth and the resulting revenue being generated from the Prime instance. !Screenshot 2025-09-17 at 06.48.17 !Screenshot 2025-09-17 at 06.42.52 Fluid and Base/Arbitrum Deployment One of the major highlights of Phase VI was the expansion of GHO into Fluid, which has quickly become a cornerstone venue for GHO liquidity and adoption. On Ethereum mainnet, GHO deposits on Fluid have surpassed 85M, making it the largest destination for GHO across the ecosystem outside of Aave. This growth was achieved thanks to the close collaboration between the ALC and Fluid, with tailored integration strategies, campaigns, and technical coordination ensuring smooth onboarding for users. !image Following this success, GHO was also deployed on Fluid on Base and Arbitrum. These deployments provide users with access to efficient, deep liquidity markets for GHO across leading L2s. Fluid has proven to be an ideal environment for GHO: Its architecture supports capital-efficient liquidity provisioning, helping amplify peg stability. Its integration with other DeFi primitives enables composable strategies that extend the utility of GHO across ecosystems. The design of Fluid markets allows for sustainable growth without excessive incentive spending, making it a cost-efficient growth channel for the DAO. Altogether, these integrations have positioned Fluid as one of the most effective growth partners for GHO, strengthening its presence on mainnet while also unlocking new user bases on Base and Arbitrum. Centralized Exchange Integration A landmark milestone during this phase was the first-ever centralized exchange listing of GHO on Bitget. This integration represents a significant step forward in expanding GHO’s distribution beyond purely DeFi-native channels and into a broader, global user base. The listing on Bitget has created: New entry points for retail and institutional users to access GHO directly without relying on decentralized liquidity routes. Increased visibility for GHO within the competitive stablecoin landscape, positioning it alongside established assets on a major trading venue. A diversified source of liquidity, complementing DeFi pools and helping to reinforce peg stability by broadening the set of arbitrage and trading flows. This listing was made possible through coordinated efforts between the ALC and Bitget’s listings team, demonstrating how collaboration between DeFi protocols and CEXs can create meaningful growth opportunities. Importantly, this is not a one-off milestone but the first step in a broader CEX integration strategy. Additional listings are in active discussion and expected before year-end, which will further strengthen GHO’s accessibility, enhance liquidity depth, and expand its presence into entirely new user demographics. On-chain Liquidity GHO on-chain liquidity has now surpassed $130M across all networks where it is deployed, mainly leveraging Balancer v3 pools and Fluid integrations. This provides users with consistent, deep markets for GHO trading and arbitrage. | Balancer GHO/USDC/USDT | Fluid GHO/USDC| | -------- | -------- | | !image| !image| Avalanche Launch The Avalanche deployment was another major highlight, supported by a dedicated incentive program. This initiative attracted more than $48M deposits into the Aave Avalanche instance, underscoring GHO’s ability to scale across chains. !image sGHO Growth During this phase, stkGHO was sunset and replaced by sGHO, the new savings rate mechanism. Since launch, sGHO supply has grown from 140M to over 180M, reflecting strong demand for a native yield-bearing stablecoin. !image The ALC is actively working with multiple DeFi and CeFi partners to integrate sGHO as a reserve asset or savings product. This positions sGHO as one of the key pillars of GHO adoption going forward. Path to Profitability Beyond growth, GHO is steadily advancing towards profitability for the DAO. By extending Phase VI to five months instead of three, the ALC effectively reduced cost-per-unit GHO growth, ensuring more efficient capital allocation. As circulation continues to expand, the impact of incentives becomes increasingly efficient. Every new GHO minted and adopted into the market dilutes the relative cost of the incentive budget, meaning that the same level of spend supports a larger base of supply. This compounding effect brings GHO closer to reaching break-even on incentive programs, after which the protocol can generate net positive returns for the DAO through facilitators, fees, and ecosystem integrations. In other words, growth itself is the path to profitability: as GHO scales, the unit economics improve naturally while the marginal cost of adoption falls. Phase VII Lookahead Remote GSM The upcoming remote GSM architecture is nearing readiness. This will enable seamless growth of GHO on new networks by allowing prefilled GSMs to act as local liquidity anchors without relying on inefficient bridging. New L2 Deployments GHO will soon be deployed to three new important L2s: Plasma, INK, and Linea. These ecosystems are poised to become major hubs of activity and will provide GHO with new markets and user bases. Centralized Exchange Expansion Following Bitget, the ALC is working with additional centralized exchanges to list GHO before the end of the year. These integrations will open further distribution channels and expand GHO’s presence beyond DeFi. sGHO ERC4626 Upgrade sGHO will be upgraded to an ERC4626-compliant version, streamlining integrations across the ecosystem. This upgrade will also enable flexibility for updating the savings product in line with the ASR proposal. Specification Create an allowance enabling the ALC to withdraw 2,500,000 aEthLidoGHO from the Prime instance. This represents a reduction from Phase VI’s budget, reflecting both the maturity of GHO and the DAO’s other growth priorities. The lower budget is designed to balance sustaining ongoing initiatives with funding new integrations on emerging networks. ALC Ethereum SAFE: 0xA1c93D2687f7014Aaf588c764E3Ce80aF016229b Disclosure TokenLogic receives no payment for this proposal. 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 Snapshot outcome is YAE, an AIP will implement this proposal. Copyright Copyright and related rights waived via CC0.

Summary This TEMP CHECK seeks the community’s input on deploying Aave v3 on X Layer, an upcoming blockchain designed to support DeFi, payments, and broader financial use cases. Motivation Aave Protocol has expanded to 16 networks and consistently ranks among the largest protocols by TVL and usage. As X Layer prepares for launch, this presents a strategic opportunity for Aave to integrate into a new chain with strong ambitions around payments, DeFi adoption, and liquidity growth. 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. This alignment has the potential to significantly grow Aave’s reach, strengthen user acquisition, 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. Key aspects of X Layer’s positioning include: Payments at the core: Designed to support payment use cases as a primary function of the network DeFi expansion: A strong emphasis on lending, borrowing, and liquidity markets as a foundation for the ecosystem. Seamless onboarding: Infrastructure that allows users to easily transition from traditional finance to DeFi with minimal friction. Scaling Ethereum: X Layer will offer Ethereum compatibility and a performant execution environment, providing developers and users with the flexibility to deploy existing Solidity-based applications. By deploying Aave v3 on X Layer, the protocol would position itself as the core liquidity layer for this new ecosystem, benefiting from first-mover advantage and integration with a payment-focused blockchain. Disclosure TokenLogic does not receive any payment for this proposal. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. Publication of 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.