Aave Governance

Summary This proposal asks the Aave DAO to apply a consistent rule to the isolated flag introduced in Aave V3.7 E-Modes: Set isolated = true when an E-Mode permits borrowing any asset whose general borrowing is disabled at the reserve level. Set isolated = false when all of an E-Mode's borrowable assets are also borrowable in the general market. The specified changes isolate 15 E-Modes and remove isolation from three. All other existing E-Modes remain unchanged, including the seven expiring PT categories identified below. The objective is to restrict E-Mode-only borrowing to its intended collateral set while allowing mixed collateral where the debt assets are already available in the general market. Motivation An E-Mode defines its own collateral and borrowable asset sets. Borrowing permission inside it follows the category's borrowable list, so an asset can remain borrowable in E-Mode even when general borrowing is disabled. In a non-isolated E-Mode, collateral outside the category retains its base-market LTV. This can allow unrelated collateral to back borrowing that was intended only for correlated positions. For example, a user can hold USDC while entering an LST E-Mode and borrow wstETH, despite general wstETH borrowing being disabled. The isolated flag closes this route by assigning zero LTV to collateral outside the E-Mode's collateral set. Where every debt asset is already generally borrowable, removing isolation restores the ability to combine collateral without opening an otherwise unavailable borrow market. User Impact Enabling isolation changes borrowing power, not liquidation thresholds. The flag change itself leaves health factors unchanged and does not trigger liquidations or force repayment of existing debt. Positions relying on outside collateral cannot be increased using that collateral, and accounts with outside collateral enabled cannot newly enter the isolated category. Affected users can restructure by withdrawing the zero-LTV collateral before collateral that still carries LTV, repaying enough debt to maintain a valid health factor. Alternatively, they can repay E-Mode-exclusive debt in full before leaving the category. Removing isolation restores the base-market LTV of outside collateral and therefore increases or preserves borrowing power. At the assessment dates, the affected categories held approximately $777M of total debt, including $45M in assets borrowable only within E-Modes. Approximately $445K of exclusive debt was backed by outside collateral. Most was concentrated in Polygon's MATIC correlated category, including a single wallet borrowing approximately $376K of WPOL against USDC. These figures describe the published assessment, not a live balance check. Specification Enable isolation: false → true | Aave V3 deployment | E-Mode | Category ID | E-Mode-only borrow asset(s) | | --- | --- | --- | --- | | Ethereum Core | rsETH (ETH/wstETH/ETHx) | 3 | wstETH, ETHx | | Ethereum Core | ezETH/wstETH | 22 | wstETH | | Ethereum Core | weETH/wstETH | 26 | wstETH | | Ethereum Prime | LRT wstETH main | 3 | wstETH | | Ethereum Prime | rsETH LST main | 5 | wstETH | | Ethereum Prime | tETH/wstETH | 7 | wstETH | | Arbitrum | ezETH/wstETH/WETH | 3 | wstETH | | Arbitrum | rsETH/wstETH/WETH | 5 | wstETH | | Base | ezETH wstETH | 2 | wstETH | | Base | rsETH/wstETH | 5 | wstETH | | MegaETH | wstETH Correlated | 4 | WETH | | MegaETH | wrsETH Correlated | 5 | WETH | | MegaETH | ezETH Correlated | 6 | WETH | | Gnosis | ETH correlated | 1 | WETH | | Polygon | MATIC correlated | 2 | WPOL | Remove isolation: true → false All borrowable assets in these categories have general borrow markets. | Aave V3 deployment | E-Mode | Category ID | | --- | --- | --- | | Mantle | WMNT/Stablecoins | 6 | | MegaETH | USDe/Stablecoins | 7 | | MegaETH | stcUSD/Stablecoins | 8 | Exceptions and implementation dependency Arbitrum rsETH/Stablecoins, category 6: leave non-isolated. Its exclusive borrow route is bridged USDC.e, which is covered by the pending low-adoption deprecation. Freezing that reserve prevents new borrowing both inside and outside E-Mode. Gnosis ETH correlated, category 1: enable isolation as specified above. WETH is also covered by the pending deprecation; the flag retains the restriction on outside collateral if the freeze is subsequently lifted. Monad: the two categories requiring isolation already have it enabled; no changes are proposed. Existing PT categories: leave Ethereum Core 47 and 48, Plasma 25 and 26, Monad 5, and XLayer 7 and 8 unchanged. These isolated categories phase out as their PTs mature. Future PT E-Modes should follow the borrow-side rule and be non-isolated where every debt asset has a general borrow market. Next Steps If this ARFC Snapshot passes, submit the changes as a single AIP payload, sequenced after the pending low-adoption deprecation. This sequencing preserves the basis for leaving Arbitrum's rsETH/Stablecoins category non-isolated. Disclaimer Prepared independently by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk has no direct affiliation with the protocols assessed and received no compensation from them or their affiliates for this work. This material is not legal, financial, tax, or professional advice.

Summary This proposal asks the Aave DAO to improve collateral efficiency for ETH- and BTC-family assets on Aave V3 Ethereum Core, Arbitrum, and Base, and on the Aave V4 Ethereum Main Spoke. The proposed changes raise loan-to-value (LTV) ratios, liquidation thresholds (LT), and V4 collateral factors (CF), as specified below. They also reduce the cbBTC liquidation bonus (LB) on Base from 7.50% to 6.00% and increase the parameters of Base's cbBTC Stablecoins E-Mode. LlamaRisk calibrated the recommendations against historical price movements, Chainlink feed updates, liquidation execution, and available liquidity, including the February and October 2025 stress events. Motivation Collateral parameters determine how much users can borrow and how much protection remains before a position becomes insolvent. This review assesses whether the existing ETH and BTC settings remain appropriate given observed volatility, liquidation performance, and market depth. The proposed increases aim to improve borrowing capacity while retaining buffers calibrated to each asset and deployment. Analysis The calibration uses the 99.9th percentile of adverse price excursions over a one-hour window. This window accounts for positions being worked down through successive liquidations, rather than assuming that an entire position is cleared in one transaction. Each collateral is assessed against the available debt assets on its deployment, using the most restrictive result and the applicable liquidation bonus. The proposed thresholds place WETH at its model ceiling, wstETH and weETH one percentage point below theirs, and BTC-family assets at least three percentage points below their ceilings. The additional BTC margin accounts for liquidity depth, caps, and concentration risks outside the price model. During the February and October 2025 stress events, economically meaningful liquidations were processed within minutes of the relevant oracle publication. The analysis found no bad debt for the ETH- and BTC-family collateral examined at the parameters then in place. Observed liquidation performance and exit liquidity also support applying the ETH calibration to wstETH and weETH. The calibration does not cover every historical extreme. Its residual risk includes a price move beyond the selected percentile coinciding with a prolonged interruption to oracle updates and liquidation execution. Historical performance at existing settings is evidence for the recommendation, rather than a guarantee of future outcomes at the proposed settings. Full methodology, charts, and supporting data are available in the forum discussion. Specification All values below are percentages. Arrows show current → proposed settings. Values marked unchanged are included for clarity. No other parameter changes are proposed. Aave V3 Ethereum Core | Asset | LTV | LT | LB (unchanged) | | --- | --- | --- | --- | | WETH | 80.5% → 81% | 83% → 84% | 5.00% | | WBTC | 73% → 81% | 78% → 85% | 5.00% | | cbBTC | 73% → 81% | 78% → 85% | 7.50% | | wstETH | 78.5% → 79% | 81% → 82% | 6.00% | | weETH | 77.5% → 78% | 80% → 81% | 7.00% | Ethereum Core liquidation bonuses remain unchanged. The forum proposal considers the separate liquidation protocol fee increase: reducing bonuses at the same time would further compress liquidators' net compensation. Aave V3 Arbitrum | Asset | LTV | LT | LB (unchanged) | | --- | --- | --- | --- | | WETH | 80% → 81% | 84% (unchanged) | 5.00% | | WBTC | 73% → 78% | 78% → 82% | 7.00% | Aave V3 Base | Asset | LTV | LT | LB | | --- | --- | --- | --- | | WETH | 80% → 81% | 83% → 84% | 5.00% (unchanged) | | cbBTC | 73% → 81% | 78% → 84% | 7.50% → 6.00% | The lower cbBTC bonus is supported by the approximately $33M of stablecoin liquidity identified in the Base assessment. Aave V3 Base: cbBTC Stablecoins E-Mode | Category ID | Collateral | Borrowable assets | LTV | LT | LB (unchanged) | | --- | --- | --- | --- | --- | --- | | 10 | cbBTC | GHO, USDC | 80% → 82% | 83% → 85% | 4.00% | Aave V4 Ethereum Main Spoke | Asset | CF | Maximum LB (unchanged) | | --- | --- | --- | | WETH | 83% → 84% | 5.55% | | wstETH | 80% → 82% | 6.66% | | weETH | 80% → 81% | 7.77% | | WBTC | 78% → 85% | 5.55% | | cbBTC | 78% → 85% | 5.55% | Apply the V4 collateral factor changes by updating the existing dynamic configuration, rather than deploying a new collateral configuration. Next Steps If this ARFC Snapshot passes, submit the specified changes for implementation through an Aave Improvement Proposal (AIP). Disclaimer Prepared independently by LlamaRisk, a DeFi risk service provider funded in part by the Aave DAO. LlamaRisk has no direct affiliation with the protocols assessed and received no compensation from them or their affiliates for this work. This material is not legal, financial, tax, or professional advice.

Summary This ARFC seeks community feedback on deploying Aave V4 on Base and activating an initial tokenized equities market. Base is an Ethereum Layer 2 incubated by Coinbase, with low transaction costs, native USDC liquidity, and access to a broad retail user base. Aave has operated on Base since 2023, and the network was among Aave's first multi-chain deployments to surpass $1 billion in deposits. The deployment would bring the Hub and Spoke architecture to one of Aave's largest existing deployments. It would establish a dedicated Equities Hub, separating liquidity and risk for the tokenized equities market from other Aave markets on Base, while providing a foundation for specialized markets as the network develops. Motivation Base combines an established Aave deployment, growing stablecoin activity, and an expanding set of consumer applications, payments products, and trading venues. These conditions support demand for onchain credit infrastructure that can serve distinct use cases while maintaining clearly defined liquidity and risk boundaries. Deploying Aave V4 on Base would: Upgrade one of Aave's largest existing deployments to the current protocol architecture. Establish a dedicated market for tokenized equities, with USDC as the borrowable asset and tokenized equities used exclusively as collateral at launch. Separate the liquidity and risk of this market from other Aave markets on Base through a dedicated Equities Hub. Extend Aave's presence within the Base and Coinbase ecosystem as additional users, applications, and tokenized assets come onchain. The initial market provides a focused implementation of the V4 architecture. A single pooled spoke will support the initial set of tokenized equities as collateral, allowing users to borrow USDC against diversified positions while maintaining asset-specific collateral factors. The equities themselves will not be borrowable at launch. Coinbase's distribution, infrastructure, and institutional relationships may support a broader range of tokenized assets on Base over time. A dedicated V4 market provides a measured starting point for this activity, with a market structure designed to accommodate distinct collateral types and risk profiles without extending their exposure to other Aave markets. Market Structure The tokenized equities market is deployed through a dedicated Equities Hub on Base. USDC suppliers to the hub explicitly opt into lending against tokenized equity collateral, and this exposure is isolated from other Aave markets. The Hub contains a single USDC reserve and two spokes. The Mag-7 Spoke supports USDC borrowing against the seven specified tokenized equities. The Tokenized USDC Spoke is supply only, providing vaults and aggregators with a composable USDC position without collateral exposure. Within the Mag-7 Spoke, users may supply any combination of the seven tokenized equities as collateral and borrow USDC. Each asset retains its own collateral factor, so borrowing capacity remains determined by the composition of each position. Pooling the assets within one spoke allows diversified collateral positions to be managed within a single market. The tokenized equities are collateral only at launch. Borrowing of equities, and positions that borrow one equity against another, are not enabled. Specification Dynamic Liquidation Bonus Configuration | Chain | Hub | Spoke | Liquidation Bonus Factor | Target Health Factor | Health Factor For Max Bonus | |-------|-----|-------|-------------------------:|---------------------:|----------------------------:| | Base | Equities Hub | Mag-7 Spoke | 90.00% | 1.24 | 0.90 | Spoke Parameters The liquidation fee is 10%, consistent with the rest of Aave V4. The risk premium threshold is 0 for every reserve, as risk premiums are not in use, and liquidators can receive collateral as shares on every reserve. | Chain | Hub | Spoke | Reserve | Collateral Factor | Max Liquidation Bonus | Borrowable | Collateral Risk | Liquidation Fee | Risk Premium Threshold | Receive Shares | |-------|-----|-------|---------|------------------:|----------------------:|------------|----------------:|----------------:|-----------------------:|----------------| | Base | Equities Hub | Mag-7 Spoke | AAPLc | 78.00% | 5.50% | FALSE | 0 | 10.00% | 0 | TRUE | | Base | Equities Hub | Mag-7 Spoke | AMZNc | 73.00% | 5.50% | FALSE | 0 | 10.00% | 0 | TRUE | | Base | Equities Hub | Mag-7 Spoke | GOOGLc | 76.00% | 5.50% | FALSE | 0 | 10.00% | 0 | TRUE | | Base | Equities Hub | Mag-7 Spoke | METAc | 65.00% | 5.50% | FALSE | 0 | 10.00% | 0 | TRUE | | Base | Equities Hub | Mag-7 Spoke | MSFTc | 79.00% | 5.50% | FALSE | 0 | 10.00% | 0 | TRUE | | Base | Equities Hub | Mag-7 Spoke | NVDAc | 70.00% | 5.50% | FALSE | 0 | 10.00% | 0 | TRUE | | Base | Equities Hub | Mag-7 Spoke | TSLAc | 65.00% | 5.50% | FALSE | 0 | 10.00% | 0 | TRUE | | Base | Equities Hub | Mag-7 Spoke | USDC | 0.00% | - | TRUE | - | - | 0 | TRUE | Add and Draw Caps | Chain | Hub | Spoke | Reserve | Add Cap | Draw Cap | |-------|-----|-------|---------|--------:|---------:| | Base | Equities Hub | Mag-7 Spoke | AAPLc | 15,000 | 0 | | Base | Equities Hub | Mag-7 Spoke | AMZNc | 10,500 | 0 | | Base | Equities Hub | Mag-7 Spoke | GOOGLc | 15,000 | 0 | | Base | Equities Hub | Mag-7 Spoke | METAc | 5,800 | 0 | | Base | Equities Hub | Mag-7 Spoke | MSFTc | 5,200 | 0 | | Base | Equities Hub | Mag-7 Spoke | NVDAc | 24,000 | 0 | | Base | Equities Hub | Mag-7 Spoke | TSLAc | 14,000 | 0 | | Base | Equities Hub | Mag-7 Spoke | USDC | 32,000,000 | 21,000,000 | | Base | Equities Hub | Tokenized USDC Spoke | USDC | 1,000,000 | 0 | Interest Rate Curve | Chain | Hub | Asset | Base Drawn Rate | Rate Growth Before Optimal | Rate Growth After Optimal | Optimal Usage Ratio | Liquidity Fee | |-------|-----|-------|----------------:|---------------------------:|--------------------------:|--------------------:|--------------:| | Base | Equities Hub | USDC | 0.00% | 4.00% | 20.00% | 90.00% | 10.00% | Price Feeds Each reserve is priced by the Chainlink total return feed for the token, which carries the issuer multiplier and follows the 24/5 US equities market hours. These are standard feeds. Smart Value Recapture variants are not used at rollout. USDC is priced by the Chainlink USDC/USD feed on Base through the stable price cap adapter, with the cap set at 1.04. | Reserve | Token | Chainlink feed | |---------|-------|----------------| | AAPLc | 0xb200000000000000000000C2e324d24d7eEcd1fb | 0x787f13dEa48Db0897CbCDD985de77809D837F988 | | AMZNc | 0xb200000000000000000000d9192b6B456483C2E8 | 0x06A8E4b3aBB3B7543d8396FB2B763d22820cB295 | | GOOGLc | 0xb2000000000000000000002D0BA3164cc74f58B7 | 0x5bF49E0ffA937CE2FfF033c739aD7C634c4D34F2 | | METAc | 0xb2000000000000000000008bC8786B856E61707C | 0x6526aE6797A76123638b863AeE4dD27Ba4E4b27D | | MSFTc | 0xB200000000000000000000Ab99cFa739E253872B | 0xeB10A6c9aa7E537aEd766C08c35Dae35B321b18c | | NVDAc | 0xB20000000000000000000078ee7ce2fE4908108C | 0x04689a41629776563E6822F76f2e57D148d28513 | | TSLAc | 0xb2000000000000000000001e800a7f5189430cD0 | 0xFaf869185383a24F8cb00e27BdA6b63B9905DCb4 | | USDC | 0x833589fCD6eDb6E08f4c7C32D4f71b54bdA02913 | 0x7e860098F58bBFC8648a4311b374B1D669a2bc6B, with the stable price cap adapter at 1.04 | Useful Links Base website Base developer documentation Aave V4 overview Disclosures Aave Labs is the author of this proposal and has received no compensation from third parties for its creation. Copyright Copyright and related rights waived via CC0.

Title: [ARFC] Activate Aave Risk Stewards on Aave V4 Author: Aave Labs Date: 2026-09-02 Summary This proposal seeks to activate the Aave Risk Steward on the Aave V4 Ethereum and Aave V4 Avalanche instances. If adopted, it would grant the Risk Steward bounded, revocable delegated authority to adjust a defined set of Hub, Spoke, and Oracle risk parameters within fixed cooldowns and a maximum change allowed per update. To keep that authority narrow, each instance's two configurator domain admin roles would first be split into five granular roles apiece, so the Risk Steward would receive only the risk management and emergency capabilities it needs. The Risk Steward contracts proposed for this activation are undergoing audit by Certora, with the engagement now reaching finalization. Motivation Today, adjusting any Hub, Spoke, or Oracle parameter, from interest rate curve tuning to collateral risk updates, requires a full governance cycle through the domain admin role on each instance's configurator, even when the change would fall within a range the DAO has already discussed. The Aave Risk Steward pattern already reduces this governance overhead on Aave V3 through the Aave Generalized Risk Stewards, where Risk Service Providers update parameters within bounds and cooldowns set by governance instead of returning to a vote for every adjustment. This proposal would extend the same pattern to Aave V4, activating the Aave Risk Stewards on the Ethereum and Avalanche instances with the bounds proposed below for Hub, Spoke, and Oracle parameters. Specification Configurator role split The proposed scope of each new role is as follows. | Concern | Hub role | Spoke role | Scope | |----|----|----|----| | Prevent all activity | HUBCONFIGURATORSPOKEACTIVEROLE (201) | SPOKECONFIGURATORPAUSE_ROLE (401) | Flips the flag that prevents all activity, in both directions. updateSpokeActive on the Hub, updatePaused on the Spoke. | | Prevent new activity | HUBCONFIGURATORSPOKEHALTEDROLE (202) | SPOKECONFIGURATORFREEZE_ROLE (402) | Flips the flag that prevents new activity, in both directions. updateSpokeHalted on the Hub, updateFrozen on the Spoke. | | Listing | HUBCONFIGURATORLISTINGROLE (203) | SPOKECONFIGURATORLISTINGROLE (403) | addAsset, addAssetWithDecimals, addSpoke, addSpokeToAssets on the Hub. addReserve, updateBorrowable, updateReceiveSharesEnabled on the Spoke. | | Emergency | HUBCONFIGURATOREMERGENCYROLE (204) | SPOKECONFIGURATOREMERGENCYROLE (404) | The batch flag actions that only ever move toward a safer state. deactivateAsset, haltAsset, deactivateSpoke, haltSpoke on the Hub. pauseReserve, pauseAllReserves, freezeReserve, freezeAllReserves on the Spoke. | | Risk management | HUBCONFIGURATORRISKMANAGEMENTROLE (205) | SPOKECONFIGURATORRISKMANAGEMENTROLE (405) | updateSpokeAddCap, updateSpokeDrawCap, updateSpokeCaps, updateSpokeRiskPremiumThreshold, updateInterestRateData on the Hub. updateCollateralRisk, addCollateralFactor, updateCollateralFactor, addMaxLiquidationBonus, updateMaxLiquidationBonus, addLiquidationFee, updateLiquidationFee, addDynamicReserveConfig, updateDynamicReserveConfig, updateLiquidationTargetHealthFactor, updateHealthFactorForMaxBonus, updateLiquidationBonusFactor, updateLiquidationConfig on the Spoke. | | Residual domain admin | HUBCONFIGURATORDOMAINADMINROLE (200) | SPOKECONFIGURATORDOMAINADMINROLE (400) | updateLiquidityFee, updateFeeReceiver, updateFeeConfig, updateInterestRateStrategy, updateReinvestmentController, resetAssetCaps, resetSpokeCaps on the Hub. updateReservePriceSource, updatePositionManager on the Spoke. | The two flag roles would be named after the flag they own rather than after pause and freeze, because the Hub carries no paused or frozen flag of its own. Its equivalent state is the Spoke active flag, tracked per asset, which gates every Hub action, and the halted flag, which gates the actions that instantly update liquidity. The emergency role is proposed as separate from both because every one of its selectors only ever moves a target to a safer state and can never move it back, so it could be delegated to an entity that can act faster than the two flag roles, which move state in either direction. The Hub's batch cap resets are proposed to stay with the domain admin role: zeroing caps moves in only one direction, the same as a halt, but only risk management could restore them, so restoring capped values would remain a governance action. Role IDs and selector sets would match Roles.sol in the Aave V4 repository, following the convention of appending new IDs while the domain admin role's selector set shrinks. Existing IDs would never be repurposed, so the two domain admin roles would retain the selectors that fall outside the five new roles, and every address holding a domain admin role today would be granted the corresponding five new roles, preserving its current reach. Risk Steward parameter bounds For each parameter, the cooldown would set the minimum time between successive Risk Steward updates, the maximum change per update would cap how far a single update can move the parameter, and the mode would determine whether that maximum applies as an absolute change or one relative to the parameter's current value. The same bounds are proposed for both the Aave V4 Ethereum and Aave V4 Avalanche instances. | Scope | Parameter | Cooldown | Max change per update | Mode | |----|----|----|----|----| | Hub | optimalUsageRatio | 36 hours | 3% | absolute | | Hub | baseDrawnRate | 36 hours | 3% | absolute | | Hub | rateGrowthBeforeOptimal | 36 hours | 3% | absolute | | Hub | rateGrowthAfterOptimal | 36 hours | 20% | absolute | | Hub | addCap | 36 hours | 100% | relative | | Hub | drawCap | 36 hours | 100% | relative | | Spoke | collateralRisk | 36 hours | 300% | absolute | | Spoke | collateralFactor (update) | 72 hours | 0.5% | absolute | | Spoke | maxLiquidationBonus (update) | 72 hours | 0.5% | absolute | | Spoke | collateralFactor (addition) | 72 hours | 5% | absolute | | Spoke | maxLiquidationBonus (addition) | 72 hours | 0.5% | absolute | | Spoke | targetHealthFactor | 72 hours | 5% | relative | | Spoke | healthFactorForMaxBonus | 72 hours | 5% | relative | | Spoke | liquidationBonusFactor | 72 hours | 5% | absolute | | Oracle | priceCapLst | 72 hours | 5% | relative | | Oracle | priceCapStable | 72 hours | 0.5% | relative | | Oracle | discountRatePendle | 48 hours | 0.025 | absolute | Risk Steward grants It is proposed that each Risk Steward be granted four of the new roles on its instance's AccessManager, with no execution delay: HUBCONFIGURATORRISKMANAGEMENTROLE, HUBCONFIGURATOREMERGENCYROLE, SPOKECONFIGURATORRISKMANAGEMENTROLE, and SPOKECONFIGURATOREMERGENCYROLE. The two risk management roles are what the bounds above would require: without them the Risk Steward could not reach either configurator. The two emergency roles are proposed alongside so that a future Risk Steward release could respond to an emergency without a further governance cycle; the release proposed here calls none of their selectors, so they would remain inert until then. It is further proposed that each Risk Steward be granted RISK_ADMIN on its instance's Aave V3 ACLManager, needed for the priceCapLst, priceCapStable, and discountRatePendle bounds above to take effect through the shared CAPO adapters. Disclaimer Aave Labs is presenting this proposal as a contributor to the Aave ecosystem. Aave Labs is putting forward this proposal as part of its ongoing work on the Aave Protocol's risk management infrastructure and has no undisclosed financial interest in its outcome. Next Steps 1. Gather community feedback during the ARFC stage. 2. If the ARFC response is positive, escalate to Snapshot for off-chain confirmation. 3. Following a positive Snapshot outcome, execute the corresponding payloads through the V4 Security Council to activate the Risk Steward on the Aave V4 Ethereum and Aave V4 Avalanche instances. Copyright Copyright and related rights waived via CC0. *

Title: [ARFC] Deploy Aave V4 on Arc Author: Aave Labs Date: 2026-09-02 Summary This ARFC proposes deploying Aave Protocol V4 on Arc Network. Motivation Aave Labs proposes deploying Aave V4 on Arc, the institutional-grade public layer-1 blockchain built by Circle, at or near Arc mainnet launch. The initial deployment would activate with one Liquidity Hub and two Spokes, supporting an initial set of high-quality assets: USDC, EURC, WETH and cirBTC. Relative to the Temp Check, which proposed an initial scope of USDC, EURC and cirBTC, this ARFC adds WETH as a fourth launch asset in response to demand signals from prospective liquidity providers and to strengthen day-one borrow markets. Following the Temp Check, this ARFC sets out the proposed initial token listing and parameters. Deploying on Arc provides several benefits: Positions Aave as a core lending protocol at launch. Increases market access for Circle-issued assets. Expands Aave’s reach into institutional liquidity flows. Generates additional protocol TVL and revenue. Arc’s infrastructure is designed to concentrate stablecoin and tokenized asset liquidity, making it a logical fit for Aave. Following the passing of the TEMP CHECK Snapshot, this ARFC sets out the proposed launch topology, asset scope, oracle configuration, incentive structure, and rollout path. Rollout The rollout will follow a deliberately conservative, phased path. The deployment would launch at or near Arc mainnet with conservative caps, followed by monitored expansion and cap increases per LlamaRisk recommendations as live conditions support. Additional assets, including further RWA assets, could be onboarded through subsequent governance processes. Incentive and Revenue Structure In connection with the deployment, Aave DAO is expected to receive a minimum of $2m per year in protocol revenue from the Aave V4 deployment on Arc, with any shortfalls covered by certain Arc ecosystem participants for the first five years following deployment. This structure provides protection for Aave DAO during the bootstrap phase. Specification Market Design The launch configuration consists of one hub and two spokes. The Core Hub serves as the sole borrowing environment, structured around two spokes targeting a distinct collateral type, user intent, and risk profile: Main Spoke: The Main Spoke is the general-purpose lending venue and is expected to host the majority of liquidity within the deployment. It accepts the broadest collateral set and the broadest borrowable set in the deployment, where USDC, cirBTC, and wETH are collateral against which users can borrow USDC, EURC, cirBTC, and wETH. In the future, the Main Spoke can provide credit lines to specialized Hubs, allowing them to access its liquidity while preserving separate risk profiles. Forex Spoke: It supports trading and hedging across fiat-pegged stablecoins, with EURC and USDC as collateral, which can be borrowed against each other. Due to limited secondary market liquidity for EURC, conservative caps have been set. In addition to the two spokes above, a tokenized spoke layer will also be created, which is a supply-only integration layer that tokenizes deposits of the Core Hub's borrowable assets (USDC, EURC, cirBTC, and wETH) into composable positions for external vaults, aggregators, and strategies, without enabling borrowing or introducing additional collateral risk to the Core Hub. Dynamic Liquidation Bonus Configuration V4 replaces V3's static liquidation bonus with a dynamic bonus that scales with the health factor. Each spoke is configured through three parameters: the Target Health Factor (the HF a borrower is restored to after liquidation), the Health Factor For Max Bonus (the HF at which the maximum bonus is reached), and the Liquidation Bonus Factor (which scales the curve so the bonus at an HF of 1.0 matches the corresponding V3 value). The Forex Spoke uses correlated-asset settings, and the Main Spoke applies a wider curve suited to volatile collateral. | Chain | Hub | Spoke | Liquidation Bonus Factor | Target Health Factor | Health Factor For Max Bonus | |-------|-----|-------|--------------------------|----------------------|-----------------------------| | Arc | Core Hub | Main Spoke | 90.00% | 1.2400 | 0.90 | | Arc | Core Hub | Forex Spoke | 100.00% | 1.0442 | 0.99 | V4 Spoke Parameters The liquidation protocol fee is to be set at 10% across all assets, aligning with the configuration used for the majority of assets on Aave V3. | Chain | Hub | Spoke | Reserve | Collateral Factor | Max Liquidation Bonus | Borrowable | Collateral Risk | Liquidation Fee | |-------|-----|-------|---------|-------------------|-----------------------|------------|-----------------|-----------------| | Arc | Core Hub | Main Spoke | cirBTC | 78.00% | 7.22% | TRUE | 0 | 10.00% | | Arc | Core Hub | Main Spoke | USDC | 78.00% | 5.55% | TRUE | 0 | 10.00% | | Arc | Core Hub | Main Spoke | wETH | 83.00% | 5.55% | TRUE | 0 | 10.00% | | Arc | Core Hub | Main Spoke | EURC | 0.00% | - | TRUE | - | - | | Arc | Core Hub | Forex Spoke | EURC | 90.00% | 2.00% | TRUE | 0 | 10.00% | | Arc | Core Hub | Forex Spoke | USDC | 90.00% | 2.00% | TRUE | 0 | 10.00% | Add and Draw Caps The Add Cap and Draw Cap values below are preliminary. They are set conservatively ahead of liquidity being deployed on-chain, where secondary-market depth is not yet established, and reflect the hub-and-spoke structure of Aave V4 and the distinct risk profiles of each spoke. These values may be refined once liquidity is deployed and market conditions become observable on-chain. For USDC and EURC, the cumulative Add Cap is distributed across the Main and Forex Spokes. Add Cap and Draw Cap are denominated in token units. | Chain | Hub | Spoke | Reserve | Add Cap | Draw Cap | |-------|-----|-------|---------|---------|----------| | Arc | Core Hub | Main Spoke | cirBTC | 1,100 | 220 | | Arc | Core Hub | Main Spoke | USDC | 56,000,000 | 51,000,000 | | Arc | Core Hub | Main Spoke | wETH | 24,000 | 4,800 | | Arc | Core Hub | Main Spoke | EURC | 20,000,000 | 18,000,000 | | Arc | Core Hub | Forex Spoke | EURC | 10,000,000 | 9,000,000 | | Arc | Core Hub | Forex Spoke | USDC | 13,000,000 | 11,000,000 | | Arc | Core Hub | Core Tokenized USDC Spoke | USDC | 10,000,000 | 0 | | Arc | Core Hub | Core Tokenized EURC Spoke | EURC | 9,000,000 | 0 | | Arc | Core Hub | Core Tokenized cirBTC Spoke | cirBTC | 160 | 0 | | Arc | Core Hub | Core Tokenized wETH Spoke | wETH | 6,000 | 0 | Tokenized Spokes serve as the standard entry point for integrators, vaults, aggregators, and other strategies routing liquidity into Aave V4 markets. They are supply-only and accept deposits exclusively in each hub's primary borrowable assets, ensuring a simple, composable tokenized representation. Interest Rate Curves The IRM parameters apply to an asset across all spokes within that hub. The parameters follow the same two-slope utilization curve used in V3, defined by a base variable borrow rate, slope below the optimal usage ratio (Slope 1), slope above it (Slope 2), and the optimal usage ratio itself (Uoptimal). The Liquidity Fee is the fraction of borrower interest captured by the protocol treasury, equivalent to the reserve factor in V3. The goal of the initial configuration is to keep the setup as similar as possible to the one currently used in Aave V3. | Chain | Hub | Reserve | Base | Slope 1 | Slope 2 | Uoptimal | Liquidity Fee | |-------|-----|---------|------|---------|---------|----------|---------------| | Arc | Core Hub | USDC | 0.00% | 4.10% | 10.00% | 90.00% | 10.00% | | Arc | Core Hub | EURC | 0.00% | 5.50% | 50.00% | 90.00% | 10.00% | | Arc | Core Hub | cirBTC | 0.25% | 4.00% | 60.00% | 80.00% | 20.00% | | Arc | Core Hub | wETH | 0.00% | 2.20% | 8.00% | 90.00% | 15.00% | Oracle Configuration Oracle assignments for V4 Arc deployment replicate the existing V3 and V4 configurations, applying the Capped USDC/USD and EURC/USD feeds with an upside cap of 1.04 to price the respective stablecoins, ETH/USD feed for wETH, and the BTC/USD feed for cirBTC. Next Steps 1. Gather community feedback and risk analysis from LlamaRisk 2. Escalate the proposal to the ARFC Snapshot stage. 3. If the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Disclaimer Aave Labs is not compensated by Arc, nor affiliated with them. Copyright Copyright and related rights waived via CC0. *

[ARFC] Onboard cirBTC on Aave v3 Core and Aave V4 Core Author: Aave Labs Date: 2026-08-31 Summary This proposal seeks to onboard Circle Wrapped Bitcoin (cirBTC) to the Aave V3 Core Instance and the Aave V4 Core Instance on Ethereum, with collateral functionality enabled. Motivation cirBTC is an ERC-20 representation of native BTC issued by Circle, launched on Ethereum mainnet on June 8, 2026. Each unit is backed 1:1 by Bitcoin custodied at a regulated Circle entity and segregated from Circle's corporate assets. Onboarding cirBTC as a collateral asset is aligned with the DAO's long-term objectives in several ways: It broadens the set of BTC denominated collateral available on Aave, complementing existing wrapped Bitcoin exposures already present on the Core instances. It enables users to borrow against a regulated, BTC backed wrapped representation, supporting demand from institutional participants and DeFi protocols. It strengthens the Core instances' position as a venue for BTC denominated leverage and liquidity strategies. Specification Aave V3 Specific Parameters Instance: Ethereum Core | Parameter | Recommendation | |-----------|----------------| | Borrowable | Yes | | Collateral Enabled | Yes | | Supply Cap | 250 | | Borrow Cap | 20 | | LTV | 73% | | LT | 78% | | Liquidation Bonus | 5% | | Liquidation Protocol Fee | 20% | | Reserve Factor | 50% | | Base Variable Borrow Rate | 0.25% | | Variable Slope 1 | 4% | | Variable Slope 2 | 60% | | Uoptimal | 80% | | Flashloan Enabled | Yes | Aave V4 Specific Parameters Spoke Parameters | Chain | Hub | Spoke | Reserve | Collateral Factor | Max Liquidation Bonus | Borrowable | Collateral Risk | Liquidation Fee | Risk Premium Threshold | ReceiveShares | |-------|-----|-------|---------|-------------------|-----------------------|------------|-----------------|-----------------|------------------------|---------------| | Ethereum | Core Hub | Main Spoke | cirBTC | 78% | 5.55% | TRUE | 0 | 10% | 0 | TRUE | Add and Draw Caps | Chain | Hub | Spoke | Reserve | Add Cap | Draw Cap | |-------|-----|-------|---------|---------|----------| | Ethereum | Core Hub | Main Spoke | cirBTC | 250 | 25 | Interest Rate Curve | Chain | Hub | Asset | Base | Slope 1 | Slope 2 | Uoptimal | Liquidity Fee | |-------|-----|-------|------|---------|---------|----------|---------------| | Ethereum | Core Hub | cirBTC | 0.25% | 4% | 60% | 80% | 20% | Price feed Recommendation Use Chainlink’s BTC/USD feed to price cirBTC on Aave V3 and V4. Useful Links Circle cirBTC product page Circle announcement: cirBTC is Live on Ethereum Disclaimer This proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem. Aave Labs has no financial relationship with Circle or any of its affiliates and has not received compensation from Circle in connection with this proposal. Next Steps 1. Gather community feedback during the ARFC stage. 2. Service Providers to post Asset Technical Assessment and Asset Risk Assessment, including supply caps, reserve factor, interest rate parameters, and oracle configuration for both instances. 3. If the ARFC response is positive, escalate to Snapshot for off-chain confirmation. 4. Submit the corresponding AIP for on-chain enforcement on the Aave V3 Core. Execute the corresponding transaction through the V4 Security Council on the Aave V4 Core. Copyright Copyright and related rights waived via CC0. *

Summary This proposal asks the Aave DAO to increase the Liquidation Protocol Fee (LPF) from 10% to 20% for WBTC, WETH, and wstETH on Aave V3 Ethereum Core. All other reserves and markets would remain unchanged. The LPF is the share of a liquidation bonus that accrues to the Aave treasury. LlamaRisk reviewed every liquidation on Ethereum Core from April 2025 through June 2026 and modeled the effect of higher fee levels on treasury revenue and liquidator behavior. Backtesting indicates that a 20% LPF on these three collaterals would have increased net treasury revenue by approximately $1.35M–$2.23M per year, after accounting for displaced Chainlink Smart Value Recapture (SVR) income. Including the October 10, 2025 crash week, the estimated increase is $1.20M–$2.15M per year. No bad debt attributable to the proposed fee was identified in either window. Expressed independently of future liquidation volume, Aave’s expected revenue per dollar liquidated on these assets would rise from approximately 173 bps today to 187–196 bps, an increase of roughly 8%–13%. LlamaRisk recommends 20% as a measured first step. Higher fees may generate more revenue in normal conditions, but they also create greater uncertainty and tail risk by compressing liquidator margins. A broader increase would expose thinner collateral markets that are less able to absorb it. Motivation Ethereum Core earns liquidation revenue through two mechanisms: The static LPF, deducted from the liquidation bonus. The SVR auction, where liquidators bid away part of their remaining margin; 65% of auction proceeds accrue to Aave and 35% to Chainlink. Because both mechanisms draw from the same liquidation surplus, a higher LPF partly replaces SVR revenue rather than adding entirely new income. If the fee becomes too high, some liquidations may no longer be profitable. Those liquidations would generate neither LPF nor SVR revenue and could increase risk during market stress. The appropriate fee must therefore be evaluated on net revenue—not gross fee collection—and on whether liquidators retain enough margin to operate reliably. Analysis LlamaRisk measured 14,006 liquidations representing approximately $1.05B of seized collateral. The analysis used onchain data and block-level oracle prices, including DEX price impact, gas costs, payments to block builders, and SVR auction proceeds. The primary measurement window runs from October 13, 2025 to June 1, 2026, after SVR order flow was fully integrated with the dominant block builders. The October 10 crash week was separately added as a stress test. WBTC, WETH, and wstETH represented approximately $612M of liquidated value in the post-October window and produced most of the modeled portfolio-wide fee gain. These assets have deep markets and the most redundant liquidator coverage on Aave. Estimated annual net revenue increase versus the current 10% LPF: | Proposed LPF | WBTC | WETH | wstETH | Total | |---|---:|---:|---:|---:| | 20% | $0.38M–$0.88M | $0.81M–$0.84M | $0.16M–$0.51M | $1.35M–$2.23M | The range reflects two treatments of liquidations that a higher fee would make unprofitable: The conservative bound assumes they do not execute. The upper bound assumes they still execute and pay the fee. At 20%, both treatments show a material net gain with no attributable bad debt. Higher fee levels widen the gap between the bounds because actual liquidator behavior cannot be known in advance. Under conservative assumptions, Aave’s revenue per dollar liquidated peaks near a 30% LPF and eventually falls below the current level as more liquidations become uneconomic. This uncertainty is particularly important during stress. The LPF is static and continues taking the same share when liquidator margins compress, whereas SVR auction bids naturally decline with available surplus. For that reason, approximately 30% should be treated as the maximum supported by the current evidence—not as the recommended setting. Why the proposal is limited to three assets The same fee level does not carry the same risk across all reserves. Smaller collateral markets generally have higher price impact, fewer liquidators, and thinner margins. In the portfolio-wide assessment, BAL was net negative at both 20% and 30% and accounted for the entire modeled bad-debt line, despite generating only approximately $30K–$60K of additional annual fee revenue. Similar, though less pronounced, constraints appear across other smaller reserves. Limiting the change to WBTC, WETH, and wstETH captures the best-supported revenue gain without shifting disproportionate risk to assets least able to absorb it. Risk assessment A liquidation remains viable only while the bonus covers execution costs and leaves the liquidator an adequate margin. The analysis treats a liquidation as unexecuted when the proposed fee would leave the liquidator less than 10% of the bonus as profit, a stricter threshold than pure break-even. For every affected position, LlamaRisk reconstructed the borrower’s health factor for the following 100 blocks, or approximately 20 minutes. Across 465 positions representing approximately $354M, one position in the post-October window crossed the bad-debt threshold, with a negligible shortfall. Across both windows, ten positions crossed the threshold with a combined shortfall of approximately $0.55M; nine were WETH positions liquidated during the October 10 crash while already insolvent at the current fee. The backtest cannot predict a future event more severe than October 2025 or determine exactly how liquidators will respond to a fee change that has not yet occurred during the SVR era. Market-maker liquidations are a further source of uncertainty because some execution margins are not observable onchain. These limitations support implementing 20%, observing real behavior, and reassessing only after sufficient post-change data is available. Specification | Market | Asset | Parameter | Current | Proposed | |---|---|---|---:|---:| | Aave V3 Ethereum Core | WBTC | Liquidation Protocol Fee | 10% | 20% | | Aave V3 Ethereum Core | WETH | Liquidation Protocol Fee | 10% | 20% | | Aave V3 Ethereum Core | wstETH | Liquidation Protocol Fee | 10% | 20% | All other reserves and markets remain unchanged. Next steps If this ARFC Snapshot passes, the parameter changes will be implemented through an Aave Improvement Proposal (AIP). Following implementation, LlamaRisk will monitor liquidation execution, SVR recapture, and liquidator margins on the affected collaterals, including during the next market stress event. 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 protocols reviewed and did not receive compensation from them or their affiliates for this work.

[ARFC] Aave Governance Emergency Guardian: Signer Rotation Author: Aave Labs Date: 2026-08-19 Summary This ARFC proposes updating the signer composition of the Aave Governance Emergency Guardian. The Governance Emergency Guardian will retain its existing 5-of-9 threshold, permissions, and Safe addresses. Only the underlying signer set will change. The updated roster consists of active and stakeholders with a strong security posture capable of maintaining the operational readiness required by the role. Signer identities will not be formally attributed in public documentation. Only the signing addresses will be disclosed. Motivation The current Governance Emergency Guardian signer set was ratified in 2024. Since then, the Aave DAO’s stakeholder landscape has evolved, making it appropriate to refresh the signer composition and ensure that the Guardian remains operationally resilient. The Governance Emergency Guardian provides a protective backstop for Aave Governance. Its role is to cancel governance proposals or payloads that are malicious, materially erroneous, or otherwise unsafe to execute. Aave Governance contracts cannot independently determine the semantic intent or safety of a proposal. If a malicious proposal is submitted, its creator cannot be expected to cancel it voluntarily. The Governance Emergency Guardian therefore remains an essential final safeguard within the governance process. Although this role is exercised infrequently and carries less time pressure than the Protocol Emergency Guardian, it must still be possible to contact signers and assemble quorum within the applicable governance lifecycle. This rotation is intended to: Refresh the signer set to reflect the DAO’s current stakeholder landscape. Maintain a reliable and reachable quorum. Improve operational resilience and signer availability. Preserve separation between the responsibility to cancel governance actions and the responsibility for protocol emergencies. Reduce the security risks created by publicly attributing individual signers. The DAO thanks all current and outgoing signers for their service and support. Signer privacy and operational security The public attribution of individual signers can create avoidable security risks, including targeted phishing, social engineering, coercion, and attempts to compromise signing devices or communication channels. Following the approach adopted for the Protocol Emergency Guardian rotation, the specification below identifies signers only by their signing addresses. The addresses must necessarily remain public onchain. Some retained addresses may already have historical public attribution. This proposal does not provide or expand the attribution of the proposed signer set. Before implementation, every signer should confirm compliance with the operational security requirements of the role. Signers remain responsible for maintaining compliance with these requirements for the full duration of their tenure as a signer, including: Use of a hardware wallet or equivalently secure signing setup. Verified out-of-band communication for signing requests. Independent verification of every transaction before signing. Continued availability and access to the designated signing account. Specification The Aave Governance Emergency Guardian will retain its existing 5-of-9 configuration and be updated to the following signer set: | Signer | Address | | --- | --- | | Signer 1 | 0x61C2dAE896f93e5f0f10425914CE7868eE8A0e44 | | Signer 2 | 0x2694B8A8490f10f98Da6F83d18267Eae9412CbF1 | | Signer 3 | 0x1e3804357eD445251FfECbb6e40107bf03888885 | | Signer 4 | 0xb291232F480F41c75802C4a60F1D2AC03404Afef | | Signer 5 | 0xDA5Ae43e179987a66B9831F92223567e1F38BE7D | | Signer 6 | 0x985F3290d7971a840152E46d00b5ceb60A56f235 | | Signer 7 | 0x9EF7c9A17c5881d54A4694785637acD93E790403 | | Signer 8 | 0x4f96743057482a2E10253AFDacDA3fd9CF2C1DC9 | | Signer 9 | 0xA3103D0ED00d24795Faa2d641ACf6A320EeD7396 | Scope of changes This proposal does not expand or otherwise modify the authority of the Governance Emergency Guardian. The following remain unchanged: The 5-of-9 signature threshold. Existing Governance Emergency Guardian Safe addresses. Governance and PayloadsController permissions assigned to those Safes. The conditions and processes under which cancellation powers should be exercised. Implementation is expected to consist solely of transactions that rotate ownership on each Governance Emergency Guardian Safe. A chain-by-chain execution manifest should be published before implementation to ensure every deployed Safe is updated and subsequently verified. Disclaimer This proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem. Next steps 1. Gather feedback from the Aave community. 2. If community sentiment is favorable, proceed to an ARFC Snapshot. 3. If the Snapshot outcome is YAE, confirm the operational readiness of all proposed signers. 4. Publish the complete chain-by-chain execution manifest. 5. Execute the signer rotations while retaining the 5-of-9 threshold. 6. Verify the resulting owner set on every deployment and update the relevant documentation. If technical review determines that any Guardian Safe address or assigned permission must change, the necessary changes should be submitted through an AIP. Otherwise, no change to the Governance Emergency Guardian’s onchain permissions is required. References Aave Emergency Guardian (Protocol): Signer Rotation ARFC: Renewal of Aave Guardian - 2024 Technical maintenance proposal establishing the current Governance Guardian Safes Copyright Copyright and related rights waived under (CC0)[https://creativecommons.org/publicdomain/zero/1.0/]. *

[ARFC] Onboard PAXG to the Global Dollar Hub in Aave V4 Ethereum Author: Aave Labs Date: 2026-08-19 Summary This proposal seeks to onboard Pax Gold (PAXG) to the Global Dollar Hub on the Aave V4 Ethereum instance. Final asset configuration will be determined by the Risk Service Providers. Motivation PAXG is an ERC-20 token issued by Paxos Trust Company, where each unit represents one fine troy ounce of a London Good Delivery gold bar held in professional vaults. Redemption and custody are administered by a regulated issuer, and holdings are subject to periodic third-party attestations. Onboarding PAXG to the Global Dollar Hub is aligned with the DAO's long-term objectives in several ways: - It introduces a gold-backed, real-world asset to the Aave V4 Ethereum instance, broadening the range of collateral and liquidity available beyond dollar-denominated exposures. - It gives users access to a regulated, physically-backed representation of gold within the Aave ecosystem, supporting demand from institutional participants and DeFi protocols seeking commodity exposure. - It complements the Global Dollar Hub's existing composition, adding a non-correlated asset that strengthens the instance's position as a venue for diversified liquidity strategies. Specification This proposal adds PAXG to Aave V4 Global Dollar Hub in Ethereum Token Address: 0x45804880De22913dAFE09f4980848ECE6EcbAf78 Likewise, adds PAXG as a collateral-only asset to a new Spoke named Gold Spoke. In parallel, to avoid additional governance proposals, enables native USDG as a borrowable reserve on the Pendle Spoke with a 4,000,000 USDG Draw Cap. Dynamic Liquidation Bonus Configuration As a non-crypto open-market spoke, it merits more conservative liquidation restoration parameters. Draw Caps will be set conservatively to reflect the Gold Spoke’s still-developing borrow-side liquidity profile. Spoke-level liquidation parameters: | Parameter | Value | Rationale | | --- | --- | --- | | targetHealthFactor | 1.20 | Open-market non-crypto collateral dynamics require more conservative post-liquidation restoration to reduce reliquidation risk. | | healthFactorForMaxBonus | 0.90 | Lower trigger avoids overpaying incentives too early while still reaching max LB before the deficit zone. | | liquidationBonusFactor | 0.80 | Matches the Main Spoke baseline and preserves V3-equivalent Gold correlated asset bonus at HF~1 with a 1.25x max LB cap. | Spoke Parameters | Hub | Spoke | Reserve | Collateral Factor | Max Liquidation Bonus | Borrowable | Collateral Risk | Liquidation Fee | riskPremiumThreshold | receiveShares | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Global Dollar Hub | Gold Spoke | PAXG | 75.00% | 6.50% | FALSE | 0 | 10.00% | 0 | TRUE | | Global Dollar Hub | Gold Spoke | USDG | 0.00% | - | TRUE | - | - | 0 | TRUE | | Global Dollar Hub | Pendle Spoke | USDG | 0.00% | - | TRUE | - | - | 0 | TRUE | riskPremiumThreshold is set to 0 for all reserves, in line with other assets across V4, as risk premiums are not currently in use. receiveShares is enabled for all reserves. Add and Draw Caps | Hub | Spoke | Reserve | Add Cap | Draw Cap | | --- | --- | --- | --- | --- | | Global Dollar Hub | Gold Spoke | PAXG | 2500 | 0 | | Global Dollar Hub | Gold Spoke | USDG | 5,000,000 | 9,500,000 | | Global Dollar Hub | Pendle Spoke | USDG | - | 4,000,000 | Oracle List PAXG against the Chainlink XAU/USD price feed, pricing the token at underlying gold spot with no CAPO growth-ceiling wrapper. PAXG carries no monotonic exchange-rate growth for a cap to bound, so a CAPO adapter is not recommended. The accepted risks are a sustained token-level dislocation priced at full gold spot and the feed’s weekend staleness. The liquidation parameters set at any future collateral-enable phase must absorb that envelope rather than assume a continuously updating reference. Disclaimer This proposal was prepared by Aave Labs in its capacity as a contributor to the Aave ecosystem. Aave Labs has no financial relationship with Paxos Trust Company or any of its affiliates and has not received compensation from Paxos in connection with this proposal. Next Steps 1. Gather community feedback during the ARFC stage. 2. Service Providers to post Asset Technical Assessment and Asset Risk Assessment. 3. If the ARFC response is positive, escalate to Snapshot for off-chain confirmation. 4. Execute the corresponding transaction through the V4 Security Council to onboard PAXG to the Global Dollar Hub on the Aave V4 Ethereum instance. Copyright Copyright and related rights waived via CC0. *

Summary This ARFC proposes deploying an instance of the remoteGSM for GHO on X Layer. Motivation X Layer is expected to act as both a payment-focused network and a DeFi hub, creating new avenues for user onboarding, real-world adoption, and capital efficiency. Deploying GHO concurrently with the Aave instance on X-Layer ensures that GHO has every chance of becoming foundational to DeFi and payments infrastructure on a chain optimized for Money 2.0 utility. The goal is to establish GHO as a key stablecoin within X Layer’s ecosystem from inception, facilitating reward programs, liquidity incentives, and seamless integration with the upcoming Aave deployment. Specification Mint and bridge 25,000,000 GHO Mint 25M GHO from the GhoDirectFacilitator and bridge to XLayer via CCIP to XLayer's Collector. TokenPool Configuration: Bucket Capacity: Increase by 25M GHO Inbound Capacity: 5M GHO Outbound Capacity: 5M GHO Refill Rate: 1,000 GHO/sec CCIP Bridge Configuration Deploy instance of the AaveGhoCCIPBridge on X-Layer. Configure Mainnet instance to be able to send minted GHO to X-Layer. Deploy GSM |Parameter | Value| |:-- | :--| |stataUSDG Exposure Cap | 20M| |Freeze Lower Bound | $0.990| |Freeze Upper Bound | $1.010| |Unfreeze Lower Bound | $0.995| |Unfreeze Upper Bound | $1.005| |Buy GHO Fee | 0%| |Sell GHO Fee | 0.10%| |Gho Reserve Limit | 25M| GhoReserve Deploy GhoReserve on X-Layer to hold bridged GHO initially. Configure stataUSDG RemoteGSM as an entity with a draw capacity of 25M GHO. GHO Steward Configuration GhoAaveSteward updateGhoBorrowCap: ±100% updateGhoBorrowRate: ±5% on optimal usage ratio, base variable rates, slopes updateGhoSupplyCap: Up to +100% GhoGsmSteward updateGsmExposureCap: ±100% updateGsmBuySellFees: ±0.5% per side (FixedFeeStrategy) Both stewards remain callable only by the GHO steward. Budget To bootstrap GHO, funding from Ethereum will be bridged to X Layer via CCIP and used to provide initial liquidity in Aave. Over time it will be withdrawn to support growing GHO's adoption across the broader X Layer ecosystem via Aave and other protocols. Create allowance for ALC, 1M aEthLidoGHO from Aave v3 Prime on Ethereum: Asset: aEthLidoGHO: 0x18eFE565A5373f430e2F809b97De30335B3ad96A Amount: 1M Spender: ALC0xA1c93D2687f7014Aaf588c764E3Ce80aF016229b Method: approve() aEthLidoGHO on the Aave Collector contract to the ALC address Budget for boostrapping liquidity shall be processed separately as part of a general funding update. Disclosure TokenLogic does not receive any payment for this proposal. Next Steps 1. Publish an ARFC to continue gathering community and Service Providers feedback. 2. Escalate proposal to ARFC Snapshot. 3. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via CC0.

Summary This proposal updates the signer set of the GHO Stewards admin role, the operator of the GHO Steward contracts, to a 2-of-3 configuration consisting of LlamaRisk, TokenLogic, and Aave Labs. Motivation Overview The GHO Risk Council operates the GHO Steward contracts (GhoAaveSteward, GhoBucketSteward, GhoGsmSteward, and GhoCcipSteward), which enable timely, bounded parameter adjustments for GHO within limits defined by governance. Over recent months, the Safes managing the DAO’s finances, including the Aave Finance Committee, have converged on a common 2-of-3 signer configuration. Upon implementation, this publication will replace Individual’s signers with Service Provider owned signing addresses. The Gho Risk Council remit is functionally limited to the various Steward Roles as defined in Governance V2 and assigned by tokenholder votes. Please note that, prior to this publication, the legacy Chaos Labs address was transitioned to an Aave Labs address. We extend our sincere thanks to each of the Steward signers, whose responsiveness and diligence have supported GHO's parameter management since the Council's inception. Rationale for the Signer Update Adopting the shared configuration provides: 1. General Updates: updating signer addresses to reflect those actively contributing to the Aave ecosystem. 2. Signer Continuity: Each contributing organization manages its own internal signer roster within its entity Safe, so personnel changes no longer require per committee signer rotations. If a service provider were to leave Aave abruptly, the Steward role can continue to function, preserving confidence in the governance of the GHO ecosystem. 3. Operational efficiency: A 2-of-3 threshold across three highly available service providers preserves the Council's ability to act within the response windows that the Steward contracts assume. The Council Safe address is unchanged. The GHO Steward contracts reference the Safe address, not its signers, so no change to any Steward contract or on chain permission is required. Specification The signer update applies to the GHO Risk Council Safe across each network where the Steward role is active: | Item | Current | Proposed | |----|----|----| | Safe Address | 0x8513e6F37dBc52De87b166980Fa3F50639694B60 | Unchanged | | Threshold | 3 of 4 | 2 of 3 | | Signers | Individual signer addresses | Entity Safes (below) | Proposed signer set: | Entity | Address | |----|----| | Aave Labs | 0x4b752551fC6345A7de82F76fd7a5015CA16d1a74 | | LlamaRisk | 0xb291232F480F41c75802C4a60F1D2AC03404Afef | | TokenLogic | 0x9DE1d45e2786b03498289959203F25b29B4D1193 | The update will be executed as a standard Safe owner management transaction signed by the current Council signers. No Aave governance payload is required as the Council Safe address, and therefore the RISK_COUNCIL reference in each GHO Steward contract, is unchanged. Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If the Snapshot outcome is YAE, the signer update will be executed by the current Council signers. No AIP is required as no on-chain governance action is involved. Copyright Copyright and related rights waived via CC0.

Summary LlamaRisk proposes deprecating Chainlink price feeds for a set of long-tail assets deployed across Aave V2 or V3 reserves, feeds that Chainlink itself has classified as high or very high operational risk as the underlying assets have lost meaningful adoption and liquidity, leaving too little trading activity to price them reliably. The set spans 10 deployments, part of which are already deprecated, with aggregate affected supply of $6.76M and aggregate debt of $4.29M. Previously applied as part of Aave V2 Continued Deprecation Steps, this round of changes expands to some of the Aave V3 deployments, as these assets have already been deprecated for an extended period of time and continue to experience a decline in adoption, which in turn affects the stability of the secondary market price feeds employed by Chainlink. Deprecating troubled or inactive reserves is a standard, well-established part of Aave governance. The same process has been applied to other assets before, including the full deprecation of DPI across Aave deployments and the TUSD offboarding plan, and this proposal follows the same playbook. Motivation The reserves in scope share a common deprecation reason: each underlying asset has either lost meaningful adoption or held its peg only intermittently over a sustained period, and in several cases both. As activity migrated away, secondary market liquidity thinned to the point where the asset's market price is no longer a dependable input for valuing collateral and debt on a lending protocol. Pricing a thinly traded or persistently depegged asset from its live market feed is inherently fragile, because the reported value can drift well away from any defensible fair value and can be moved by a small amount of trading volume. For this reason Chainlink has classified the price feeds behind these reserves as high or very high risk meaning that they should no longer be used to price assets on Aave. Continuing to mark positions against a feed whose underlying market has deteriorated leaves the protocol exposed to stale or manipulable valuations, which on a lending market translate directly into mispriced collateral, unfair liquidations, or debt that is no longer fully backed. These reserves nonetheless still carry live positions on Aave, held as collateral, as debt, or both, so the feeds cannot simply be switched off. Each reserve instead requires an individual remedy: the live oracle is replaced with a fixed-price adapter and paired with a controlled set of parameter changes so the remaining positions can be wound down in an orderly fashion. The approach is tailored on a per-asset basis, where the non-frozen assets are also frozen as part of the oracle deprecation. Aave V3 Reserves & Markets Twenty-one V3 reserves fall under this round of oracle deprecation. Six carry material exposure and are analysed individually below: LUSD and FRAX on both Ethereum Core and Arbitrum, RPL on Ethereum Core, and USDm on Celo. Together they hold $3.50M of supply and $1.47M of debt, and only $13.0K of the supplied balance is enabled as collateral, so the exposure sits almost entirely on the supply and debt sides rather than in collateral risk. The remaining 15 V3 reserves, spread across Arbitrum, Avalanche, Ethereum, Optimism, Polygon, Scroll and the EtherFi instance, hold a further $231.2K of supply and $48.2K of debt and are handled with the simplified treatment described in the Negligible Exposure Reserves section. LUSD on Aave V3 Ethereum Core LUSD is the decentralised, ETH-backed stablecoin issued by the Liquity protocol. On Aave V3 Ethereum Core it carries $2.01M of supply across 127 wallets and $664.7K of debt across 60 wallets. Of that supply, only $12.2K across 15 wallets is enabled as collateral at the current 77% LT. The active feed is a Chainlink LUSD/USD secondary market price feed used in a stable price cap adapter with a $1.10 price cap, currently reporting a price of $1.00. Hardcoding the oracle to a fixed value removes the price manipulation vector for both the LUSD collateral and LUSD debt without materially repricing the position relative to its current accounting value. !LUSD position concentration|2520x1260 Source: LlamaRisk, July 28th, 2026 Position breakdown Supplied only (not borrowed against): 123 wallets, $1.98M of LUSD, including 11 that have LUSD enabled as collateral but carry no debt. Used as collateral backing debt: 4 wallets, $7.4K of LUSD, backing only $160 of borrowing. Borrowed: 60 wallets, $664.6K of LUSD debt. Borrower health Across the 63 wallets that borrow LUSD or post it as collateral, the median HF is 1.81 and the 10th percentile is 1.03. 6 are already below HF 1, 2 more sit in the [1.0, 1.05] band where a 1% adverse move would tip them into liquidation, and 26 sit above HF 2. !LUSD borrower HF distribution|2520x900 Source: LlamaRisk, July 28th, 2026 Co-position patterns The top 10 LUSD borrowers post $11.40M of collateral between them, almost entirely WETH at $8.02M and WBTC at $3.18M, with a small LINK remainder. LUSD is being borrowed against blue-chip collateral, not held as a directional position. !Top LUSD borrowers: portfolio composition and HF|2520x1260 Source: LlamaRisk, July 28th, 2026 Recommendation The reserve is frozen and its supply and borrow caps are reduced to one. The oracle is hardcoded at $1.00. Because slope2 only affects the borrow rate once utilization rises above the optimal point, raising it alone would leave the current 2.1% borrow APR at 33% utilization unchanged. The RF is therefore raised from 20% to 99%, redirecting almost all interest income from suppliers to the treasury. With their yield gone, suppliers are expected to withdraw, which lifts utilization and with it the borrow rate. The IRM base rate is also raised to 5%, a moderate but immediate repayment incentive that applies at every utilization level, and slope2 to 100% so that once utilization does cross the optimal point the borrow rate climbs steeply. As this is the first step of the deprecation, sharper rate increases are deliberately left for a later round. USDm on Aave V3 Celo USDm is the Celo-native dollar stablecoin issued by the Mento protocol. On Aave V3 Celo it carries $503.7K of supply across 545 wallets and $451.7K of debt across 20 wallets. None of the supplied balance is enabled as effective collateral as the asset was never allowed to be used as collateral. The active feed is a Chainlink USDm/USD price feed with the stable cap adapter clamped at the $1.04 reference, while the current oracle price is at $1.00. Hardcoding the oracle to the reference value removes the upward-manipulation vector for the residual debt without affecting current positions. Position concentration Supply side: 545 wallets holding $503.7K, with the top five holding 99%. None of it is enabled as collateral, so the whole balance is supply-only. Debt side: 20 wallets holding $435.9K, with the top five holding 100%. !USDm position concentration|2520x1260 Source: LlamaRisk, July 28th, 2026 Position breakdown Supplied only (not borrowed against): 545 wallets, $503.7K of USDm. Used as collateral backing debt: none. The reserve LT is zero, so no supplied USDm backs borrowing. Borrowed: 20 wallets, $435.9K of USDm debt. Borrower health Across the 20 wallets that borrow USDm, the median HF is 1.13 and the 10th percentile is 1.03. 1 position is already below HF 1. !USDm borrower HF distribution|2520x900 Source: LlamaRisk, July 28th, 2026 Co-position patterns The top 10 USDm borrowers post $806.0K of collateral, effectively all of it USDT. Borrowing one dollar stable against another points to carry or basis trades rather than directional positions. !Top USDm borrowers: portfolio composition and HF|2520x1260 Source: LlamaRisk, July 28th, 2026 Recommendation The reserve is frozen and its supply and borrow caps are reduced to one. The oracle is hardcoded at $1.00. Even at 90% utilization the variable borrow APR is only 4.0%, too low to give borrowers a reason to close their positions. The RF is therefore raised from 15% to 99%, redirecting almost all interest income from suppliers to the treasury. With their yield gone, suppliers are expected to withdraw, which lifts utilization and with it the borrow rate. The IRM base rate is also raised to 5%, a moderate but immediate repayment incentive that applies at every utilization level, and slope2 to 100% so that once utilization crosses the optimal point the borrow rate climbs steeply. As this is the first step of the deprecation, sharper rate increases are deliberately left for a later round. RPL on Aave V3 Ethereum Core RPL is the Rocket Pool governance token. Its market price has fallen substantially over the trailing six months, so the trailing 6 month average sits above current spot. On Aave V3 Ethereum Core it carries $583.6K of supply across 180 wallets and $203.7K of debt across 45 wallets. None of the supplied balance is enabled as collateral, as the reserve's LT is already zero. Noted: Due to character limitations, the remainder of the forum post is available on the Aave Governance forum.

Summary LlamaRisk, together with the Aave service providers working on risk surface reduction, recommends offboarding a broad set of low-activity Aave V3 reserves along with six whole deployments. The following specification lists the current configuration of each reserve and the parameter changes required to wind it down. The individual removals cover 50 reserves and 21 matured Pendle PTs across eleven deployments, holding $85.3M of supply and $11.5M of debt. The whole-market deprecations add 25 reserves across Sonic, Scroll, zkSync, Metis, Soneium and Aptos, holding $12.8M of supply and $4.1M of debt. A large share of the set is already in motion, with borrowing disabled, reserves frozen, or caps already reduced to 1 on most of it. A further set of V3 reserves flagged for Chainlink price feed risk is being offboarded through the companion oracle deprecation ARFC. Those reserves receive a freeze, caps of 1 and a fixed-price oracle there, so they are listed in the cross-reference section below and excluded from the tables and specification of this document. Motivation This recommendation is part of a portfolio-level effort to reduce Aave's risk surface across deployments, applying the Aave Risk Framework rather than reacting to a problem with any single asset. Most reserves in scope are assets whose usage on Aave has remained below, or declined to, the level the framework requires for a standalone listing. Each listed reserve carries a fixed operational load regardless of its size: an oracle to maintain, risk parameters to monitor, and a liquidation path that must function reliably. Where a reserve's activity no longer justifies that load, it is wound down. The scope also includes several structural cases. Bridged tokens such as USDC.e and USDbC are removed where the native version is listed and retained, so the same asset is not carried twice. MaticX is being sunset by its issuer. A group of Pendle Principal Tokens has passed maturity, after which the reserve serves no ongoing function. On six smaller deployments the assessment applies to the whole market rather than individual reserves: aggregate activity has declined to a level where the revenue the deployment generates does not cover the cost of supporting it, so the entire market is wound down at once. Wind-down mechanics Each reserve is wound down so that exposure is removed while users exit in an orderly way and liquidation risk is minimised. The default action on every reserve is to freeze it, reduce its supply and borrow caps to 1 and, on reserves that carry a borrow, raise the RF. The freeze blocks new supply, borrow, and use as fresh collateral. Raising the RF directs more of the borrow interest to the treasury, so suppliers earn less yield and withdraw their assets. As supply leaves, utilisation rises and borrowers are pushed to repay. For assets that are currently used as collateral, freezing the market stops new activity, but the positions already in place can remain open. Any effort to unwind those positions is discussed on a case-by-case basis. The next steps listed per reserve below reflect this default action and the current state of each reserve. Beyond the default action, further levers may be applied depending on how each asset behaves, so they are deliberately not part of the per-reserve next steps: Where borrowers do not repay despite the raised reserve factor, the IRM curves are increased to make carrying a borrow more expensive. When it is deemed risky to keep the exposure, the Liquidation Threshold can be gradually reduced to deleverage the market, applied per asset when that is necessary to remove a lingering collateral position. The whole-market deprecations apply the same approach to every reserve at once: each reserve is frozen with caps reduced to 1 and, where it is borrowed, the RF is raised to 99% and the IRM base rate is set to 5%, matching the initial rate step used in the oracle deprecation ARFC. We will reassess periodically whether further measures, such as raising the IRM further, are needed. Overlap with the oracle deprecation ARFC The reserves of Aave V3 below qualify for this scope on adoption grounds but also carry a Chainlink price feed assessed at elevated risk. They are handled in the oracle deprecation ARFC, which freezes each reserve, reduces its caps to 1 and replaces the live feed with a fixed-price adapter. They are excluded from the specification of this document to avoid double-specifying the same reserves. | Asset | Instance | Feed tier | Supplied | Borrowed | |-------|----------|-----------|---------:|---------:| | LUSD | Ethereum | Very High | $2.0M | $665k | | RPL | Ethereum | High | $608k | $212k | | BAL | Ethereum | Very High | $46k | $3k | | FRAX | Ethereum | Very High | $38k | $29k | | KNC | Ethereum | High | $6k | $1k | | FXS | Ethereum | High | $1k | $17 | | LUSD | Arbitrum | Very High | $192k | $75k | | FRAX | Arbitrum | Very High | $170k | $48k | | MAI | Arbitrum | Very High | $16k | $13 | | MAI | Avalanche | Very High | $21k | $4k | | FRAX | Avalanche | Very High | $7k | $6k | | LUSD | Optimism | Very High | $26k | $18k | | MAI | Optimism | Very High | $9k | $3k | | sUSD | Optimism | Very High | $26k | $12k | | GHST | Polygon | Very High | $31k | $311 | | miMATIC | Polygon | Very High | $9k | $11 | | BAL | Polygon | Very High | $1k | $450 | | STG | Ethereum | Medium | $92 | $2 | USDm on Celo and SCR on Scroll are also covered by the oracle deprecation ARFC. SCR additionally falls under the Scroll whole-market deprecation below, where the deployment-wide parameter changes still apply. Scope by market The first chart sets the in-scope supplied value of each live deployment against that market's total supplied value. On the large general-purpose markets the changes touch a small fraction of overall size. !Share of each live market's supplied value affected|2160x1170 Source: LlamaRisk, July 28th, 2026 The six whole-market deprecations cover their deployments in full and hold $12.8M of supply between them: Sonic $7.6M, Scroll $2.2M, Aptos $1.7M, zkSync $0.8M, Metis $0.3M and Soneium $0.2M. The chart below shows how much each deployment, live and fully deprecated alike, contributes to the roughly $98M of supplied value in scope. !Contribution of each deployment to the supplied value in scope|1980x1170 Source: LlamaRisk, July 28th, 2026 Live markets: individual reserve removals Ethereum Core The Ethereum Core scope is dominated by two BTC liquid-staking wrappers, FBTC and eBTC, which together hold about $16.3M of supply against $63k of borrowing. Both were listed for collateral demand that has not materialised at scale, and their supplied balances have fallen from roughly $38.9M and $33.5M respectively over the past six months as depositors migrated out. CRV and UNI carry the largest remaining borrow balances in scope, with supply roughly halving over the same window, CRV from $4.2M to $2.2M and UNI from $4.1M to $1.7M. The remainder is a long tail of reserves below $250k, most of them already frozen, borrow-disabled or capped to 1, where this proposal formalises a wind-down that is already underway. | Asset | Supplied | Borrowed | RF | State | Borrowable | Collateral | Reason | Next steps | |-------|---------:|---------:|----:|-------|------------|------------|--------|------------| | FBTC | $11.1M | $63k | 50% | Active | No | General + E-Mode | Limited adoption | Freeze reserve, set caps to 1 and raise RF to 75% | | Matured PTs (15) | $86k | $0 | - | Active, supply cap of 1 | No | E-Mode only | Matured | Freeze all and set caps to 1 | | CRV | $2.2M | $238k | 35% | Active | No | General | Limited adoption | Freeze reserve, set caps to 1 and raise RF to 50% | | UNI | $1.7M | $29k | 20% | Active | No | General | Limited adoption | Freeze reserve, set caps to 1 and raise RF to 50% | | crvUSD | $185k | $78k | 20% | Active, supply cap of 1, borrow cap of 1 | Yes | Non-collateral | Limited adoption | Freeze reserve, set caps to 1 and raise RF to 50% | | MKR | $175k | $2k | 20% | Frozen, supply cap of 1, borrow cap of 1 | Yes | General | Limited adoption | Raise RF to 50% | | ETHx | $159k | $650 | 15% | Active, supply cap of 1 | No | General + E-Mode | Limited adoption | Freeze reserve, set caps to 1 and raise RF to 50% | | 1INCH | $154k | $6k | 20% | Active | No | General | Limited adoption | Freeze reserve, set caps to 1 and raise RF to 50% | | ezETH | $111k | $0 | - | Active | No | General + E-Mode | Limited adoption | Freeze reserve and set caps to 1 | | ENS | $72k | $5k | 20% | Active | No | General | Limited adoption | Freeze reserve, set caps to 1 and raise RF to 50% | | SNX | $59k | $13k | 95% | Active, supply cap of 1 | No | General | Limited adoption | Freeze reserve, set caps to 1 and raise RF to 99% | | sDAI | $50k | $0 | - | Active, supply cap of 1 | No | General | Limited adoption | Freeze reserve and set caps to 1 | | eUSDe | $17k | $0 | 45% | Active, supply cap of 1 | No | General + E-Mode | Limited adoption | Freeze reserve and set caps to 1 | Noted: Due to character limitations, the remainder of the forum post is available on the Aave Governance forum.

Summary This publication presents an overview of the Aave DAO’s Governance Process v2 and, upon implementation, replaces the current Governance Process Document v1. v2 consolidates the governance process, presently spread across v1 and several newer frameworks, into a single canonical reference. The mandatory TEMP CHECK stage of the governance process has been removed, and all role, guardian, and steward mandates have been refreshed to reflect the 2026 service provider landscape. Upon implementation, this framework streamlines the current 19-day process to 13 days, while ensuring risk and technical standards are upheld. Motivation Overview Aave's governance has matured into a lean, Service Provider model built for transparency and speed. This publication provides a holistic overview of Aave DAO’s governance processes and frameworks, designed to keep the DAO efficient, nimble, and structured. A focused group of service providers now delivers the core functions: Aave Labs on development and growth; LlamaRisk on risk; Certora on security; and TokenLogic on finance and growth. This document supersedes the Governance Process Document v1 and shall be maintained over time, always reflecting the community's current operational structure. Rationale for retiring TEMP CHECK One of the most significant efficiency improvements to the overall governance process presented here has been the retirement of TEMP CHECK from the standard path. With an emphasis on refining the economics of sequential adjustments in overall market risk, the initial intent to reduce workload on Risk and Technical service providers has been addressed. The process now begins with a business case to determine whether new assets or markets should be deployed. Furthermore, since the Governance Process Document v1 was written, the DAO has adopted structured evaluation frameworks, notably the Aave Risk Framework and the Technical Asset Listing Framework, providing clear public criteria that each proposal must satisfy before it can advance. The ARFC stage provides a public discussion window followed by a binding Snapshot vote, providing the community retains a clear opportunity to shape, support, or reject a proposal without running two sequential sentiment rounds. A notable distinction: the ARFC vote is binding, allowing the Aave DAO to make commitments before deploying technical resources for larger initiatives, such as deploying Aave Protocol instances, entering new markets within an existing instance, or committing to payment upon delivery of work scopes. Governance Process Aave's governance process is structured so that the protocol remains decentralised, secure, and adaptable. The lifecycle of a proposal is carefully designed to allow community members to present ideas, vote on them, and implement approved changes through a transparent, structured process. The processes described below are an overview of the official ways to participate in Aave DAO in various parts of the lifecycle as an AAVE, stkAAVE, or aAAVE delegate. For more details, please refer to the official documentation. Every type of governance action falls into one of three processes, based upon who they are implemented by: Standard Process: The default governance process consists of an ARFC governance proposal, a Snapshot vote and an on-chain vote to implement the upgrade. The Short Executor implements the vast majority of AIP proposals, with the Long Executor reserved for major upgrades. Direct-to-AIP Process: A refined on-chain voting process designed to enable simple parameter adjustments, not otherwise performed by Stewards, to be implemented quickly. Steward Process: This process facilitates high-cadence operational updates implemented by Service Providers within a tightly controlled, limited-access, and bounded environment, allowing the protocol to operate efficiently throughout the market cycle. !image|2000x1006 The gradual introduction of Steward roles allows for a growing portion of routine upgrades to shift from the Direct-to-AIP process to the Steward Process, streamlining the protocol's operational readiness by enabling swift action and reducing administrative overhead. Token holders remain critical to shaping the future of business by retaining key decision-making power and electing to delegate daily operations to trusted actors who operate the Steward roles. Standard Process The standard governance process for the Aave DAO follows the guidelines outlined below: !image|2000x1734 Reference: Aave Governance. Adjust Level 2 requirements (long-executor) Governance Forum - Aave Request for Comment (ARFC) This is where initial discussions take place, and feedback is gathered. Service providers and community members provide detailed feedback over a 4-day period on how the proposal would affect the protocol, helping prepare it for the AIP stage. Snapshot ARFC voting takes place in the Aave Snapshot Space. * Voting: If the proposal meets the required Snapshot threshold, it proceeds to the AIP stage; otherwise, it fails. Authors, proposition power, timing, and thresholds are detailed in the Voting section below. Aave Improvement Proposal (AIP) The AIP stage is where the proposal becomes a formal, on-chain submission. It includes two parts: metadata (stored on IPFS) and the contract payload. These are submitted through Aave's governance contracts, primarily on the Ethereum Mainnet. * Voting: Once on-chain, the AIP is voted on through Aave's governance contracts. The on-chain stages, quorum, and vote differential are described in the Voting section below. * Execution: A successful proposal moves to the execution phase, where it is enacted via Aave's governance infrastructure. Depending on the type of proposal, a timelock delay (either 1 day or 7 days) is imposed before the changes are implemented. Cross-chain proposals are executed using Aave's Delivery Infrastructure (a.DI). Long Executor The Long Executor (Level 2) governs the most sensitive parts of the protocol, those that define governance itself. It controls upgrades to the AAVE, stkAAVE, and aAAVE tokens, changes to the governance contracts and their permissions, and modifications to the executors and timelocks themselves. In short, it covers any change that could affect voting or proposition power. Because these changes carry the highest impact, the Long Executor applies stricter requirements than the Short Executor (Level 1), which handles day-to-day protocol matters such as asset listings, parameter updates, and treasury operations. A Level 2 proposal runs a longer 10-day voting period, requires a higher quorum and vote differential, and passes through a 7-day timelock before execution, compared with the 3-day vote and 1-day timelock of a Level 1 proposal. For the current thresholds and contract addresses, see the Aave governance documentation. !image|2000x864 Direct-to-AIP Process To support timely implementation of protocol upgrades via Token holder vote, the Direct-to-AIP governance process supports a streamlined 2-step process: a forum post followed by an AIP. By removing the Snapshot vote, the Direct-to-AIP process reduces the governance duration by 4 days and the governance burden. This process is intended to expedite minor changes and can only be proposed by active Service Providers. An illustration of the process is shown below: !image|2000x1221 To be eligible for this non-standard Tokenholder voter process, an Active Aave DAO Service Provider must submit a Direct-to-AIP proposal that addresses one of the areas mentioned below: Existing Asset Listing Existing Asset Parameter Update (excl. controlled by Stewards) Existing Rolling Maturity Asset Listing Eg: Pendle PTs Emission Manager updates Funding Updates Whitelist Flashloan Borrowers (remove fee) Technical Maintenance Whitelist addresses to claim rewards Extending SVR Integrations to new instances or assets Creation of new hubs and spokes on Aave V4 with existing assets Risk Parameters not amendable by Steward Role Noted: Due to character limitations, the remainder of the forum post is available on the Aave Governance forum.

Summary This ARFC proposes onboarding PT-AUSD-8OCT2026, the PT for Agora's AUSD to the Aave V3 instance on Monad. Motivation Overview Aave went live on Monad in July 2026 and crossed 300M USD in deposits, with AUSD onboarded as one of the instance's core stablecoin reserves. AUSD is Agora's institutional digital dollar, minted 1:1 against USD and backed by cash, short-dated U.S. Treasury bills and overnight reverse repurchase agreements. The reserve fund is managed by VanEck, with State Street acting as cash custodian and fund administrator, and reserves are independently attested by Grant Thornton. AUSD is currently the largest stablecoin on Monad, and Pendle operates a liquid AUSD market on the chain. Rationale for Onboarding PT-AUSD-8OCT2026 Onboarding this maturity would enable users to use their fixed-yield PT-AUSD positions as collateral within the same Aave market that already supports AUSD, further enhancing the utility and capital efficiency of the stablecoin on Aave's latest deployment. As a short-dated, AUSD-backed asset, PT-AUSD offers a collateral profile that is well aligned with Aave's risk framework, making it a strong candidate for inclusion on Monad. Selected market data at the time of submission: | Metric | Value | |----|----| | Underlying asset | AUSD (Agora) | | Maturity | 8 October 2026 | | Residual maturity at submission | Approximately 85 days | | PT implied APY | Approximately 6.5% | | Pendle market liquidity | Approximately 5.75M USD | | PT total value locked | Approximately 67.5M USD | | 7-day trading volume | Approximately 8.06M USD | The case for onboarding rests on the following points: 1. Incentives from Agora. Agora has committed some incentives towards that Pendle market we can see the current implied rate around 6.5% APR being subsidized with incentives. 2. Underlying already onboarded. AUSD is already a live reserve on the Aave Monad instance, so the market already prices AUSD and the collateral pairing is natural: PT-AUSD supplied as collateral against AUSD or other stablecoin debt within a dedicated E-Mode category. 3. Ecosystem growth. Enabling PT-AUSD as collateral supports stablecoin leverage and borrowing demand on a nascent instance, aligned with the growth objectives set out in the Aave Protocol v3.7 Monad deployment. Specification The following asset would be onboarded to the Aave V3 instance on Monad. | Field | Value | |----|----| | Asset | PT-AUSD-8OCT2026 | | Network | Monad (chainId 143) | | PT token address | 0x9fc74f8ed616b5baf52a170caa97d6d3898602d1 | | Pendle market address | 0x6f99cf00ee7290ae78a072bb6910ef72d1129fe7 | | SY token address | 0xba3d60f5000f472aef947fb8020a3e6319f9a0b7 | | YT token address | 0xeddee9c0b56248d70a9bfdd103f8bd97c35dfd89 | | Underlying asset (AUSD) | 0x00000000efe302beaa2b3e6e1b18d08d69a9012a | | Maturity | 8 October 2026 | Oracle Price Feed Recommendation For pricing PT-AUSD-8OCT2026 on Aave, the dynamic linear discount rate oracle is recommended. The same oracle template currently in use for Pendle PT assets on Aave V3, can be reused for this deployment. The oracle prices the PT as a zero-coupon bond against a capped underlying Chainlink reference (AUSD/USD fixed at 1 USD), applying a linear discount that decays to par at maturity. The discount rate is bounded above by the maxDiscountRatePerYear parameter, providing a deterministic price floor against adverse market dislocations. Discount Rate Parameters | Parameter | PT-AUSD-8OCT2026 | |----|----| | initialDiscountRatePerYear | To be provided by Risk Service Providers | | maxDiscountRatePerYear | To be provided by Risk Service Providers | Risk Parameters Per Aave's asset onboarding framework, all risk parameters for PT-AUSD-8OCT2026 will be provided by the Risk Service Provider, LlamaRisk and appended to this proposal prior to escalation to the Snapshot stage. An indicative market structure is shown below: | Parameter | Value | |----|----| | Asset | PT-AUSD-8OCT2026 | | Borrowable | No | | Collateral Enabled | No | | Supply Cap | 20,000,000 | | Borrow Cap | - | | Debt Ceiling | - | | LTV | - | | LT | - | | Liquidation Penalty | 10.00% | | Liquidation Protocol Fee | - | | E-Mode Category | PT Agora Stablecoins | eMode #5 - PT Agora Stablecoins | Parameter | Value | Value | Value | Value | Value | |----|----|----|----|----| | Asset | PT-AUSD-8OCT2026 | USDT0 | USDC | GHO | USDe | | Collateral | Yes | No | No | No | No | | Borrowable | No | Yes | Yes | Yes | Yes | | Max LTV | 93.00% | - | - | - | - | | Liquidation Threshold | 95.00% | - | - | - | - | | Liquidation Bonus | 2.44% | - | - | - | - | Linear Discount Rate Oracle | Parameter | Value | |-----------|-------| | initialDiscountRatePerYear | 6.661% | | maxDiscountRatePerYear | 8.829% | Given the current on-chain liquidity of the PT-AUSD market on Monad (approximately 5.75M USD), a conservative initial supply cap and a collateral configuration consistent with the treatment of comparable short-dated Pendle PT stablecoin assets on other Aave instances is anticipated. Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100086 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

Author: Ether.Fi Date: 2026-07-14 ARFC discussion: governance.aave.com thread Temp Check discussion: governance.aave.com thread Temp Check Snapshot (passed): Snapshot vote Summary Following the successful TEMP CHECK Snapshot, this ARFC formalizes the deployment of a dedicated, EtherFi-operated Aave V4 hub on OP Mainnet to serve as the credit backend for EtherFi Cash, the Visa card product used by tens of thousands of cardholders. The instance replaces the bespoke borrow/lend market ("Debt Manager") that powers Cash today. The instance is isolated and borrow-whitelisted: borrowing is restricted exclusively to EtherFi Cash users. EtherFi operates it end to end — configuration, risk parameters, liquidity, and growth — while Aave provides the V4 deployment and operating license (2-year initial term) and earns a share of the revenue the instance generates. Because the instance is ring-fenced and EtherFi-run, Aave carries the upside without taking on the market's day-to-day risk. Key Terms Revenue share: 80-20 EtherFi / Aave on the totality of instance protocol revenue (Liquidity Fee, liquidation fees, SVR and other fee streams), settled automatically on-chain. Projected ~$1.0-1.2M/year to the Aave DAO at end-2026 target scale (~$500M instance assets). GHO integration: GHO listed as supply and borrow reserve once deployed on OP Mainnet; Aave deploys a GHO GSM on Optimism; GHO may become a spend asset in Cash at the DAO's discretion. Assets at launch: up to $175M brought by EtherFi. Launch capitalization: $20M supplied by the Optimism Foundation Treasury; $1.2M joint incentive package; $5M strategic GHO position via the GSM (6 months). Exclusivity: EtherFi Cash will exclusively use Aave V4 as its DeFi lending protocol. Operating model: EtherFi as operator; Nonce Capital as independent risk admin (listings, oracles, risk parameters, IRMs, caps, pause states); Aave Labs provides deployment, license, and GSM; Aave DAO ratifies and receives the revenue share. Full specification — architecture (single Liquidity Hub + Cash Spoke on OP Mainnet), the 20-asset launch collateral set, reference risk parameters, oracles, liquidations, and the phased Debt Manager migration (~$25M active borrows) — is detailed in the ARFC post. Next Steps If the outcome of this ARFC Snapshot is YAE, publish an AIP vote for final confirmation and enforcement of the proposal, targeting a July 2026 deployment to meet the Cash product handoff from the current Debt Manager. Disclaimer This proposal is submitted by EtherFi as the operator of EtherFi Cash and the proposer of the instance. All terms and parameters are subject to this governance process and service-provider review. EtherFi is not compensated by any third party for submitting this proposal. Copyright Copyright and related rights waived via CC0.

[Temp Check] Deploy Aave V4 on Tempo Author: Tempo Date: 2026-07-23 Summary This Temp Check seeks community feedback on deploying Aave v4 on Tempo Mainnet. Tempo is a new purpose-built Layer 1 blockchain for payments, developed in partnership with leading fintechs and Fortune 500s like DoorDash, Deel, Shopify, Moneygram and more. Incubated by Stripe and Paradigm, Tempo is designed for stablecoin use cases including cross-border payments, remittances, embedded finance, payroll, and treasury management that bring real business value to companies adopting blockchain technology. Launching Aave v4 on Tempo would position Aave as a key infrastructure partner for Tempo and the enterprises building on Tempo. Motivation Tempo launched on mainnet in March 2026. Since then, the Tempo team has been building yield and credit products with enterprise partners. With regulatory clarity emerging around stablecoins and crypto, traditional companies are increasingly positioned to build onchain using DeFi infrastructure. Tempo is excited to partner with the Aave ecosystem on bringing these use cases to life. Deploying Aave v4 on Tempo will: Expand Aave's liquidity footprint to include traditional enterprises and fintechs Develop new markets by listing bespoke real-world assets exclusive to Tempo Grow GHO by powering B2B credit use cases on Tempo Drive new revenue opportunities that will accrue value back to the Aave DAO and $AAVE token holders For the first year after Aave v4 launches on Tempo, the Tempo team will incentivize pathUSD deposited on Aave at around SOFR rate. This will establish a sustainable baseline incentive APY for the pathUSD supply market. pathUSD is a native stablecoin on Tempo issued by Bridge. Specification If governance supports this Temp Check, the next phase will be an ARFC for deploying Aave v4 on Tempo. The ARFC would include the proposed initial supported tokens, oracle configuration, risk framework, deployment contracts, incentive strategy, and parameter recommendations from relevant Aave DAO service providers. Useful Links Website: https://tempo.xyz/ Customer stories: https://tempo.xyz/customer-stories/ Developer docs: https://tempo.xyz/developers/docs Next Steps 1. If the Temp Check Snapshot outcome is YAE, publish an ARFC covering the initial supported tokens, oracle configuration, risk framework, deployment contracts, incentive strategy, and parameter recommendations from relevant Aave DAO service providers. 2. After the ARFC discussion and a successful ARFC Snapshot, submit an AIP for an onchain vote to deploy Aave v4 on Tempo. Copyright Copyright and related rights waived via CC0. *

[ARFC] Aave App Launch Author: Aave Labs Date: 2026-07-21 1. Aave for Everyone Aave App is designed to meet the usability bar of leading fintech apps: the Fintech Test. It gives anyone, anywhere, a self-custodial way to access Aave Protocol's lending infrastructure through an interface as simple as the apps they already use. Aave App allows anyone with a smartphone to use Aave's institutional-grade lending infrastructure without setting up a digital asset wallet, managing gas, or understanding the complexities of DeFi. Users transfer fiat from their bank account via Aave Push's regulated fiat-conversion rails and earn yield generated by Aave Protocol's lending markets, with all net revenue directed to the DAO treasury. Aave Labs provides the user interface and the self-custodial infrastructure behind it, through Aave Accounts and ERC-6900 smart accounts. At launch, the Aave App will introduce four new innovations (Stable Vaults, Balance Protection, Aave App Accounts and Aave Push), with more product additions arriving through 2026 to increase revenue, lower costs, and expand the App's user base. This proposal asks the DAO to approve the following: The initial vault allocation configuration for the Aave App, as specified in Section 5 The RPUR (Revenue Parameter Update Request) framework described in Section 7, under which the DAO may propose changes to Aave App's core revenue parameters A launch campaign for the Aave App, as detailed in Section 8 The use of the entire Milestone 1 funding from the Aave Will Win proposal to fund the first-loss tranche of the Balance Protection captive structure The addition of Stable Vaults to the scope of the Aave App Stack bug bounty program, as described in the Aave Protocol Bug Bounty Programs Restructure ARFC and specified in Section 5 2. User & Balance Projections Aave App's iOS waitlist comprises approximately 50,000 registered users, each of whom completed a multi-step onboarding process: app download, account setup, and profile completion with a subset of users also completing applicable KYC screening (only available to US users while on the waitlist). This required multi-step process filters for higher intent users relative to those present in email-only waitlists. The Android version of the Aave App is expected to be released in Q3 2026, expanding the non-US user base. By the end of the Aave App's first 12 months, we estimate three scenarios for combined iOS and Android success metrics by varying three assumptions together for each case: conversion rate from waitlist to funded user (a user who has made an initial deposit), average balance per funded user, and month over month user growth: !Projections The above metrics are purely indicative, based on current waitlist numbers, assumed conversion rates, and projected month-over-month growth, and should not be taken as a guarantee of future performance. 3. Revenue Opportunities Aave App is projected to generate over $15M in annual revenue by the end of year two (indicative), across the four revenue streams outlined below, with additional streams under evaluation. Stream 1 (yield spread fees) and Stream 2 (reserve factor attribution) are expected to be active at launch. Streams 3 and 4 (card fees, swaps and FX), are expected to phase in throughout 2026, pending product availability and regulatory clearance. The $15M figure includes illustrative contributions from Streams 3 and 4; as these products have not yet been built or cleared for launch, their revenue contribution should not be treated as a projection the DAO is asked to rely on. Yield Spread This fee is derived from the spread between the yield earned by the assets deployed in the vault and the yield payable to users. !Yield Spread For example, total user deposits of $1B with a 0.2% yield spread could result in $2M in annual revenue within 24 months. Reserve Factor Attribution Because the Aave App uses Aave Protocol for earning on the vault's balances, an increase in deposits via the app results in an increase in deposits into the protocol markets. Assuming unchanged protocol utilization rates and reserve factor, an increase in user balances would increase the reserve factor revenue for the DAO. !Reserve Factor Attribution Within 24 months, deposits of $1B flowing into Aave Protocol via the Aave App could generate approximately $4.5M in annual reserve factor revenue accruing to the DAO treasury at a 6% borrow rate, calculated as: $1B × 75% utilization × 6% borrow rate × 10% reserve factor = $4.5M The above calculation is a projection that assumes stable protocol utilization, borrow rates, and reserve factor allocation. The actual figure depends on protocol-wide activity, the stability of the above noted factors, and DAO governance. Card Fees Card fees (including interchange, FX, network incentives, signing bonuses, etc) are expected to be a major revenue driver. The Aave App is expected to enable worldwide card issuance, letting users spend directly from their vault balances. This creates a high-margin, transaction-based revenue stream opportunity that can scale independently of yield or user balances. The table below includes projections assuming a 1.0% blended card fee. Savings-first users tend to have higher card spend because their vault balance functions as a spending account, similar to debit card behavior at neobanks. Card adoption rates are benchmarked against major fintechs. !Card Fees If Aave Cards launch, the calculation above illustrates how card revenue could scale with adoption; it is not a revenue target and is not part of what this proposal asks the DAO to approve. Swap Fees Future additions to the Aave App could include volume-based fees on swaps between assets. Example use cases could include: Non-Stablecoin Deposits: Users that want to exit a crypto asset position and enter into stablecoins that pay a yield before they make their next move. Foreign Exchange Swaps: With the introduction of savings in additional fiat currencies as well as the ability to spend the Aave App balance internationally with the upcoming card, Aave App would be able to charge FX swap fees. The chart below is illustrative only. Swap fees depend on both the FX swap capability and the card product described above, neither of which currently exists, and the figures shown should not be treated as a projection the DAO is asked to rely on: !Swap Fees 4. The Four Aave App Innovations At launch, Aave App will introduce four breakthrough innovations, each one necessary to pass the Fintech Test. Stable Vault Stable Vault is a vault tailor-made for retail consumer savings and provides a step-function improvement for stablecoin-powered savings applications. While being a DeFi innovation, it mirrors the user experience of traditional savings accounts while allowing for maximum cost and liquidity scalability. The core features that make this possible are: Per-user stable rate: Stable Vault depositors' assets are placed in a yield bucket (for example, earning 5%, with the rates being influenced by underlying variable DeFi markets) from the vault's allocation rather than guaranteed by any actor. This innovation allows for a smoother, more predictable yield experience. Certain users may be eligible to obtain yield boosts by completing in-app activities such as inviting friends or setting up automated deposits. Multi-strategy connectivity: Stable Vault is able to earn by supplying liquidity to protocols with any ERC-4626 compatible strategy, meaning Aave App can earn with Aave V3, V4 and sGHO. Multi-chain earning: Stable Vault is able to earn on any supported chain, enabling for the accounting (processing of deposits & withdrawals) to happen on a gas-efficient chain, while accessing the deepest pools of liquidity on Ethereum and capturing incentives on select other chains. Multi-stablecoin deposits: Stable Vault allows deposits & withdrawals in any number of whitelisted stablecoins, further allowing Aave App to abstract away individual stablecoin balances behind a reported dollar value. Stablecoins inside of the Stable Vault are rebalanced toward the target allocation automatically and uniformly across pooled balances, without discretionary per-user management. Stable Vault's multi-chain IOU bridging functionality is guarded by an M-of-N bridge quorum. Rate limits are enforced on asset bridging globally and per lane (a route per asset, bridge provider and chain) to mitigate risk of bridge compromises or down time. Stable Vaults have been audited by Certora, Chain Security, Josselin, Stermi, and Recon. You can find the code and more information in the Stable Vault GitHub repository. Stable Vaults will be available to fintechs and partners as part of Aave Kit. !Stable Vault Due to the Snapshot character limit, the remainder of this proposal can be viewed on the Aave Governance forum.

Summary We propose the onboarding of USDai and sUSDai on Aave V3 Arbitrum Instance. This listing would initially enable users to deposit USDai and sUSDai to earn yield and borrow. 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: Hardware-backed design: Both tokens leverage GPU/AI compute hardware as collateral, creating a new RWA category. 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. Growing ecosystem: 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 | Parameter | sUSDai | USDai | |----|----|----| | Borrowable | No | No | | Collateral enabled | No | No | | Supply Cap | 55,000,000 | 55,000,000 | | Borrow Cap | \- | 45,000,000 | | LTV | \- | \- | | LT | \- | \- | | Liquidation Bonus | \- | \- | | Liquidation Protocol Fee | 10% | 10% | | Variable Base | \- | 1% | | Variable Slope1 | \- | 3% | | Variable Slope2 | \- | 50% | | Uoptimal | \- | 80% | | Reserve Factor | \- | 20% | | Flashloanable | No | Yes | | E-Modes | sUSDai/USDai, sUSDai Stablecoins | sUSDai/USDai | sUSDai/USDai E-Mode | Parameter | Value | |----|----| | Isolated | True | | LTV | 89% | | Liquidation Threshold | 91% | | Liquidation Bonus | 4% | | Asset | sUSDai | USDai | |----|----|----| | Collateral | Yes | No | | Borrowable | No | Yes | sUSDai Stablecoins E-Mode | Parameter | Value | |----|----| | Isolated | True | | LTV | 88% | | Liquidation Threshold | 90% | | Liquidation Bonus | 1% | | Asset | sUSDai | USDT0 | USDC | |----|----|----|----| | Collateral | Yes | No | No | | Borrowable | No | Yes | Yes | CAPO LlamaRisk recommends setting the max yearly growth to 16%, with a 14-day snapshot Next Steps 1. If the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Disclaimer Aave Labs is not receiving compensation from Ava Labs for this proposal or the potential deployment of Aave V4 on Avalanche. Aave Labs is presenting this proposal as a service provider to the Aave DAO as part of its approved scope of work in support of DAO operations. Copyright Copyright and related rights waived via CC0. *

Summary This proposal seeks to onboard syrupUSDC — a USDC-based yield-bearing token issued by Maple Finance — as a collateral asset on Aave V3 Core Instance. syrupUSDC is built on top of Maple’s infrastructure and offers access to overcollateralized, fixed-rate institutional loans, providing high and consistent yields to DeFi users. Maple, launched in 2021, is an on-chain Asset Manager with decades of traditional finance and crypto experience. Motivation Onboarding syrupUSDC to Aave V3 Core Instance provides: New Token Type: A new collateral option backed by real yield from fixed-rate institutional lending strategies AAVE TVL: Maple has a large network of institutional capital allocators, ready to allocate $500M+ USDC/USDT into syrupUSDC if it is available on Aave as collateral to loop it and get to their hurdle rates. Higher Rates and Utilization: Increases USDC rates and utilization due to strong expected borrower demand. Growth Incentives: Maple has $250k of incentives available to bootstrap the growth for Aave users. The Aave and Maple partnership will enable: New Yield Opportunities: Commercial alignment with Maple’s large institutional network, unlocking additional yield generation opportunities for Aave. GHO Adoption: Maple can help with growing other strategic priorities for Aave, including GHO adoption. Eg GHO lending to institutions. Future Collaboration: Future asset listings, including the Maple liquid yielding Bitcoin asset. Specification | Parameter | Recommendation | |----|----| | Borrowable | No | | Collateral Enabled | No | | Supply Cap | 50,000,000 | | Borrow Cap | \- | | LTV | \- | | LT | \- | | Liquidation Bonus | \- | | Liquidation Protocol Fee | 10% | | Reserve Factor | \- | | Base Variable Borrow Rate | \- | | Variable Slope 1 | \- | | Variable Slope 2 | \- | | Uoptimal | \- | | E-Modes | Stablecoin E-Mode | Stablecoin E-Mode | Parameter | Value | |----|----| | Isolated | False | | LTV | 90.00% | | LT | 92.00% | | Liquidation Bonus | 4.00% | | Asset | syrupUSDC | USDC | GHO | |----|----|----|----| | Collateral | Yes | No | No | | Borrowable | No | Yes | Yes | CAPO LlamaRisk recommends setting the Snapshot Delay to 7 days and the maxYearlyGrowthRatio to 8.05%. Next Steps 1. If the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Disclaimer Aave Labs is not receiving compensation from Ava Labs for this proposal or the potential deployment of Aave V4 on Avalanche. Aave Labs is presenting this proposal as a service provider to the Aave DAO as part of its approved scope of work in support of DAO operations. Copyright Copyright and related rights waived via CC0. *

[ARFC] Technical Asset Listing Framework Author: Aave Labs Date: 2026-07-08 !Screenshot 2026-07-09 at 08.20.09.png Summary Aave Labs proposes adopting a standardized Technical Asset Listing Framework for assets seeking listing, continued listing, or material parameter expansion on Aave V3, Aave V4 and Horizon. The objective is to improve the existing asset listing and monitoring process by making the technical requirements for assets listed on Aave more consistent, transparent, and repeatable across governance proposals, while establishing an ongoing monitoring baseline to ensure listed assets continue to meet the protocol's quality and safety standards over time. The framework is designed to complement existing risk-provider methodologies and the Aave Asset Classification Framework by defining a public baseline for technical safety. The framework defines the technical information and requirements expected from asset issuers and review contributors. Formal technical assessment reports may include qualitative ratings or findings summaries for use by risk providers and governance contributors, but this ARFC does not prescribe rating reference values or define exhaustive blocker conditions. Motivation Aave's asset listing process has matured significantly over time, with deeper participation from risk providers, technical contributors, and governance stakeholders. As the protocol expands across more markets, asset types, and deployment environments, the technical requirements for listed assets need to remain clear enough for governance participants to evaluate proposals while being rigorous enough to capture the full asset risk surface. Relevant requirements include ERC20 compatibility, predictable transfer behavior, bounded minting, robust privileged-role controls, reliable oracle paths, safe bridge topology, audited codebase, and appropriate disclosure of offchain arrangements or components where relevant information is not available onchain. These issues are often technical, but they have direct implications for Aave's solvency, liquidations, collateral configuration, oracle design, and emergency response. A token with unbounded minting, weak upgrade controls, a stale or unsuitable oracle, bridge supply mismatch risk, an unclear redemption path, or limited transparency due to offchain arrangements can create exposure that is not visible from standard market metrics alone. This ARFC proposes building on the existing process by making technical asset requirements explicit and standardized, so that future asset proposals can be evaluated against the same baseline and so that governance can clearly identify which assets satisfy the standard, which require mitigation, and which require further review or remediation. Scope The framework applies to: New asset listings on any instance of Aave V3, Aave V4 and Horizon. Existing listed assets undergoing material changes. Existing listed assets subject to periodic or out-of-cycle technical refresh. The framework is intended to be deployment-aware. Where an asset exists across multiple chains, the asset is expected to satisfy the applicable requirements on each relevant chain, including per-chain contract implementations, oracle paths, bridge topology, access-control structure, and dependency configuration. The framework does not replace market-risk analysis, liquidity analysis, legal review, or governance discretion. It provides a technical eligibility baseline to be used alongside the work of the DAO's risk providers and other relevant service providers. Ultimately, onboarding and parameter decisions remain with the DAO, based on the full set of available information, diligence, and recommendations presented through governance. (Liquidity and market-depth analysis is expected to be provided by the DAO's risk providers as part of their standard market-risk assessment, and findings from that process should be read alongside this framework's technical conclusions when governance evaluates supply caps, borrow caps, and collateralization parameters.) Relationship with AAcA Each asset should first be mapped to the relevant group under the Aave Asset Classification Framework. At the pre-screening stage, the asset's AAcA category is expected to be confirmed, and assets in a non-approved or sanctioned category should not proceed. The AAcA classification determines which requirements require the deepest focus. For example, yield-bearing assets are expected to satisfy dedicated exchange-rate, withdrawal-path, and CAPO requirements, while bridged assets are expected to satisfy dedicated bridge and supply-integrity requirements. Evaluation Methodology This framework defines the technical requirements expected from assets seeking listing, continued listing, or material expansion on Aave. It is not intended to publish fixed rating reference values or a complete list of automatic rejection conditions. When Aave Labs or another contributor prepares a formal technical assessment report, that report may include section-level qualitative ratings, risk labels, or other assessment outputs. Those labels should be treated as report-specific conclusions based on the asset reviewed, the relevant deployment, the available issuer disclosures, and the surrounding market and protocol context. The review should separate factual findings from recommendations. For each section, the reviewer should identify: the relevant contracts and systems reviewed; the key finding; any required remediation; any residual risk that remains after mitigation; whether the finding should constrain listing parameters or exposure caps; a qualitative rating and assessment conclusion. The absence of explicit rating thresholds in this ARFC should not be interpreted as acceptance of every implementation that technically satisfies the information request. Material weaknesses may still lead to reduced exposure, additional monitoring, delayed onboarding, or a recommendation not to proceed until remediation is complete. Pre-Screening Requirements Before a full technical review proceeds, the asset should satisfy the following pre-screening requirements: The asset contract must be deployed and verified on the target chain. The asset's AAcA group must be confirmed. The asset must not belong to an AAcA non-approved or sanctioned category. Existing Aave listings, if any, must be identified and used as parameter references where relevant. The closest comparable asset already listed on Aave must be identified. Proxy and implementation bytecode must match, or be reconciled against, the latest audited version where applicable. If a comparable asset exists, it should be used as the initial reference point for oracle design, LTV, liquidation threshold, caps, and other collateralization parameters, subject to the new asset's own technical profile. Standard Findings Report Where a formal technical assessment report is prepared, it should use a standardized structure so that findings are comparable across assets and deployments. The assessment may include a rating, severity label, recommendation, or other report-specific conclusion. This ARFC does not define the reference values for that assessment. Where a section does not apply, the reviewer should explain why. Framework Sections The sections below describe the core technical areas that should generally be covered when evaluating assets for listing, continued listing, or material expansion on Aave. They are not intended to be an exhaustive or final list of requirements. Additional requirements may apply depending on the asset type, implementation design, deployment environment, issuer operations, external dependencies, or new risk considerations identified through governance and service-provider review. For assets with material offchain components, including tokenized real-world assets, custodied instruments, and assets whose redemption or collateralization depends on legal arrangements rather than onchain mechanics, the requirements in this framework apply to the onchain layer. Offchain arrangements that bear on supply integrity, redemption reliability, or counterparty risk should be disclosed and assessed under Section 8 (Dependencies and Composability) and the Issuer Expectations section. Where an offchain component is a critical dependency, it should be treated with the same scrutiny as an onchain dependency. 1. ERC20 Compliance Assets listed on Aave are expected to behave predictably under ERC20 integration assumptions and broader DeFi composability standards. Technical requirements: name(), symbol(), decimals(), and totalSupply() must return sensible values. transfer() and transferFrom() must return a boolean. The asset must not have fee-on-transfer behavior. The asset must not rebase, unless a non-rebasing wrapper is used instead. The asset must not use ERC777 hooks or ERC1363 transfer callbacks. Any flash-mint capability must be documented and shown not to impair Aave accounting. Smart contracts must be able to hold and transfer the token without whitelist or address restrictions. Token decimals must be compatible with Aave integrations and frontend assumptions. Fee-on-transfer behavior, rebasing behavior without a suitable wrapper, ERC777 hooks, or unsupported decimals that cannot be safely integrated should generally require remediation or a modified listing approach before the asset is considered under the framework. 2. Oracle Aave requires a robust oracle path for each listed asset. The oracle path is a core safety dependency, and any feed design that does not use Chainlink as the primary source must be explicitly justified. Due to the Snapshot character limit, the remainder of this proposal can be viewed on the Aave Governance forum.

[TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash Author: Ether.Fi Date: 2026-07-07 Summary EtherFi requests that a dedicated, EtherFi operated Aave V4 hub on OP Mainnet is deployed to serve as the credit backend for EtherFi Cash, our Visa card product used by tens of thousands of cardholders. This instance would replace the bespoke borrow/lend market (“Debt Manager”) that powers Cash today. The instance is isolated and whitelisted: EtherFi operates it end to end - configuration, risk parameters, liquidity, and growth, while Aave provides the V4 deployment and operating license and earns a share of the revenue it generates. Because the instance is ring-fenced and EtherFi run, Aave carries the upside without taking on the market’s day-to-day risk. The proposal arrives with a substantial commercial package contributed by EtherFi and the Optimism Foundation, summarized in the Commercial Terms section, including a 20% revenue share to the Aave DAO, GHO integration into EtherFi Cash, an Aave-deployed GHO GSM on OP Mainnet, full migration of the EtherFi Debt Manager, up to $175M in assets at launch, and product exclusivity to Aave V4. Motivation EtherFi Cash today. Cash lets cardholders spend against yield-bearing collateral at the point of sale: they borrow a stablecoin to settle a Visa transaction while preserving their underlying asset exposure. It runs in production on OP Mainnet on a custom, non-pooled borrow/lend market with roughly $25M in active borrows across 16+ collateral assets and a high-frequency, low-ticket, well-distributed borrow profile. We are targeting roughly $500M in assets on the instance by the end of 2026. Why migrate to Aave V4. Maintaining a bespoke lending engine is increasingly operationally taxing. Migrating to a dedicated Aave V4 instance lets EtherFi inherit audited, battle-tested infrastructure and governance machinery while preserving the Cash product surface (User Safes, Credit/Debit modes, settlement) above it. Why this is a fit for Aave. Pure-upside revenue. Aave shares in the borrow revenue of a live consumer product without committing pool liquidity or balance sheet to it. At our end-2026 target scale, the instance is projected to generate an estimated $5-6M in annual revenue, 20% of which accrues directly to the Aave DAO and compounds as the Cash book grows. Direct GHO adoption. GHO becomes a supply/borrow reserve on the instance as soon as GHO is deployed on Optimism, with an Aave-deployed GSM strengthening GHO’s peg and liquidity on OP Mainnet. GHO as a spend currency. Beyond being a listed reserve, GHO could, at the Aave DAO discretion, be enabled as a deposit/spend asset in Cash, subject to sufficient GHO liquidity to support the Cash program as expected, turning card volume into organic GHO demand. Real-world spend footprint. Aave extends into consumer card settlement, anchored by a product with tens of thousands of active cardholders. Net new on-chain activity on OP Mainnet, with exclusivity to Aave V4 for the Cash product. Aave Labs has expressed support for deploying the instance and providing the operating license. This Temp Check initiates the governance process to ratify that direction and to confirm community sentiment ahead of an ARFC. Specification This Temp Check is intentionally high-level; detailed parameters and the technical specification will be finalized at the ARFC stage with service-provider input. Architecture. A dedicated Aave V4 hub on OP Mainnet. One of V4’s first Layer 2 targets, with spokes depending on the final lending architecture. The instance is whitelisted and isolated from Aave’s shared liquidity and other markets. EtherFi operates the instance end to end and is responsible for collateral listing, risk parameters, oracles, and ongoing risk management. Aave provides the V4 codebase under license for 2 years initial term, but is not responsible for its assets, configuration, or risk. Operating model. EtherFi acts as operator and will authorize an independent risk admin for the instance, with authority over: Collateral listing and de-listing Oracle selection (Chainlink, RedStone, or otherwise) and configuration LTV, liquidation threshold, and liquidation bonus per asset Interest rate models, supporting both utilization-curve and fixed-rate reserves Supply and borrow caps, and pause states EtherFi and the independent risk admin will handle, as appropriate, items such as configuration, liquidity sourcing, and market growth in full. Aave’s role. Aave Labs supports EtherFi in the deployment of the V4 instance on OP Mainnet and provides the license to run the whitelisted version, and deploys a GHO GSM on OP Mainnet to support GHO stability and peg. Collateral at launch. Mirror the existing Cash collateral set, with streamlined additions over time via the admin role: ETH-likes:* weETH, wETH BTC-likes:* eBTC Stables:* USDC, USDT, EURC, frxUSD, GHO EtherFi platform, Optimism & HYPE:* ETHFI / sETHFI, eUSD, OP, beHYPE, wHYPE Liquid vault receipts:* LiquidETH, LiquidBTC, LiquidUSD, LiquidReserve Borrow reserves. USDC and GHO, added as both a supply and a borrowable asset. Liquidations. Aave V4’s standard partial liquidation behavior; EtherFi adapts its liquidator tooling to the V4 flow. Commercial Terms The following package has been aligned in principle between EtherFi, the Optimism Foundation, and Aave Labs to strengthen the instance at launch. Final mechanics are subject to this governance process and service-provider review. Revenue share to Aave DAO: 80–20 EtherFi / Aave on instance reserve-factor revenue. 20% to the Aave treasury, settled automatically. This split reflects the long-standing, proven relationship between EtherFi and Aave, together with Aave V4 serving as the sole lending and borrowing market for EtherFi Cash. GHO integration: GHO supported on the instance as both a supply and a borrowable reserve once GHO is deployed on OP Mainnet. Aave deploys a GHO GSM on Optimism. GHO as a spend currency: at the Aave DAO’s discretion and conditional on sufficient GHO liquidity for the Cash program, GHO may also be added as a spendable/deposit asset within Cash itself, converting a portion of card usage into direct GHO demand. Assets at launch: EtherFi brings up to $175M in assets to the instance at launch, with a clear path to grow significantly from there. Exclusivity: EtherFi Cash will exclusively use Aave V4 lending markets as DeFi Lending Protocol. Launch capitalization (EtherFi & Optimism Foundation funded): * $20M supplied from the Optimism Foundation Treasury into the instance. * $1.2M joint incentive package, directed toward deposits and/or borrows across any asset. * $5M strategic GHO position, taken via the GHO GSM, shared by the Optimism Foundation and EtherFi, held for 6 months, after which continuation is at each party’s discretion. Taken together, Aave contributes the deployment, license, and GHO infrastructure; EtherFi and the Optimism Foundation contribute the launch capital, incentives, asset base and ongoing operation, with revenue flowing back to the Aave DAO. Disclaimer This proposal is submitted by EtherFi as the operator of EtherFi Cash and the proposer of the instance. The commercial terms reflect agreements in principle with Aave Labs and Optimism Foundation; all terms and parameters are subject to this governance process, ARFC refinement, and service-provider review. EtherFi is not compensated by any third party for submitting this proposal. Next Steps 1. On a successful Snapshot, proceed to an ARFC with finalized parameters and risk/finance service-provider input, targeting a July 2026 deployment to meet the Cash product handoff from the current Debt Manager. Copyright Copyright and related rights waived via CC0. *

[ARFC] Deploy Aave V4 on Avalanche Author: Aave Labs Date: 2026-07-06 Summary This ARFC proposes deploying Aave Protocol V4 on Avalanche Network. Motivation Aave V4's next growth phase involves expanding into networks with existing DeFi demand, active Aave usage, and a credible path to protocol revenue. The initial deployment on Ethereum Mainnet validated the Hub and Spoke model in a production environment, making this expansion the logical next step for V4. Aave Labs proposes deploying Aave V4 on Avalanche, beginning with one Liquidity Hub and three Spokes. A dedicated real-world asset (RWA) hub will be launched in a later phase. Avalanche has been a supported Aave V3 deployment since 2022, accumulating over five years of production operation. Its track record across liquidations, oracle performance, and market stress events within the Aave ecosystem establishes Avalanche as a proven network for Aave deployments. The existing market brings established distribution, active liquidity, and a mature user base, materially reducing execution risk for the activation of Aave V4 on Avalanche. Following the passing of the TEMP CHECK Snapshot, this ARFC sets out the proposed launch topology, asset scope, oracle configuration, incentive structure, and rollout path. Incentives Package The Avalanche Foundation has committed up to $15,000,000 in milestone-based incentives tied to Hub launches and growth KPIs to bootstrap the V4 markets. Specification Hub and Spoke Configuration The proposed initial Avalanche deployment will activate one Liquidity Hub and three Spokes; a Main Spoke, an AVAX Correlated Spoke, and a Forex Spoke. | Hub | Assets | |:---|:---| | Avalanche Core Hub | wAVAX, sAVAX, BTC.b, USDC, USDT, wETH.e, EURC | | Spoke | Collateral | Borrowable | |:---|:---|:---| | Main Spoke | WAVAX, BTC.b, USDC, USDT, wETH.e, EURC | WAVAX, BTC.b, USDC, USDT, wETH.e, EURC | | AVAX Correlated Spoke | sAVAX, WAVAX | WAVAX | | Forex Spoke | EURC, USDC, USDT | EURC, USDC, USDT | Dedicated RWA Hub: An RWA Hub is expected to be introduced through a follow-up proposal, with its own topology, asset scope, oracle configuration, and risk parameters, so that institutional collateral can be isolated from the core liquidity pool. Risk Parameters Dynamic Liquidation Bonus Configuration For correlated-asset spokes (AVAX Correlated and Forex), liquidationBonusFactor is set to 1.0 because the health factor (HF) range between liquidation eligibility and bad debt is already narrow. Any reduction below this level would steepen the bonus curve and increase losses for leveraged correlated positions. For volatile spokes (Main), healthFactorForMaxBonus is set to 0.9, ensuring that maximum liquidator incentives are active well before positions approach bad-debt levels. To maintain incentive continuity with V3, maxLiquidationBonus on the Main Spoke is set to 1.11 times its V3 value. This keeps the liquidation bonus at HF = 1.0 aligned with V3 while allowing higher incentives as positions deteriorate further. | Chain | Hub | Spoke | Liquidation Bonus Factor | Target Health Factor | Health Factor For Max Bonus | | --- | --- | --- | --- | --- | --- | | Avalanche | Core Hub | Main Spoke | 90.00% | 1.2400 | 0.90 | | Avalanche | Core Hub | AVAX Correlated Spoke | 100.00% | 1.0350 | 0.99 | | Avalanche | Core Hub | Forex Spoke | 100.00% | 1.0442 | 0.99 | V4 Spoke Parameters The liquidation protocol fee is proposed to be set at 10% across all assets, aligning with the configuration used for the majority of assets on Aave V3. | Chain | Hub | Spoke | Reserve | Collateral Factor | Max Liquidation Bonus | Borrowable | Collateral Risk | Liquidation Fee | | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Avalanche | Core Hub | Main Spoke | WAVAX | 73.00% | 10.00% | TRUE | 0 | 10.00% | | Avalanche | Core Hub | Main Spoke | BTC.b | 75.00% | 7.22% | TRUE | 0 | 10.00% | | Avalanche | Core Hub | Main Spoke | USDC | 78.00% | 5.55% | TRUE | 0 | 10.00% | | Avalanche | Core Hub | Main Spoke | USDT | 78.00% | 5.55% | TRUE | 0 | 10.00% | | Avalanche | Core Hub | Main Spoke | WETH.e | 83.00% | 5.55% | TRUE | 0 | 10.00% | | Avalanche | Core Hub | Main Spoke | EURC | 0.00% | - | TRUE | - | - | | Avalanche | Core Hub | AVAX Correlated Spoke | sAVAX | 95.00% | 1.00% | FALSE | 0 | 10.00% | | Avalanche | Core Hub | AVAX Correlated Spoke | WAVAX | 0.00% | - | TRUE | - | - | | Avalanche | Core Hub | Forex Spoke | EURC | 90.00% | 2.00% | TRUE | 0 | 10.00% | | Avalanche | Core Hub | Forex Spoke | USDC | 90.00% | 2.00% | TRUE | 0 | 10.00% | | Avalanche | Core Hub | Forex Spoke | USDT | 90.00% | 2.00% | TRUE | 0 | 10.00% | Add and Draw Caps Add and draw caps have been set, keeping in mind the limited liquidity available on Avalanche, with the specifications reflecting the hub-and-spoke structure of Aave V4 and the distinct risk profiles of each spoke. | Chain | Hub | Spoke | Reserve | Add Cap | Draw Cap | | --- | --- | --- | --- | --- | --- | | Avalanche | Core Hub | Main Spoke | WAVAX | 500,000 | 50,000 | | Avalanche | Core Hub | Main Spoke | BTC.b | 100 | 10 | | Avalanche | Core Hub | Main Spoke | USDC | 5,000,000 | 5,000,000 | | Avalanche | Core Hub | Main Spoke | USDT | 5,000,000 | 5,000,000 | | Avalanche | Core Hub | Main Spoke | WETH.e | 3,000 | 300 | | Avalanche | Core Hub | Main Spoke | EURC | 500,000 | 400,000 | | Avalanche | Core Hub | AVAX Correlated Spoke | sAVAX | 200,000 | 0 | | Avalanche | Core Hub | AVAX Correlated Spoke | WAVAX | 0 | 250,000 | | Avalanche | Core Hub | Forex Spoke | EURC | 300,000 | 400,000 | | Avalanche | Core Hub | Forex Spoke | USDC | 200,000 | 150,000 | | Avalanche | Core Hub | Forex Spoke | USDT | 200,000 | 150,000 | | Avalanche | Core Hub | Core Tokenized WAVAX Spoke | WAVAX | 150,000 | 0 | | Avalanche | Core Hub | Core Tokenized BTC.b Spoke | BTC.b | 20 | 0 | | Avalanche | Core Hub | Core Tokenized USDC Spoke | USDC | 1,500,000 | 0 | | Avalanche | Core Hub | Core Tokenized USDT Spoke | USDT | 1,500,000 | 0 | | Avalanche | Core Hub | Core Tokenized WETH.e Spoke | WETH.e | 600 | 0 | | Avalanche | Core Hub | Core Tokenized EURC Spoke | EURC | 150,000 | 0 | Tokenized Spokes serve as the standard entry point for integrators, vaults, aggregators, and other strategies routing liquidity into Aave V4 markets. They are supply-only and accept deposits exclusively in each hub’s primary borrowable assets, ensuring a simple, composable tokenized representation. Interest Rate Curves The parameters follow the same two-slope utilization curve used in V3, defined by a base variable borrow rate, slope below the optimal usage ratio (Slope 1), slope above it (Slope 2), and the optimal usage ratio itself (Uoptimal). | Chain | Hub | Reserve | Base | Slope 1 | Slope 2 | Uoptimal | Liquidity Fee | | --- | --- | --- | --- | --- | --- | --- | --- | | Avalanche | Core Hub | WAVAX | 1.00% | 4.00% | 144.28% | 65.00% | 20.00% | | Avalanche | Core Hub | BTC.b | 0.00% | 4.00% | 80.00% | 80.00% | 25.00% | | Avalanche | Core Hub | USDC | 0.00% | 4.00% | 10.00% | 90.00% | 10.00% | | Avalanche | Core Hub | USDT | 0.00% | 4.00% | 10.00% | 90.00% | 10.00% | | Avalanche | Core Hub | WETH.e | 0.00% | 2.50% | 8.00% | 90.00% | 15.00% | | Avalanche | Core Hub | EURC | 0.00% | 5.50% | 50.00% | 90.00% | 10.00% | Next Steps 1. If the ARFC Snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Disclaimer Aave Labs is not receiving compensation from Ava Labs for this proposal or the potential deployment of Aave V4 on Avalanche. Aave Labs is presenting this proposal as a service provider to the Aave DAO as part of its approved scope of work in support of DAO operations. Copyright Copyright and related rights waived via CC0. *

!Image 1.jpg --- title: [ARFC] Launch sGHO Cross-Chain author: @TokenLogic created: 2026-06-24 --- Summary This proposal defines the cross-chain deployment strategy for sGHO, extending the savings product introduced in the sGHO Launch Configuration ARFC to Layer 2 networks. The design maintains a single ERC-4626 vault on Ethereum mainnet as the sole source of truth, using Chainlink CCIP to enable cross-chain deposit and withdrawal flows. The architecture introduces two complementary paths: Fast Path: Pre-provisioned sGHO liquidity on destination chains enables instant GHO-to-sGHO (and vice versa) swaps for retail-sized deposits, modelled on the Direct Staking pattern used by Lido for wstETH cross-chain distribution. Slow Path: Larger deposits route GHO cross-chain to the mainnet vault via CCIP, with sGHO bridged back to the user on the origin chain (and vice versa). Initial deployment targets Arbitrum, with subsequent expansion to CEX-aligned networks to support retail onboarding via the Aave App and Earn integrations. Motivation Introducing Cross-chain sGHO sGHO is an interest-compounding ERC4626 token that accrues yield at the Aave Savings Rate (ASR) on Ethereum. Upon implementation, this proposal expands the sGHO offering to other networks, allowing users to access the sGHO savings product locally from each network. This approach continues the strategy of bringing the product to users and promoting a streamlined user experience through a universal savings vault. By maintaining a single sGHO vault on Ethereum and distributing the sGHO token across other networks, every user enjoys the same universal savings rate. To enhance the user experience, the cross-chain sGHO implementation uses a Fast lane and a Slow lane for different transaction sizes. The Fast lane allows users to instantly exchange GHO ↔ sGHO without bridging between networks, whilst larger transactions route via the Slow lane, facilitating bridging, depositing, and bridging back transactions on the user’s behalf. We expect the dual-lane approach to deliver an improved user experience for retail-sized user positions (Aave App) via the Fast lane and for larger integrations to route via the Slow lane, reducing the need for secondary-market liquidity. To support the Fast lane functionality, the Aave DAO will provide working capital that rotates between GHO and sGHO whilst fulfilling users’ orders. The amount of working capital supporting the sGHO liquidity pool locally on each network depends on the user’s position-size profiles and the volume of flows. A non-exhaustive list of the advantages of having a single sGHO vault on Ethereum is presented below: Centralised accounting. Single source-of-truth vault. There is only one instance of the sGho vault where GHO can be deposited. Supply cap governance is simplified. The DAO manages one cap parameter rather than coordinating caps across multiple deployments. !Image 2.png Liquidity is consolidated. GHO backing is never fragmented across chains, ensuring withdrawals are always serviced from a single deep pool. This is the same architectural approach used by Lido for wstETH, where the staking vault exists on the Ethereum with the receipt token distributed cross-chain. Cross-Chain Demand Drivers Several near-term integrations require sGHO availability on L2 networks: Aave App. The Aave App deposits user funds into a vault that allocates across yield sources. sGHO is a primary allocation target. The App requires programmatic deposit and withdrawal flows that work cross-chain without requiring users to interact directly with the Ethereum mainnet. CEX-Chain Integrations. Partnerships with centralized exchanges operating on dedicated chains need sGHO access for earn products. These integrations are expected to generate predominantly retail-sized inflows, well-suited to the Fast path mechanism. GhoRouter Composability. The GhoRouter enables atomic swaps between stablecoins (USDC, USDT) and stataTokens to sGHO via the GSM. Extending this flow cross-chain requires sGHO to be bridgeable while preserving atomicity for the Fast path. Precedent This architecture follows the pattern established by Lido for wstETH cross-chain distribution, as documented in Chainlink's Cross-Chain Staking reference architecture. The approach has been validated at scale with wstETH and is adapted here to sGHO's specific characteristics: ERC-4626 mechanics, GHO's status as a CCIP fee token, and supply cap constraints. Specification Architecture Overview !Image 3.png ------ Due to the Snapshot character limit, the remainder of this proposal can be viewed on the Aave Governance forum.

!image Summary This framework sets the risk standard that governs every asset on Aave V3, V4, and Aave Horizon. It is binding at onboarding, at every quarterly due diligence refresh, at every material-change re-evaluation, and at every parameter or deprecation decision taken on a listed asset. The requirements, evaluation points, and procedures below are to become the standard against which every listing and every parameter decision is measured once the framework is endorsed. Asset safety on Aave is the union of every chain it lives on, every bridge it crosses, and every operational decision its issuer makes between reviews. The framework reflects that surface in full and reinforces continuity in the monitoring of the asset risk vectors as well as automation of the defensive actions. The framework is organised into four layers, each addressing a distinct class of risk and a distinct timescale of control. Layer 1: Asset Risk carries the lifecycle, the qualitative onboarding requirements, the continuous due diligence cadence, the material-change taxonomy, and the conditions under which a reserve or an entire market deployment is wound down. Layer 2: Bridging Risk defines the mandatory bridge configuration baseline that any asset crossing chains must satisfy, the lifecycle for managing those configurations, and the evaluation pillars applied to every bridging stack in use. Layer 3: Monitoring and Automated Risk Oracle Systems defines the enforced automated monitoring of Aave-external layers, the continuous risk oracles and automated freeze guardians that act between adverse events and human response, the Risk Stewards' role as the human-paced complement, and Umbrella's role as the safety net. These are risk management mechanisms rather than discretionary tooling, and the framework codifies them as standing infrastructure because the risks they address are not fully manageable through onboarding requirements and continuous reviews alone. Layer 4: Chain Risk codifies the chain-level evaluation that gates whether Aave should deploy on a chain at all and the standing chain properties that constrain the exposure tier of every asset listed on the deployment, it functions as a precondition to Layers 1 through 3, because every asset and bridging decision on a chain inherits that chain's properties. 1. Asset Risk An asset's life on Aave passes through four stages: onboarding, continuous due diligence, material-change re-evaluation, and an unlikely deprecation. Listing breadth in itself does not signal elevated risk, because exposure is gated at the parameter level long before it becomes systemic. The question this layer answers at every stage is not whether the protocol holds a long list of reserves, but whether each reserve continues to fit the risk and operational profile that justifies its presence. The subsections below define the requirements applied at each stage and the triggers that advance an asset between stages. This framework is designed to operate alongside the Technical Asset Listing Framework proposed by Aave Labs, and the two complement each other during the asset evaluation phase. Read together they are what makes a veto authority exercisable, since the technical framework establishes whether an asset technically can be listed and surfaces material technical concerns, while this framework determines whether it may be listed from the risk surface perspective and at what exposure tier, and holds the explicit veto. Where a subsection below covers ground that the Technical Asset Listing Framework also addresses, the relevant section of that framework and the specific additional requirements it carries are noted in the subsection itself, so the technical requirement and its risk treatment are read together. 1.1 Asset Classification Adherence Equivalently as indicated in the Technical Framework, every asset must map to a governance-ratified Aave Asset class Allowlist (AAcA) before listing, because the class determines the parameter stack, the relevant E-Mode configurations, and the comparable assets the parametrisation is benchmarked against. Onboarding outside an existing class is structurally ambiguous and not accepted under the framework until the asset is included in a newly created class. Requirements: The asset is mapped to an existing governance-ratified asset class (stablecoin group, ETH-correlated group, BTC-correlated group, RWA, or other class formally defined by Aave governance) before listing. Assets that do not fit an existing class require explicit class definition through Aave governance before listing, not ad-hoc onboarding under an analogous but non-binding category. The closest comparable asset already listed under the same class is identified and could be used as a comparable reference for oracle design, LTV, LT, CF, caps, and Credit Lines subject to the new asset's own technical profile. Onboarding under an unconfirmed or out-of-class designation is treated as a hard block at the pre-screening stage, therefore listings for such assets would first need to be approved via the asset class allowlist. 1.2 Multi-Chain Evaluation Scope An asset's risk profile is the union of every chain it lives on and every configuration its issuer has shipped. A fixed snapshot or chain-local evaluation is structurally insufficient because an exploit, misprint, or governance action on one chain inevitably affects stability on every chain where the asset is deployed and translates directly to stress on the lending protocol. Requirements: Every chain the asset is or will be deployed on through Aave is examined as part of the same evaluation. Per-chain bridge topology is documented for every cross-chain route carrying Aave exposure. Per-chain smart contract divergence, including proxy implementation and smart contract structure, is documented and reconciled to the latest audited version. Per-chain access-control and parameter divergence is documented. Per-chain oracle path and adapter configuration is documented. Material divergence across chains that cannot be reconciled to a single documented configuration profile materially constrains the asset's cross-chain exposure tier. 1.3 Smart Contract Audit Coverage Audits are the standing technical attestation that the asset's contracts implement the design the framework's other operational controls assume. Recency matters as much as existence because the threat landscape and the asset's contracts both evolve between audits. Requirements: The deployed version of the asset is covered by audits from reputable firm(s) completed with a published audit report. Re-attestation is required on every subsequent material upgrade rather than reliance on the original audit. Bridge-side contracts on every deployed chain are reviewed under the same standard as the asset contract itself, because the bridge contract is part of the asset on the destination chain. Audit reports are provided to the risk provider; any unresolved findings are disclosed. Past incidents on any deployed version are disclosed with post-mortem and documented remediation. Audits without re-attestation on subsequent material upgrades, unresolved Critical or High findings, or past exploits without documented remediation are hard-block conditions. This matches the requirements of the technical listing framework. 1.4 Bug Bounty Coverage A live bug bounty program is the only standing financial incentive aligning external security researchers with the asset's safety. Detailed expectations are set out in the LlamaRisk Bug Bounty Landscape report and form the baseline applied here. Requirements: A live bug bounty program covering the asset and its critical dependencies is in place at listing and maintained continuously. Minimum payout floor of $50,000 for a critical finding as an absolute minimum regardless of TVL. Maximum payout that scales with the protocol’s TVL, sized using bounty value per million dollars of TVL as the reference metric, with comparisons of this metric for current Aave assets presented in the Bug Bounty Landscape document. Scope covers loss of user funds, private-key or password exposure, user-information disclosure, unauthorised state-modifying actions, infrastructure compromise, domain takeover, and malicious redirection. Smart-contract-only scope is not sufficient anymore. The program is preferably platform-managed (Immunefi, HackerOne, or equivalent) given platform-managed programs' professional triage, credibility, and stronger researcher network effects. Missing or materially weak bug bounty coverage is a hard-block condition. --------- Due to the Snapshot character limit, the remainder of this proposal can be viewed on the Aave Governance forum.