Aave Governance

Summary This publication outlines the next incremental reduction in Safety Module emissions and also, the first update to Umbrella emissions. Motivation Umbrella Since our last update, user deposits in Umbrella have increased from $248.9M to $357.0M, well exceeding the Target Coverage of $293.3M. !Screenshot 2025-09-08 at 20.05.32 Source: https://aave.tokenlogic.xyz/umbrella-eth-core !Screenshot 2025-09-08 at 20.05.15 Source: https://aave.tokenlogic.xyz/umbrella-eth-core Most notably, ETH deposits within Umbrella are consistently over the Target Liquidity, they are ~54% at the time of writing. With less than $5M in cooldown, this trend is likely to continue given the high level of concentration with one use comprising 61% of ETH liquidity. !Screenshot 2025-09-08 at 20.10.25 Source: https://aave.tokenlogic.xyz/umbrella-eth-core !Screenshot 2025-09-08 at 20.15.25 Source: https://aave.tokenlogic.xyz/umbrella-eth-core In response, this publication proposes reducing the Max waETH Emission Rate. By reducing the Max Emissions from 550 to 440 the new emission rate at the Target Liquidity amount would be 1.205 ETH/day and equal to the current emission rate. However, this would be the first emission update since Umbrella went live, and with this in mind a notably smaller reduction is proposed with a subsequent follow up proposal when more data to assess the elasticity of users' appetite for deploying capital into Umbrella is available. This publication proposes reducing the Max Emission Rate from 550 to 500 representing a 10% reduction in annual budget. Depending how the market responds, a further amendment can be proposed at a later date. Safety Module Overview At the start of 2025, the daily AAVE emission rate was 820 AAVE/day, this proposal if implemented will further reduce AAVE emissions to 300 AAVE/day across all Safety Module categories. !Screenshot 2025-09-08 at 21.45.44 When implemented, AAVE emissions will be reduced from 390 AAVE/day to 300 AAVE/day. A reduction of 90 AAVE/DAY, is equivalent to 32,850 AAVE/year: worth $9.85M in annual savings with AAVE trading at $300. With AAVE trading at $300 the daily AAVE buyback rate is approximately 476 AAVE/day, the result is Aave DAO increasing its AAVE holdings by 176 AAVE/day excluding any Service Provider related expenses. This is a considerable improvement from a runway perspective. stkAAVE On the 5th June 2025, the Umbrella upgrade went live, resulting in AAVE emissions for the stkAAVE category being reduced inline with the new Aavenomics presented by the @ACI team. This publication continues to implement the Aavenomics vision by further reducing AAVE emissions and slashing exposure on the Aave Safety Module. When implemented, this proposal will further reduce Slashing risk to 0% for stkAAVE holders. stkAAVE Holders will benefit from a risk free-yield with a 7-days cooldown period. The improved risk profile and reduced cooldown period improves the overall attractiveness of holding stkAAVE. stkAAVE Emission Schedule | Category | Pre-Umbrella | Umbrella Update | Update #1 | Update #2 | | :------- | :----------: | :-------------: | :----------: | :----------: | | Date | Mar 14, 2024 | Jun 05, 2025 | Jul 29, 2025 | Proposed | | stkAAVE | 360 AAVE/Day | 315 AAVE/Day | 260 AAVE/Day | 260 AAVE/Day | | Cooldown | 20 days | 20 days | 20 days | 7 days | | Slashing | 30% | 20% | 10% | 0% | The chart below show the stkAAVE yield reducing over time from 4.58% on the 5th June 2025 to 3.37% on 31st August 2025. !Screenshot 2025-09-09 at 20.32.38 Source: https://aave.tokenlogic.xyz/stkaave Over this period, the amount of AAVE staked has changed from 2,870,483 AAVE on the 5th June 2025 to 2,811,859 AAVE on the 8th September. A change of 58,624 AAVE or a reduction of 2.04% since the 5th June 2025. !Screenshot 2025-09-09 at 20.31.50 Source: https://aave.tokenlogic.xyz/stkaave Given the strong support for stkAAVE at the reduced rate, we propose leaving stkAAVE emissions as-is and monitoring the impact of how the market responds to further reductions in stkABPT and also, the 112,091 AAVE currently in cooldown due out 12th September. !Screenshot 2025-09-09 at 20.30.36 Source: https://aave.tokenlogic.xyz/stkaave Reducing Slashing from 10% to 0%, improves the risk profile of stkAAVE by eliminating the slashing tail risk of being slashed by a shortfall event. The current stkAAVE category receives 260 AAVE/day, for an annual spend of 94,900 AAVE. This compares favourably to the total 84,640 AAVE purchased to date via the Buyback program since the 9th April 2025. stkABPT stkABPT Emission Schedule Category | Pre-Umbrella | Umbrella Update | Update #1 | Update #2 | | :------- | :----------: | :-------------: | :----------: | :----------: | | Date | Apr 29, 2025 | Jun 05, 2025 | Jul 29, 2025 | Proposed | | stkABPT | 240 AAVE/Day | 216 AAVE/Day | 130 AAVE/Day | 40 AAVE/Day | | Cooldown | 20 days | 20 days | 20 days | 20 days | | Slashing | 30% | 20% | 10% | 0% | Since the 5th June 2025, when the Umbrella upgrade went live, stkABPT emissions reduced from 240 AAVE/day to 130 AAVE/day. Over this time, 42.41% of the liquidity has been removed from the pool with the majority coming from one of a select few liquidity providers. On the 1st September, a single user redeemed 227,952 BPT as AAVE and wstETH from the Balancer pool, then redeposited a portion. !Screenshot 2025-09-09 at 20.29.06 Source: https://aave.tokenlogic.xyz/stkabpt Overall, the number of unique users remains unchanged with a net reduction of 13 users over the last 30 day period, to 453 unique addresses. With the recent large withdrawal, the stkABPT yield has increased to average 14.90% over the last 7 days. On the 22nd September another large withdrawal day (83,142 ABPT) is anticipated, with 82,411 of the 83,142 ABPT being the same user mentioned earlier. The chart below shows the yield profile since 1st August 2025 with the overall yield expected to increase to around 19-20% APR from the 22nd September. !Screenshot 2025-09-09 at 20.26.20 Source: https://aave.tokenlogic.xyz/stkabpt To balance the liquidity outflows, we recommend reducing the AAVE emissions to the stkABPT category by ~70%, to 40 AAVE/day, which reduces the yield to around 6.5-8% after allowing for the stkABPT currently in cooldown. The resulting yield compares favourably to the previous guidance of ~8% when combined with a reduction in slashing risk from 10% to 0%. More generally, the resulting impact is expected to lead to the market finding a new equilibrium. Over the last 30 days, the utilisation of the ABPT liquidity, Swap Volume / Pool TVL, experienced 3 large trading days resulting in over 6% utilisation. The vast majority of swaps, 93.8%, are under $40k USD. A reduction in pool TVL is not likely to impede the pools ability to attract swap volume. !Screenshot 2025-09-09 at 20.24.58 Source: https://aave.tokenlogic.xyz/stkabpt The emergence of new liquidity pool(s) mentioned in the next section presents an opportunity to measure the impact of new liquidity pools with improved capital efficiency. AAVE Liquidity Balancer Over the last month, we have continued to work with Balancer on refining AAVE liquidity. With a focus on attracting swap volume, we have elected to proceed with a reCLMM (non-boosted) pool by submitting the gauge proposal for Ethereum and Arbitrum. The two pools being considered are linked below: Ethereum AAVE/WETH Pool Arbitrum AAVE/WETH Pool Based upon the historical data available on Ethereum, the Impermanent loss from 1st August to 7th September 2025 ranged from -0.41% to 0.41% utilising data from an initial deposit of slightly less than $10k. During this period, AAVE/WETH traded within an 18% price range, which is quite low by historical standards and the liquidity in the pool was rebalanced four time. !Screenshot 2025-09-09 at 19.52.40 Whilst recognising the sample period is only 40 days and the pools liquidity was always less than $90k, the below chart highlights the volatility in swap fee APR. With deeper liquidity and the Balancer team continuing to promote more pool integrations, we expect the data to normalise over time enabling us to better compares to other liquidity venues. !Screenshot 2025-09-09 at 19.50.40 With over $250M in liquidity for the majority of August 2025, the reduction in AAVE emissions is expected to result greater liquidity outflows from the pool. With users withdrawing liquidity from the pool expected to accelerate, we recommend the Aave DAO begin providing liquidity to the reCLMM pool as part of the transitioning towards both more efficient and lower cost liquidity without adversely affecting users ability to trade AAVE on Balancer. An initial $10M liquidity provision is proposed, funded from the Economic Reserve and Collector Contract, and depending upon the utilisation and impermanent loss exposure of the pool the allocation is to be adjusted in the future. A $10M reCLMM allocation is expected to be sufficient to replace the liquidity within the weighted 80/20 AAVE/wstETH pool. Aerodrome Liquidity on Aerodrome has reduced from approximately $10M USD in AAVE/WETH to around $3M even though a notably higher yield was achieved relative to Balancer since the last forum update. We will continue to monitor the pool over time to see if the elevated yield is able to attract any organic user deposits following stkABPT rewards being reduced. !Screenshot 2025-09-09 at 20.12.39 Source: https://dune.com/0xkhmer/aerodrome !Screenshot 2025-09-09 at 20.11.22 Source: https://dune.com/0xkhmer/aerodrome Specification This proposal when implemented via AIP will: Umbrella wETH Update | Umbrella Asset | Current Max Emission | Proposed Max Emission | | :------------- | :------------------: | :-------------------: | | waWETH | 550 | 500 | Reduce AAVE Emissions | SM Category | Current | Proposed | | :---------- | :-----: | :------: | | stkAAVE | 260/day | 260/day | | stkABPT | 130/day | 40/day | Reduce Slashing Risk | SM Category | Current | Proposed | | :---------- | :-----: | :------: | | stkAAVE | 10% | 0% | | stkABPT | 10% | 0% | Reduce Cooldown Period | SM Category | Current | Proposed | | :---------- | :-----: | :------: | | stkAAVE | 20 days | 7 days | | stkABPT | 20 days | 20 days | AAVE/wETH Liquidity Funding Create allowances to a new Aave Liquidity SAFE, for the equivalent of $5M AAVE and $5M aEthWETH from Aave Ecosystem Reserve and Aave Core instances on Ethereum at the time the AIP is submitted. Asset: AAVE 0x7Fc66500c84A76Ad7e9c93437bFc5Ac33E2DDaE9 Amount: $5M USD Asset: aEthWETH: 0x4d5F47FA6A74757f35C14fD3a6Ef8E3C9BC514E8 Amount: $5M USD Spender: Aave Liquidity TBA Method: approve() AAVE and aEthWETH on the Ecosystem Reserve and Aave Collector contract to the new Aave Liquidity SAFE. The signers on the new Aave Liquidity SAFE are the same as other Asset holding SAFEs, detailed here, with a 3 of 4 signer requirement. Forward Looking Statement Similar to the previous proposal, approximately 30 days after the AIP is executed, TokenLogic will review how users respond to the changes and the impact this has on AAVE liquidity. With a favourable outcome across both AAVE DEX liquidity and WETH deposits in Umbrella, the next update is likely to include the following updates: Direct AAVE liquidity provisioning to be increased; stkABPT rewards to be reduced to zero; and, Umbrella wETH Max Emissions to be revised lower if liquidity remains elevated relative to the Target Liquidity. Disclosure TokenLogic does not receive any payment for this proposal. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

Summary We are excited to present the next iteration of Aave's non-custodial Treasury Management tooling suite. We are expanding the Aave Finance Steward role to perform swaps on Ethereum via MainnetSwapSteward v1 and claim Liquidity Mining rewards across acrued to the collector across all networks viaRewardsSteward. Activating these steward roles will enable Aave DAO to further streamline operations and reduce governance overhead in a secure and safe manner. Overview Following the successful deployment of the Pool Exposure Stewards back in April, this publication seeks to deploy the next set of modules that comprise the Aave Finance Steward. The Finance Steward role is comprised of a set of Modules (Smart Contracts) that provide approved signers with the ability to perform DAO approved actions such as swapping tokens or migrating assets from Aave V2 to Aave V3, without having to rely on governance. This publication deploys the MainnetSwapSteward, grants the initial budget for swaps, and deploys the Rewards Stewards to claim earned rewards on a timely manner. !telegram-cloud-photo-size-4-5893280474481151642-y Motivation The Finance Steward modules enables the DAO to define a core set of financial capabilities to be carried out within strict role-based guardrails. As the role matures or new use cases arise, we plan to bring forward additional capabilities for the DAO to discuss. This publication includes deploying two separate contracts. The MainnetSwapSteward is deployed to more easily perform swaps on behalf of the DAO, as well as introducing TWAP Orders on-chain without having to grant an allowance to the AFC, meaning the DAO's funds never leave the DAO's possession. The RewardsSteward grants the stewards the ability to claim Aave rewards to be sent to the collector. MainnetSwapSteward Regular Orders Regular orders of token for token, using Chainlink price oracles and a slippage number. This is the current behavior used in all swaps. Limit Orders Orders that only execute from a certain price point or better for the DAO. TWAP Orders Time weighted average price orders, which are orders that execute over a period of time, with a minimum amount expected to be received. Cancellation of Orders The ability to cancel orders if needed or wanted by the DAO. RewardsSteward ClaimRewards Claims specific rewards on behalf of the DAO, which are sent to the collector. ClaimAllRewards Claims all pending rewards on behalf of the DAO, which are sent to the collector. Specification The RewardsSteward is a permissionless contract that can be called by anyone to claim rewards, but first the ability for that contract to claim rewards must be granted by the Emission Manager by calling setClaimer() on the IncentivesController for each deployment, listed below: | Network | | --------- | | Mainnet | | Polygon | | Avalanche | | Optimism | | Arbitrum | | Scroll | | Base | | BNB | | Gnosis | | Sonic | The MainnetSwapSteward contract has been deployed (with more chains coming in the future), with the DAO as the owner of the contracts and the following SAFE acting as the guardian 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa. The SAFE is configured as a 3-out-of-4 multi-sig, and the signers for the SAFE are the following: Marc (AaveChan) - 0x329c54289Ff5D6B7b7daE13592C6B1EDA1543eD4 Matt (TokenLogic) - 0xb647055A9915bF9c8021a684E175A353525b9890 Chaos Labs - 0x5d49dBcdd300aECc2C311cFB56593E71c445d60d Val (LlamaRisk) - 0xbA037E4746ff58c55dc8F27a328C428F258DDACb The initial budget (allowance) granted to the SwapSteward via this proposal will be as follows: | Token | Budget | Token | Budget | | :---: | :----: | :---: | :----: | | USDC | 5M | UNI | 15k | | USDT | 5M | MKR | 100 | | USDe | 5M | 1INCH | 50k | | USDS | 5M | ENS | 200 | | DAI | 3M | SNX | 150k | | rlUSD | 1M | SPK | 375.8k | | LUSD | 500k | SAFE | 5.2k | | FRAX | 150k | | pyUSD | 20k | Upon implementation of the ClinicSteward by @bgdlabs on v2, we will revisit future Allowances with input from Risk Service Providers. ClinicSteward details can be found here. Forward Looking Statement From writing custom contracts on a proposal every time the DAO wanted to sell assets, to the more standardized Aave Swapper that has been in use for the past two years, to the now more powerful MainnetSwapSteward, TokenLogic continues to bring the DAO solutions for both governance efficiency and capital efficiency. The next evolution of swaps we are currently working on is the natural expansion of the SwapSteward to various networks to more easily swap tokens there. Currently, funds on L2s must either be bridged back to Mainnet or trusted to the AFC to swap. At TokenLogic we believe in the DAO always keeping control of its funds wherever it is practical to do so and will continue to provide solutions for that to be a reality across all chains. The existing bridging capabilities is currently limited to Polygon, Optimism and Arbitrum, and they all depend on governance as well, which leads to very big funding updates. We have migrated the Polygon bridge to a steward (coming in a proposal soon), and will be doing the same for both Optimism and Arbitrum, as well as working on extending the networks where bridging is available. The first extension of bridging coming is the CCIP bridge which will allow the DAO to bridge GHO to supported EVM chains as well as non-EVM chains (such as Aptos). The CCIP work is the last milestone to be achieved in bringing Gho Stability Modules to other networks with the RemoteGSM work already completed. Disclosure TokenLogic does not receive any payment for this proposal. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

Title: [ARFC] Adopt The SEAL Safe Harbor Agreement Authors: @samczsun (SEAL), @dickson (SEAL), bgdlabs.eth Date: 2025-09-02 --- Introduction This proposal outlines Aave Governance’s adoption of the SEAL (Security Alliance) Whitehat Safe Harbor Agreement (“Safe Harbor Agreement”). By adopting Safe Harbor, Aave improves the security of its on-chain assets by allowing whitehats to intervene during active exploits to save protocol funds. What is the Safe Harbor Agreement? The Safe Harbor Agreement addresses a critical need in crypto: enabling whitehats to intervene during active exploits when traditional responsible disclosure procedures are not feasible. Key aspects of the agreement include: Encouraging Whitehats to Protect the Protocol: By adopting Safe Harbor, Aave incentivizes whitehats to step in and protect the protocol during active exploits by limiting their legal exposure. Intervention Only During Active Exploits: Whitehats are authorized to act only when there is an immediate or ongoing exploit that threatens the protocol. This agreement applies only to critical situations where responsible disclosure procedures would not save funds due to the urgency of the exploit, and it is not intended for routine security testing or vulnerability reporting. An example of what would fall under scope would be a malicious transaction present in the mempool, which could be frontrun. An example of what falls out of scope would be a security researcher finding a critical vulnerability that should be reported to the protocol via a bug bounty provider. Any attempt to initiate a blackhat transaction, or to disguise a blackhat action as a whitehat intervention, is strictly prohibited and will not be protected under this safe harbor, and may result in prosecution to the fullest extent of the law. Mandatory Return of Rescued Funds: Under the terms of the Safe Harbor, whitehats are required to return all rescued assets to a pre-designated recovery address controlled by the protocol within 72 hours of recovering them. This ensures that recovered funds are quickly secured, preventing delay or potential loss. Clear Guidelines and Legal Protection: The agreement establishes strict rules for how whitehats must operate during an exploit, ensuring recovery efforts are conducted professionally and safely, minimizing the risk of mistakes or further damage to the protocol. By adhering to these guidelines, whitehats can limit their potential legal exposure, allowing them to act in good faith without fear of liability. Incentivized Rescue Efforts: To motivate whitehats to act during critical situations, the agreement offers a bounty system similar to a bug bounty. Whitehats are rewarded with a percentage of the recovered assets, up to a predefined cap, for their successful interventions. Note: Safe Harbor and the Bug Bounty program are totally separate, but mutually exclusive rewards-wise: a whitehat rewarded for a report via the Bug Bounty program is not eligible for a reward on the same exploit, even if legal protection of Safe Harbor applies. --- Rationale Aave is committed to enhancing its security and protecting user funds during critical moments. While security audits and other preventive measures are crucial, the unpredictable nature of exploits requires a swift, decisive response mechanism to minimize potential damage. The Safe Harbor Agreement empowers whitehats to act immediately during an active exploit, providing a proactive and structured recovery process. By enabling whitehats to step in and recover assets during a crisis, Aave strengthens its defenses against emerging threats. Benefits of adopting the Safe Harbor Agreement include: Agile Defense Against Exploits: Whitehats are authorized to intervene as soon as an active exploit is detected, enabling them to respond faster than traditional methods. This ensures that Aave is protected against threats even without the ability to halt the protocol. Immediate action minimizes the window for malicious actors, reduces damages, and accelerates the recovery of assets during critical moments. Clarified Rescue Process: The agreement ensures that every step, from intervention to fund recovery, is predetermined and streamlined. Whitehats know exactly where to send recovered funds, preventing chaotic negotiations or rushed decisions during an exploit. This clarity ensures efficient, decisive action when it matters most. Clear Financial Boundaries: The predefined bounty system, with a cap matching Aave’s existing bug bounty, ensures that whitehats are incentivized fairly without creating conflicting priorities between exploit intervention and standard vulnerability disclosure. By setting expectations upfront, it eliminates post-exploit negotiations, ensuring funds are returned promptly without attempts to change the reward amount, keeping the process fair and transparent. Aligning with Industry Best Practices: By adopting the Safe Harbor Agreement, Aave aligns itself with leading security practices across the industry, reinforcing its commitment to staying at the forefront of protocol security. Adoption of the agreement complements audits by providing an additional layer of security, ensuring that the protocol is better prepared to respond to active threats. --- Adoption Details Aave will adopt the agreement with the following parameters. For a full description of these adoption details, review the Safe Harbor for Protocols document. 1. Asset Recovery Address: Addresses controlled by Aave, which recovered funds will be returned to in the event of a hack. | | | |----|----| | Chain | Address | | Ethereum | 0x464C71f6c2F760DdA6093dCB91C24c39e5d6e18c | | Polygon PoS | 0xe8599F3cc5D38a9aD6F3684cd5CEa72f10Dbc383 | | Avalanche C-Chain | 0x5ba7fd868c40c16f7aDfAe6CF87121E13FC2F7a0 | | Optimism | 0xB2289E329D2F85F1eD31Adbb30eA345278F21bcf | | Arbitrum | 0x053D55f9B5AF8694c503EB288a1B7E552f590710 | | Base | 0xBA9424d650A4F5c80a0dA641254d1AcCE2A37057 | | BNB Chain | 0x25Ec457d1778b0E5316e7f38f3c22baF413F1A8C | | Metis | 0xB5b64c7E00374e766272f8B442Cd261412D4b118 | | Gnosis Chain | 0x3e652E97ff339B73421f824F5b03d75b62F1Fb51 | | ZKSync Era | 0xd69Cbda644c6be817AaFb5Fd9174f50C33803B6b | | Scroll | 0x90eB541e1a431D8a30ED85A77675D1F001128cb5 | | Sonic | 0x1aB55bBdD5DF0782BBCf73553Af93BC6B29A286B | | Soneium | 0xc7B3cc5F5988613b0D620623C514EDFB32539720 | | Linea | 0x86E2938daE289763D4e09a7e42c5cCcA62Cf9809 | | Celo | 0xC959439207dA5341B74aDcdAC59016aa9Be7E9E7 | 2. Scope: List of all on-chain assets protected under Safe Harbor. | Chain | Name | Address | Type (None, Existing Only, All) | |----|----|----|----| | Ethereum | Pool Addresses Provider (Core) | 0x2f39d218133AFaB8F2B819B1066c7E434Ad94E9e | Existing Only | | Ethereum | Pool (Core) | 0x87870Bca3F3fD6335C3F4ce8392D69350B4fA4E2 | All (all active libraries, and the implementation under proxy) | | Ethereum | Pool Configurator (Core) | 0x64b761D848206f447Fe2dd461b0c635Ec39EbB27 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Ethereum | Oracle (Core) | 0x54586bE62E3c3580375aE3723C145253060Ca0C2 | All (all per-asset feeds) | | Ethereum | ACL Manager (Core) | 0xc2aaCf6553D20d1e9d78E365AAba8032af9c85b0 | Existing only | | Ethereum | Collector (Core) | 0x464C71f6c2F760DdA6093dCB91C24c39e5d6e18c | All (implementation under proxy) | | Ethereum | Debt Swap Adapter (Core) | 0xd7852E139a7097E119623de0751AE53a61efb442 | Existing only | | Ethereum | RepayWithCollateralAdapter (Core) | 0x35bb522b102326ea3F1141661dF4626C87000e3E | Existing only | | Ethereum | SwapCollateralAdapter (Core) | 0xADC0A53095A0af87F3aa29FE0715B5c28016364e | Existing only | | Ethereum | WETHGateway (Core) | 0xd01607c3C5eCABa394D8be377a08590149325722 | Existing only | | Ethereum | StataTokenFactory (Core) | 0xCb0b5cA20b6C5C02A9A3B2cE433650768eD2974F | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Ethereum | RateStrategy (Core) | 0x9ec6F08190DeA04A54f8Afc53Db96134e5E3FdFB | Existing only | | Ethereum | Pool Addresses Provider (Prime) | 0xcfBf336fe147D643B9Cb705648500e101504B16d | Existing Only | | Ethereum | Pool (Prime) | 0x4e033931ad43597d96D6bcc25c280717730B58B1 | All (all active libraries, and the implementation under proxy) | | Ethereum | Pool Configurator (Prime) | 0x342631c6CeFC9cfbf97b2fe4aa242a236e1fd517 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Ethereum | Oracle (Prime) | 0xE3C061981870C0C7b1f3C4F4bB36B95f1F260BE6 | All (all per-asset feeds) | | Ethereum | ACL Manager (Prime) | 0x013E2C7567b6231e865BB9273F8c7656103611c0 | Existing only | | Ethereum | Debt Swap Adapter (Prime) | 0xd1B2dec98A95B773C4909B5CD8FB455F467A527f | Existing only | | Ethereum | RepayWithCollateralAdapter (Prime) | 0x66E1aBdb06e7363a618D65a910c540dfED23754f | Existing only | | Ethereum | SwapCollateralAdapter (Prime) | 0xD0887AA7fEBC8962c622493646195e7c76D94fCE | Existing only | | Ethereum | WETHGateway (Prime) | 0x3167C452fA3fa1e5C16bB83Bc0fde4519C464299 | Existing only | | Ethereum | StataTokenFactory (Prime) | 0x347C75d19718a05148687E13dca259aD016aB411 | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Ethereum | RateStrategy (Prime) | 0x8958b1C39269167527821f8c276Ef7504883f2fa | Existing only | | Polygon PoS | Pool Addresses Provider | 0xa97684ead0e402dC232d5A977953DF7ECBaB3CDb | Existing Only | | Polygon PoS | Pool | 0x794a61358D6845594F94dc1DB02A252b5b4814aD | All (all active libraries, and the implementation under proxy) | | Polygon PoS | Pool Configurator | 0x8145eddDf43f50276641b55bd3AD95944510021E | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Polygon PoS | Oracle | 0xb023e699F5a33916Ea823A16485e259257cA8Bd1 | All (all per-asset feeds) | | Polygon PoS | ACL Manager | 0xa72636CbcAa8F5FF95B2cc47F3CDEe83F3294a0B | Existing only | | Polygon PoS | Debt Swap Adapter | 0xE28E2c8d240dd5eBd0adcab86fbD79df7a052034 | Existing only | | Polygon PoS | RepayWithCollateralAdapter | 0x5d4D4007A4c6336550DdAa2a7c0d5e7972eebd16 | Existing only | | Polygon PoS | SwapCollateralAdapter | 0xC4aff49fCeD8ac1D818a6DCAB063f9f97E66ec5E | Existing only | | Polygon PoS | WETHGateway | 0xBC302053db3aA514A3c86B9221082f162B91ad63 | Existing only | | Polygon PoS | StataTokenFactory | 0x1504F1d7b6892600ae0d394F9042e696dd9F87Fa | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Polygon PoS | RateStrategy | 0x56076f960980d453b5B749CB6A1c4D2E4e138B1A | Existing only | | Avalanche C-Chain | Pool Addresses Provider | 0xa97684ead0e402dC232d5A977953DF7ECBaB3CDb | Existing Only | | Avalanche C-Chain | Pool | 0x794a61358D6845594F94dc1DB02A252b5b4814aD | All (all active libraries, and the implementation under proxy) | | Avalanche C-Chain | Pool Configurator | 0x8145eddDf43f50276641b55bd3AD95944510021E | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Avalanche C-Chain | Oracle | 0xEBd36016B3eD09D4693Ed4251c67Bd858c3c7C9C | All (all per-asset feeds) | | Avalanche C-Chain | ACL Manager | 0xa72636CbcAa8F5FF95B2cc47F3CDEe83F3294a0B | Existing only | | Avalanche C-Chain | Debt Swap Adapter | 0xE28E2c8d240dd5eBd0adcab86fbD79df7a052034 | Existing only | | Avalanche C-Chain | RepayWithCollateralAdapter | 0x5d4D4007A4c6336550DdAa2a7c0d5e7972eebd16 | Existing only | | Avalanche C-Chain | SwapCollateralAdapter | 0x2Cf641F7C0eac2788A7924B82d6Ca8EB7bAa4E3A | Existing only | | Avalanche C-Chain | WETHGateway | 0x2825cE5921538d17cc15Ae00a8B24fF759C6CDaE | Existing only | | Avalanche C-Chain | StataTokenFactory | 0xC2E7A608d868817dd58438913Ed72955a0567561 | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Avalanche C-Chain | RateStrategy | 0xCe1C5509f2f4d755aA64B8D135B15ec6F12a93da | Existing only | | Optimism | Pool Addresses Provider | 0xa97684ead0e402dC232d5A977953DF7ECBaB3CDb | Existing Only | | Optimism | Pool | 0x794a61358D6845594F94dc1DB02A252b5b4814aD | All (all active libraries, and the implementation under proxy) | | Optimism | Pool Configurator | 0x8145eddDf43f50276641b55bd3AD95944510021E | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Optimism | Oracle | 0xD81eb3728a631871a7eBBaD631b5f424909f0c77 | All (all per-asset feeds) | | Optimism | ACL Manager | 0xa72636CbcAa8F5FF95B2cc47F3CDEe83F3294a0B | Existing only | | Optimism | Debt Swap Adapter | 0xE28E2c8d240dd5eBd0adcab86fbD79df7a052034 | Existing only | | Optimism | RepayWithCollateralAdapter | 0x5d4D4007A4c6336550DdAa2a7c0d5e7972eebd16 | Existing only | | Optimism | SwapCollateralAdapter | 0x830C5A67a0C95D69dA5fb7801Ac1773c6fB53857 | Existing only | | Optimism | WETHGateway | 0x5f2508cAE9923b02316254026CD43d7902866725 | Existing only | | Optimism | StataTokenFactory | 0x170d6D6FCAbF0Ba3932a03d5f470c16c39c18e39 | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Optimism | RateStrategy | 0x9359282735496463131139875849d5302Fb4bed1 | Existing only | | Arbitrum | Pool Addresses Provider | 0xa97684ead0e402dC232d5A977953DF7ECBaB3CDb | Existing Only | | Arbitrum | Pool | 0x794a61358D6845594F94dc1DB02A252b5b4814aD | All (all active libraries, and the implementation under proxy) | | Arbitrum | Pool Configurator | 0x8145eddDf43f50276641b55bd3AD95944510021E | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Arbitrum | Oracle | 0xb56c2F0B653B2e0b10C9b928C8580Ac5Df02C7C7 | All (all per-asset feeds) | | Arbitrum | ACL Manager | 0xa72636CbcAa8F5FF95B2cc47F3CDEe83F3294a0B | Existing only | | Arbitrum | Debt Swap Adapter | 0x63dfa7c09Dc2Ff4030d6B8Dc2ce6262BF898C8A4 | Existing only | | Arbitrum | RepayWithCollateralAdapter | 0xE28E2c8d240dd5eBd0adcab86fbD79df7a052034 | Existing only | | Arbitrum | SwapCollateralAdapter | 0xF3C3F14dd7BDb7E03e6EBc3bc5Ffc6D66De12251 | Existing only | | Arbitrum | WETHGateway | 0x5283BEcEd7ADF6D003225C13896E536f2D4264FF | Existing only | | Arbitrum | StataTokenFactory | 0xd85922fFF51ba4130cEC7c499db4Ac3Eb9981EaD | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Arbitrum | RateStrategy | 0x429F16dBA3B9e1900087Cbaa7b50D38Bc60fB73F | Existing only | | Base | Pool Addresses Provider | 0xe20fCBdBfFC4Dd138cE8b2E6FBb6CB49777ad64D | Existing Only | | Base | Pool | 0xA238Dd80C259a72e81d7e4664a9801593F98d1c5 | All (all active libraries, and the implementation under proxy) | | Base | Pool Configurator | 0x5731a04B1E775f0fdd454Bf70f3335886e9A96be | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Base | Oracle | 0x2Cc0Fc26eD4563A5ce5e8bdcfe1A2878676Ae156 | All (all per-asset feeds) | | Base | ACL Manager | 0x43955b0899Ab7232E3a454cf84AedD22Ad46FD33 | Existing only | | Base | Debt Swap Adapter | 0xb12e82DF057BF16ecFa89D7D089dc7E5C1Dc057B | Existing only | | Base | RepayWithCollateralAdapter | 0x63dfa7c09Dc2Ff4030d6B8Dc2ce6262BF898C8A4 | Existing only | | Base | SwapCollateralAdapter | 0x2E549104c516b8657A7D888494DfbAbD7C70b464 | Existing only | | Base | WETHGateway | 0xa0d9C1E9E48Ca30c8d8C3B5D69FF5dc1f6DFfC24 | Existing only | | Base | StataTokenFactory | 0x78d33BF0014ab169725F2Ea5a62b200F2977faeE | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Base | RateStrategy | 0x86AB1C62A8bf868E1b3E1ab87d587Aba6fbCbDC5 | Existing only | | BNB Chain | Pool Addresses Provider | 0xff75B6da14FfbbfD355Daf7a2731456b3562Ba6D | Existing Only | | BNB Chain | Pool | 0x6807dc923806fE8Fd134338EABCA509979a7e0cB | All (all active libraries, and the implementation under proxy) | | BNB Chain | Pool Configurator | 0x67bdF23C7fCE7C65fF7415Ba3F2520B45D6f9584 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | BNB Chain | Oracle | 0x39bc1bfDa2130d6Bb6DBEfd366939b4c7aa7C697 | All (all per-asset feeds) | | BNB Chain | ACL Manager | 0x2D97F8FA96886Fd923c065F5457F9DDd494e3877 | Existing only | | BNB Chain | Debt Swap Adapter | 0x5d4D4007A4c6336550DdAa2a7c0d5e7972eebd16 | Existing only | | BNB Chain | RepayWithCollateralAdapter | 0x5598BbFA2f4fE8151f45bBA0a3edE1b54B51a0a9 | Existing only | | BNB Chain | SwapCollateralAdapter | 0x33E0b3fc976DC9C516926BA48CfC0A9E10a2aAA5 | Existing only | | BNB Chain | WETHGateway | 0x0c2C95b24529664fE55D4437D7A31175CFE6c4f7 | Existing only | | BNB Chain | StataTokenFactory | 0x929B8a21a604b93DD7e95d5b9aAa3aDf5bE250ae | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | BNB Chain | RateStrategy | 0x86AB1C62A8bf868E1b3E1ab87d587Aba6fbCbDC5 | Existing only | | Metis | Pool Addresses Provider | 0xB9FABd7500B2C6781c35Dd48d54f81fc2299D7AF | Existing Only | | Metis | Pool | 0x90df02551bB792286e8D4f13E0e357b4Bf1D6a57 | All (all active libraries, and the implementation under proxy) | | Metis | Pool Configurator | 0x69FEE8F261E004453BE0800BC9039717528645A6 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Metis | Oracle | 0x38D36e85E47eA6ff0d18B0adF12E5fC8984A6f8e | All (all per-asset feeds) | | Metis | ACL Manager | 0xcDCb65fc657B701a5100a12eFB663978E7e8fFB8 | Existing only | | Metis | RateStrategy | 0x258625AfDe0073f5Bbce50C0305f4C23B16C7F3a | Existing only | | Gnosis Chain | Pool Addresses Provider | 0x36616cf17557639614c1cdDb356b1B83fc0B2132 | Existing Only | | Gnosis Chain | Pool | 0xb50201558B00496A145fE76f7424749556E326D8 | All (all active libraries, and the implementation under proxy) | | Gnosis Chain | Pool Configurator | 0x7304979ec9E4EaA0273b6A037a31c4e9e5A75D16 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Gnosis Chain | Oracle | 0xeb0a051be10228213BAEb449db63719d6742F7c4 | All (all per-asset feeds) | | Gnosis Chain | ACL Manager | 0xEc710f59005f48703908bC519D552Df5B8472614 | Existing only | | Gnosis Chain | Debt Swap Adapter | 0xE28E2c8d240dd5eBd0adcab86fbD79df7a052034 | Existing only | | Gnosis Chain | RepayWithCollateralAdapter | 0x86b0521f92a554057e54B93098BA2A6Aaa2F4ACB | Existing only | | Gnosis Chain | SwapCollateralAdapter | 0x63dfa7c09Dc2Ff4030d6B8Dc2ce6262BF898C8A4 | Existing only | | Gnosis Chain | WETHGateway | 0x721B9abAb6511b46b9ee83A1aba23BDAcB004149 | Existing only | | Gnosis Chain | StataTokenFactory | 0x33992721c565dA3248bd3af80524e054F5F05b42 | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Gnosis Chain | RateStrategy | 0x4cE496f0a390745102540faF041EF92FfD588b44 | Existing only | | ZKSync Era | Pool Addresses Provider | 0x2A3948BB219D6B2Fa83D64100006391a96bE6cb7 | Existing Only | | ZKSync Era | Pool | 0x78e30497a3c7527d953c6B1E3541b021A98Ac43c | All (all active libraries, and the implementation under proxy) | | ZKSync Era | Pool Configurator | 0x0207d31b4377C74bEC37356aaD83E3dCc979F40E | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | ZKSync Era | Oracle | 0xC7F58Fca663a8d377B6D0c9703C697f56dC40088 | All (all per-asset feeds) | | ZKSync Era | ACL Manager | 0xc6150b63c2F02528d4A969a248710A4658ed7928 | Existing only | | ZKSync Era | WETHGateway | 0xAE2b00D676130Bdf22582781BbBA8f4F21e8B0ff | Existing only | | ZKSync Era | RateStrategy | 0x57815Ab06D846d7dECd326Ee541CD06144FED237 | Existing only | | Scroll | Pool Addresses Provider | 0x69850D0B276776781C063771b161bd8894BCdD04 | Existing Only | | Scroll | Pool | 0x11fCfe756c05AD438e312a7fd934381537D3cFfe | All (all active libraries, and the implementation under proxy) | | Scroll | Pool Configurator | 0x32BCab42a2bb5AC577D24b425D46d8b8e0Df9b7f | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Scroll | Oracle | 0x04421D8C506E2fA2371a08EfAaBf791F624054F3 | All (all per-asset feeds) | | Scroll | ACL Manager | 0x7633F981D87dC6307227de9383D2ce7243158081 | Existing only | | Scroll | WETHGateway | 0xE79Ca44408Dae5a57eA2a9594532f1E84d2edAa4 | Existing only | | Scroll | StataTokenFactory | 0x01cfB64B99f717d791260ECb502e675d6E8Cf522 | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Scroll | RateStrategy | 0xC37353E5766164D8654D3CB395acfDcA4c2E7Ddc | Existing only | | Sonic | Pool Addresses Provider | 0x5C2e738F6E27bCE0F7558051Bf90605dD6176900 | Existing Only | | Sonic | Pool | 0x5362dBb1e601abF3a4c14c22ffEdA64042E5eAA3 | All (all active libraries, and the implementation under proxy) | | Sonic | Pool Configurator | 0x50c70FEB95aBC1A92FC30b9aCc41Bd349E5dE2f0 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Sonic | Oracle | 0xD63f7658C66B2934Bd234D79D06aEF5290734B30 | All (all per-asset feeds) | | Sonic | ACL Manager | 0x3a790a47c4d531FD333FAD24f70B0ccb521B3b5A | Existing only | | Sonic | Debt Swap Adapter | 0x2E549104c516b8657A7D888494DfbAbD7C70b464 | Existing only | | Sonic | RepayWithCollateralAdapter | 0x5598BbFA2f4fE8151f45bBA0a3edE1b54B51a0a9 | Existing only | | Sonic | SwapCollateralAdapter | 0x78F8Bd884C3D738B74B420540659c82f392820e0 | Existing only | | Sonic | WETHGateway | 0x061D8e131F26512348ee5FA42e2DF1bA9d6505E9 | Existing only | | Sonic | StataTokenFactory | 0xFeeb6FE430B7523fEF2a38327241eE7153779535 | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Sonic | RateStrategy | 0xdFf435BCcf782f11187D3a4454d96702eD78e092 | Existing only | | | | | | | Soneium | Pool Addresses Provider | 0x82405D1a189bd6cE4667809C35B37fBE136A4c5B | Existing Only | | Soneium | Pool | 0xDd3d7A7d03D9fD9ef45f3E587287922eF65CA38B | All (all active libraries, and the implementation under proxy) | | Soneium | Pool Configurator | 0x1607FCeEc8dEbA4d5Da66D620b2363066d025a02 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Soneium | Oracle | 0x20040a64612555042335926d72B4E5F667a67fA1 | All (all per-asset feeds) | | Soneium | ACL Manager | 0x7635bFF69E52023aB76267ab1EFf63434cdCe458 | Existing only | | Soneium | WETHGateway | 0x6376D4df995f32f308f2d5049a7a320943023232 | Existing only | | Soneium | StataTokenFactory | 0x535b2f7C20B9C83d70e519cf9991578eF9816B7B | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Soneium | RateStrategy | 0x486C2D3F59E4d72f3cAa301a7eF19E3db657F5b0 | Existing only | | Linea | Pool Addresses Provider | 0x89502c3731F69DDC95B65753708A07F8Cd0373F4 | Existing Only | | Linea | Pool | 0xc47b8C00b0f69a36fa203Ffeac0334874574a8Ac | All (all active libraries, and the implementation under proxy) | | Linea | Pool Configurator | 0x812E7c19421D9f41A6DDCF047d5cc2dE2Ca5Bfa2 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Linea | Oracle | 0xCFDAdA7DCd2e785cF706BaDBC2B8Af5084d595e9 | All (all per-asset feeds) | | Linea | ACL Manager | 0xbf32c7dFC72b730967072B112927ca0de205dbb5 | Existing only | | Linea | WETHGateway | 0x31A239f3e39c5D8BA6B201bA81ed584492Ae960F | Existing only | | Linea | StataTokenFactory | 0xc25Da0Ddab750739d2500dfD4E31EB4E83622F54 | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Linea | RateStrategy | 0xB1532b76D054c9F9E61b25c4d91f69B4133E4671 | Existing only | | Celo | Pool Addresses Provider | 0x9F7Cf9417D5251C59fE94fB9147feEe1aAd9Cea5 | Existing Only | | Celo | Pool | 0x3E59A31363E2ad014dcbc521c4a0d5757d9f3402 | All (all active libraries, and the implementation under proxy) | | Celo | Pool Configurator | 0x7567E3434CC1BEf724AB595e6072367Ef4914691 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Celo | Oracle | 0x1e693D088ceFD1E95ba4c4a5F7EeA41a1Ec37e8b | All (all per-asset feeds) | | Celo | ACL Manager | 0x7a12dCfd73C1B4cddf294da4cFce75FcaBBa314C | Existing only | | Celo | StataTokenFactory | 0x2b33073B94243304bCb4dfFA6b624afA5BAA414D | All (stataTokes deployed from the factory, and the implementation of those tokens under proxy) | | Celo | RateStrategy | 0x8B62D241Bf59f40991DCd18531683156d7013355 | Existing only | | Ethereum | stkAAVE | 0x4da27a545c0c5B758a6BA100e3a049001de870f5 | All (proxy and implementation) | | Ethereum | stkABPT | 0xa1116930326D21fB917d5A27F1E9943A9595fb47 | All (proxy and implementation) | | Ethereum | sGHO (legacy) | 0x1a88Df1cFe15Af22B3c4c783D4e6F7F9e0C1885d | All (proxy and implementation) | | Ethereum | GHO token | 0x40D16FC0246aD3160Ccc09B8D0D3A2cD28aE6C2f | Existing only | | Ethereum | GHO CCIP Token Pool | 0x06179f7C1be40863405f374E7f5F8806c728660A | All (proxy and implementation) | | Ethereum | GHO FlashMinter facilitator | 0xb639D208Bcf0589D54FaC24E655C79EC529762B8 | Existing only | | Ethereum | GSM USDC | 0xFeeb6FE430B7523fEF2a38327241eE7153779535 | All (proxy and implementation) | | Ethereum | GSM USDT | 0x535b2f7C20B9C83d70e519cf9991578eF9816B7B | All (proxy and implementation) | | Ethereum | GHO Direct Minter (Core) | 0x593B09afc075B3c326CE2AD7750888645BA8943d | All (proxy and implementation) | | Ethereum | GHO Direct Minter (Prime) | 0x2cE01c87Fec1b71A9041c52CaED46Fc5f4807285 | All (proxy and implementation) | | Base | GHO token | 0x6Bb7a212910682DCFdbd5BCBb3e28FB4E8da10Ee | All (proxy and implementation) | | Base | GHO CCIP Token Pool | 0x98217A06721Ebf727f2C8d9aD7718ec28b7aAe34 | All (proxy and implementation) | | Avalanche | GHO token | 0xfc421aD3C883Bf9E7C4f42dE845C4e4405799e73 | All (proxy and implementation) | | Avalanche | GHO CCIP Token Pool | 0xDe6539018B095353A40753Dc54C91C68c9487D4E | All (proxy and implementation) | | Arbitrum | GHO token | 0x7dfF72693f6A4149b17e7C6314655f6A9F7c8B33 | All (proxy and implementation) | | Arbitrum | GHO CCIP Token Pool | 0xB94Ab28c6869466a46a42abA834ca2B3cECCA5eB | All (proxy and implementation) | | Ethereum | Umbrella core | 0xD400fc38ED4732893174325693a63C30ee3881a8 | All (proxy and implementation, and all stake tokens deployed from it being factory) | | Ethereum | Umbrella RewardsController | 0x4655Ce3D625a63d30bA704087E52B4C31E38188B | All (proxy and implementation) | | Ethereum | PermissionedPayloadsController (rewards) | 0xF86F77F7531B3374274E3f725E0A81D60bC4bB67 | All (proxy and implementation) | | Ethereum | Permissioned Executor (rewards) | 0x2759de67aD133C747C9f41d56F1b8A343cE679a1 | Existing only | | Ethereum | Governance core | 0x9AEE0B04504CeF83A65AC3f0e838D0593BCb2BC7 | All (proxy and implementation, and all voting portals) | | Ethereum | Cross Chain Controller | 0xEd42a7D8559a463722Ca4beD50E0Cc05a386b0e1 | All (proxy and implementation, and all active bridges’ adapters) | | Ethereum | Payloads Controller | 0xdAbad81aF85554E9ae636395611C58F7eC1aAEc5 | All (proxy and implementation) | | Ethereum | Executor lvl1 | 0x5300A1a15135EA4dc7aD5a167152C01EFc9b192A | All (proxy and implementation) | | Ethereum | Executor lvl2 | 0x17Dd33Ed0e3dD2a80E37489B8A63063161BE6957 | All (proxy and implementation) | | Ethereum | Voting Machine | 0x06a1795a88b82700896583e123F46BE43877bFb6 | All (all contract active and connected to it, like the voting strategy or the data warehouse) | | Polygon PoS | Cross Chain Controller | 0xF6B99959F0b5e79E1CC7062E12aF632CEb18eF0d | All (proxy and implementation, and all active bridges’ adapters) | | Polygon PoS | Payloads Controller | 0x401B5D0294E23637c18fcc38b1Bca814CDa2637C | All (proxy and implementation) | | Polygon PoS | Executor lvl1 | 0xDf7d0e6454DB638881302729F5ba99936EaAB233 | All (proxy and implementation) | | Polygon PoS | Voting Machine | 0x44c8b753229006A8047A05b90379A7e92185E97C | All (all contract active and connected to it, like the voting strategy or the data warehouse) | | Avalanche C-Chain | Cross Chain Controller | 0x27FC7D54C893dA63C0AE6d57e1B2B13A70690928 | All (proxy and implementation, and all active bridges’ adapters) | | Avalanche C-Chain | Payloads Controller | 0x1140CB7CAfAcC745771C2Ea31e7B5C653c5d0B80 | All (proxy and implementation) | | Avalanche C-Chain | Executor lvl1 | 0x3C06dce358add17aAf230f2234bCCC4afd50d090 | All (proxy and implementation) | | Avalanche C-Chain | Voting Machine | 0x4D1863d22D0ED8579f8999388BCC833CB057C2d6 | All (all contract active and connected to it, like the voting strategy or the data warehouse) | | Optimism | Cross Chain Controller | 0x48A9FE90bce5EEd790f3F4Ce192d1C0B351fd4Ca | All (proxy and implementation, and all active bridges’ adapters) | | Optimism | Payloads Controller | 0x0E1a3Af1f9cC76A62eD31eDedca291E63632e7c4 | All (proxy and implementation) | | Optimism | Executor lvl1 | 0x746c675dAB49Bcd5BB9Dc85161f2d7Eb435009bf | All (proxy and implementation) | | Arbitrum | Cross Chain Controller | 0xCbFB78a3Eeaa611b826E37c80E4126c8787D29f0 | All (proxy and implementation, and all active bridges’ adapters) | | Arbitrum | Payloads Controller | 0x89644CA1bB8064760312AE4F03ea41b05dA3637C | All (proxy and implementation) | | Arbitrum | Executor lvl1 | 0xFF1137243698CaA18EE364Cc966CF0e02A4e6327 | All (proxy and implementation) | | Base | Cross Chain Controller | 0x529467C76f234F2bD359d7ecF7c660A2846b04e2 | All (proxy and implementation, and all active bridges’ adapters) | | Base | Payloads Controller | 0x2DC219E716793fb4b21548C0f009Ba3Af753ab01 | All (proxy and implementation) | | Base | Executor lvl1 | 0x9390B1735def18560c509E2d0bc090E9d6BA257a | All (proxy and implementation) | | BNB Chain | Cross Chain Controller | 0x9d33ee6543C9b2C8c183b8fb58fB089266cffA19 | All (proxy and implementation, and all active bridges’ adapters) | | BNB Chain | Payloads Controller | 0xE5EF2Dd06755A97e975f7E282f828224F2C3e627 | All (proxy and implementation) | | BNB Chain | Executor lvl1 | 0x9390B1735def18560c509E2d0bc090E9d6BA257a | All (proxy and implementation) | | Metis | Cross Chain Controller | 0x6fDaFb26915ABD6065a1E1501a37Ac438D877f70 | All (proxy and implementation, and all active bridges’ adapters) | | Metis | Payloads Controller | 0x2233F8A66A728FBa6E1dC95570B25360D07D5524 | All (proxy and implementation) | | Metis | Executor lvl1 | 0x6fD45D32375d5aDB8D76275A3932c740F03a8718 | All (proxy and implementation) | | Gnosis | Cross Chain Controller | 0x8Dc5310fc9D3D7D1Bb3D1F686899c8F082316c9F | All (proxy and implementation, and all active bridges’ adapters) | | Gnosis | Payloads Controller | 0x9A1F491B86D09fC1484b5fab10041B189B60756b | All (proxy and implementation) | | Gnosis | Executor lvl1 | 0x1dF462e2712496373A347f8ad10802a5E95f053D | All (proxy and implementation) | | ZKSync Era | Cross Chain Controller | 0x800813f4714BC7A0a95310e3fB9e4f18872CA92C | All (proxy and implementation, and all active bridges’ adapters) | | ZKSync Era | Payloads Controller | 0x2E79349c3F5e4751E87b966812C9E65E805996F1 | All (proxy and implementation) | | ZKSync Era | Executor lvl1 | 0x04cE39789e11a49595cD0ECEf6f4Bd54ABF4d020 | All (proxy and implementation) | | Scroll | Cross Chain Controller | 0x03073D3F4769f6b6604d616238fD6c636C99AD0A | All (proxy and implementation, and all active bridges’ adapters) | | Scroll | Payloads Controller | 0x6b6B41c0f8C223715f712BE83ceC3c37bbfDC3fE | All (proxy and implementation) | | Scroll | Executor lvl1 | 0xc1ABF87FfAdf4908f4eC8dc54A25DCFEabAE4A24 | All (proxy and implementation) | | Sonic | Cross Chain Controller | 0x58e003a3C6f2Aeed6a2a6Bc77B504566523cb15c | All (proxy and implementation, and all active bridges’ adapters) | | Sonic | Payloads Controller | 0x0846C28Dd54DEA4Fd7Fb31bcc5EB81673D68c695 | All (proxy and implementation) | | Sonic | Executor lvl1 | 0x7b62461a3570c6AC8a9f8330421576e417B71EE7 | All (proxy and implementation) | | Soneium | Cross Chain Controller | 0xD92b37a5114b33F668D274Fb48f23b726a854d6E | All (proxy and implementation, and all active bridges’ adapters) | | Soneium | Payloads Controller | 0x44D73D7C4b2f98F426Bf8B5e87628d9eE38ef0Cf | All (proxy and implementation) | | Soneium | Executor lvl1 | 0x47aAdaAE1F05C978E6aBb7568d11B7F6e0FC4d6A | All (proxy and implementation) | | Linea | Cross Chain Controller | 0x0D3f821e9741C8a8Bcac231162320251Db0cdf52 | All (proxy and implementation, and all active bridges’ adapters) | | Linea | Payloads Controller | 0x3BcE23a1363728091bc57A58a226CF2940C2e074 | All (proxy and implementation) | | Linea | Executor lvl1 | 0x8c2d95FE7aeB57b86961F3abB296A54f0ADb7F88 | All (proxy and implementation) | | Celo | Cross Chain Controller | 0x50F4dAA86F3c747ce15C3C38bD0383200B61d6Dd | All (proxy and implementation, and all active bridges’ adapters) | | Celo | Payloads Controller | 0xE48E10834C04E394A04BF22a565D063D40b9FA42 | All (proxy and implementation) | | Celo | Executor lvl1 | 0x1dF462e2712496373A347f8ad10802a5E95f053D | All (proxy and implementation) | | Ethereum | AAVE Ecosystem Reserve | 0x25F2226B597E8F9514B3F68F00f494cF4f286491 | All (proxy and implementation) | | Ethereum | Aave Swapper | 0x3ea64b1C0194524b48F9118462C8E9cd61a243c7 | All (proxy and implementation) | | Ethereum | ProxyAdmin (long) | 0x86C3FfeE349A7cFf7cA88C449717B1b133bfb517 | All (proxy and implementation) | | Ethereum | ProxyAdmin | 0xD3cF979e676265e4f6379749DECe4708B9A22476 | All (proxy and implementation) | | | | | | | Polygon PoS | ProxyAdmin | 0xD3cF979e676265e4f6379749DECe4708B9A22476 | All (proxy and implementation) | | Avalanche C-Chain | ProxyAdmin | 0xD3cF979e676265e4f6379749DECe4708B9A22476 | All (proxy and implementation) | | Optimism | ProxyAdmin | 0xD3cF979e676265e4f6379749DECe4708B9A22476 | All (proxy and implementation) | | Arbitrum | ProxyAdmin | 0xD3cF979e676265e4f6379749DECe4708B9A22476 | All (proxy and implementation) | | Base | ProxyAdmin | 0xc85b1E333aecc99340b2320493Fe2d22b8734795 | All (proxy and implementation) | | BNB Chain | ProxyAdmin | 0x39EBFfc7679c62Dfcc4A3E2c09Bcb0be255Ae63c | All (proxy and implementation) | | Metis | ProxyAdmin | 0x1CabD986cBAbDf12E00128DFf03C80ee62C4fd97 | All (proxy and implementation) | | Gnosis Chain | ProxyAdmin | 0xe892E40C92c2E4D281Be59b2E6300F271d824E75 | All (proxy and implementation) | | ZKSync Era | ProxyAdmin | 0x158d6c497317367CEa3CBAb0BD84E6de236F060D | All (proxy and implementation) | | Scroll | ProxyAdmin | 0x782559e349b084bB7C07c08404aE6E3436cDAE2E | All (proxy and implementation) | | Linea | ProxyAdmin | 0x160E35e28fEE90F3656420584e0a990276219b5A | All (proxy and implementation) | | Celo | ProxyAdmin | 0x54BDcc37c4143f944A3EE51C892a6cBDF305E7a0 | All (proxy and implementation) | | Ethereum | Addresses Provider (v2) | 0xB53C1a33016B2DC2fF3653530bfF1848a515c8c5 | Existing only | | Ethereum | Pool (v2) | 0x7d2768dE32b0b80b7a3454c06BdAc94A69DDc7A9 | All (all active libraries, and the implementation under proxy) | | Ethereum | Pool Configurator (v2) | 0x311Bb771e4F8952E6Da169b425E7e92d6Ac45756 | All (aTokens and vTokens, whose proxy factory is the Pool Configurator on the initial listing. Also the implementation under proxy) | | Ethereum | Oracle (v2) | 0xA50ba011c48153De246E5192C8f9258A2ba79Ca9 | All (all per-asset feeds) | | Ethereum | RepayWithCollateralAdapter (v2) | 0x80Aca0C645fEdABaa20fd2Bf0Daf57885A309FE6 | Existing only | | Ethereum | SwapCollateralAdapter (v2) | 0x135896DE8421be2ec868E0b811006171D9df802A | Existing only | | Ethereum | WETHGateway (v2) | 0xa0d9C1E9E48Ca30c8d8C3B5D69FF5dc1f6DFfC24 | Existing only | “All”: The Safe Harbor Agreement will cover both the subcontracts currently deployed under this contract and any future subcontracts deployed through it. This ensures that all present and future subcontracts are protected. 3. Contact Details: Designated security contact for Aave * Name: BGD Labs 4. Bounty Terms: Predetermined rewards for successful whitehats that protect protocol funds * Bounty Percentage: 10% of recovered funds. * Bounty Cap (USD): $1M * Aggregate Bounty Cap (USD): $1M * Retainable: False 1. This means that whitehats cannot retain their bounty directly from the recovered assets. Instead, all rescued funds must be returned to the protocol’s designated asset recovery address, and the bounty will be paid out separately afterwards. * Identity Verification: Named 1. Whitehats may need to provide their full legal name. This requirement ensures compliance with legal obligations and is similar to the identity verification standards seen in traditional bug bounty programs. * Diligence Requirements: KYC & Global Sanction Verification 1. Aave may require all eligible whitehats to undergo Know Your Customer (KYC) verification and be screened against global sanctions lists, including OFAC, UK, and EU regulations. This process ensures that all bounty recipients are compliant with legal and regulatory standards before qualifying for payment. 2. In line with the ethos of Safe Harbor and Aave’s existing bug bounty practices, the DAO will avoid requesting KYC whenever possible to respect the anonymity of whitehats. However, KYC may still be required if deemed necessary during the due diligence process following an incident - for example, to validate eligibility for a reward or confirm compliance with legal obligations. If requested, this process will be completed within the 15-day post-incident review period. 3. Safe Harbor and the Aave Bug Bounty program are completely separate but mutually exclusive from a rewards perspective. A whitehat rewarded via the Bug Bounty program cannot receive a reward for the same exploit under Safe Harbor, even if Safe Harbor’s legal protections apply. Note: The reward payment will be made from the funds of the Aave DAO treasury, not anyhow from from the rescued funds, which belong to the protocol’s users, not the DAO Note: Reward denomination (stablecoins or other tokens) are sole discretion of the Aave DAO via the security coordinator, and following recommendations by treasury contributors. If the payment is partially or done in volatile assets (e.g., ETH or AAVE), the 30-day average price from the moment of the incident will be taken as reference. --- Implementation Plan 1. Register Agreement On-Chain: * The agreement will be registered on Ethereum in the Safe Harbor Registry at address 0x1eaCD100B0546E433fbf4d773109cAD482c34686, including all adoptionDetails. This ensures transparency and immutability. 3. Future Updates to Scope: * New versions of Aave will be reviewed and added to the Safe Harbor Agreement scope via Aave Governance vote, ensuring continued protection for all new contracts and functionalities.

[ARFC] Deploy Aave v3 on Plasma Author: ACI Date: 2025-03-15 Proposal has been updated with latest Risk Parameters 2025-09-05 --- Simple Summary This ARFC proposes the deployment of an Aave V3 Instance on Plasma. Motivation Plasma is a high-performance, scalable, and secure blockchain purpose-built for stablecoins. Built from the ground up, it delivers zero fees, lightning-fast transactions, and the robust security that stablecoins like USD₮ require. The network offers a performant location to the deploy the Aave protocol, and the Plasma team are planning to support Aave’s launch on the network. Specification Risk Parameters will be provided by Risk Service Providers during the ARFC stage and ARFC will be updated accordingly. Proposal has been updated with latest Risk Parameters 2025-09-05 Specification | Parameter | Value | Value | Value | Value | Value | Value | Value | | --- | --- | --- | --- | --- | --- | --- | --- | | Asset | USD₮ | USDe | sUSDe | XAUt | WETH | weETH | XPL | | Isolation Mode | No | No | No | Yes | No | No | No | | Borrowable | Yes | Yes | No | No | Yes | No | No | | Collateral Enabled | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | Supply Cap | 2,200,000,000 | 500,000,000 | 450,000,000 | 7,000 | 80,000 | 10,000 | 50,000,000 | | Borrow Cap | 2,000,000,000 | 50,000,000 | - | - | 10,000 | - | - | | Debt Ceiling | - | - | - | - | - | - | - | | LTV | 75% | 72% | 0.05% | 70% | 80.5% | 0.05% | 0.00% | | LT | 78% | 75% | 0.1% | 75% | 83% | 0.1% | 0.1% | | Liquidation Bonus | 4.50% | 8.50% | 8.50% | 7.50% | 5.5% | 7% | 8% | | Liquidation Protocol Fee | 10% | 10% | 10% | 10% | 10% | 10% | 10% | | Variable Base | 2.5% | 2.5% | - | - | 0% | - | - | | Variable Slope1 | 4.0% | 5.0% | - | - | 2.7% | - | - | | Variable Slope2 | 20% | 50% | - | - | 20% | - | - | | Uoptimal | 92% | 85% | - | - | 92% | - | - | | Reserve Factor | 10% | 25% | - | - | 15% | - | - | USDe Stablecoin E-Mode | Parameter | Value | Value | | --- | --- | --- | | Asset | USDe | USD₮ | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 90% | - | | Liquidation Threshold | 93% | - | | Liquidation Bonus | 2.0% | - | sUSDe Stablecoin E-Mode | Parameter | Value | Value | Value | | --- | --- | --- | --- | | Asset | USDe | sUSDe | USD₮ | | Collateral | Yes | Yes | No | | Borrowable | No | No | Yes | | Max LTV | 90% | 90% | - | | Liquidation Threshold | 92% | 92% | - | | Liquidation Bonus | 4.0% | 4.0% | - | weETH WETH E-Mode | Parameter | Value | Value | | --- | --- | --- | | Asset | weETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93% | - | | Liquidation Threshold | 95% | - | | Liquidation Bonus | 1.00% | - | CAPO Parameters sUSDe | Token | Snapshot Delay | maxYearlyGrowthRatio | | --- | --- | --- | | sUSDe | 14 days | 15.19% | POL and Incentives Upon confirmation of the Aave deployment on Plasma, the Plasma Foundation will: Supply 10M USDT Ensure that in any future incentive campaign, Aave is the only lending protocol receiving incentive distributions. Integrate and boost adoption of the GHO stablecoin within its ecosystem, targeting real-world and institutional use cases. Collaborate with liquidity providers, institutional capital allocators, and partners to expand supply in Aave v3 for BTC and USDT. Offer Aave DAO or ACI an opportunity to serve as an early validator, thereby securing the Plasma Bitcoin bridge and participating in consensus. Have Aave DAO redistribute any airdrops or incentive distributions from the Plasma ecosystem to protocol users through liquidity mining. Entrust ACI, on behalf of Aave DAO, to manage any liquidity mining campaign on a Plasma Aave V3 deployment. Useful Links Website: https://www.plasma.to/ Docs: https://docs.plasma.to/ Disclaimer This proposal is powered by Skywards. ACI is not directly affiliated with Plasma and did not receive compensation 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 under CC0.

[TEMP CHECK] Onboard USDG to Aave V3 Core Instance Author: ACI Date: 2025-08-25 Summary We propose the onboarding of USDG, a USD-backed stablecoin issued by Paxos, on Aave V3 Core Instance. This listing would initially enable users to deposit USDG to earn yield and borrow USDG as a stable asset. Collateral usage will be considered at a later date following review by Aave's Risk Management teams. Motivation USDG is a regulated stablecoin backed 1:1 by cash and short-term U.S. Treasuries, designed with regulatory compliance and transparency as core principles. As a trusted stablecoin from Paxos, a regulated financial institution with a strong track record, USDG has gained significant adoption across various platforms, demonstrating market confidence and growing utility. Key differentiators: 1. Global Dollar (USDG) is issued by Paxos Digital Singapore, which is a Major Payments Institution supervised by the Monetary Authority of Singapore. USDG is issued in the EU by Paxos Issuance Europe Oy (PIE), an Electronic Money Institution regulated by the Finnish Financial Supervisory Authority (FIN-FSA). USDG is fully compliant with the EU’s Markets in Crypto Assets Regulation (MiCA). 2. Transparency: Regular attestations verify USDG's reserves are fully backed by cash and short-term U.S. Treasuries. 3. Chainlink price feed: Live and available for use in Aave integrations. Specification Risk Parameters will be provided by Risk Service Providers and proposal will be updated accordingly. USDG Overview: Ticker: USDG Fiat backed stablecoin Issuer: Paxos Backing assets: USD cash and short-term U.S treasuries. Audits: Multiple third-party audits Price Oracle: Chainlink USDG Listed on: Major centralized and decentralized exchanges. Use Cases: 1. Deposits enabled for yield generation 2. Borrowing enabled as a low-volatility asset Incentives: Paxos is considering incentive programs to boost adoption and enhance the competitiveness of USDG borrowing rates compared to other stablecoin assets on Aave. Detailed incentive structures will be shared with Aave DAO contributors and the community in the ARFC stage. Disclosure The current proposal has been powered by Skywards. ACI is not affiliated with Paxos and has not received compensation for the creation and review of this proposal. Next Steps 1. Publication of TEMP CHECK to gather community & service providers feedback, and escalate to TEMP CHECK Snapshot. 2. Publication of a standard ARFC, if TEMP CHECK Snapshot passed, to continue collecting community & service provider feedback before escalating proposal to ARFC snapshot stage. 3. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via CC0

Summary This publication presents the next round of parameter updates to be implemented as we work towards deprecating v2 instances of Aave Protocol across Polygon, Ethereum and Avalanche. Motivation This publication builds on previous efforts that froze both Polygon v2 and Avalanche v2, to support the deprecation of Aave v2, ensuring a smooth, controlled, and secure transition to Aave v3. The proposed changes are designed to increase borrowing costs through adjustments to the interest rate curve parameters, providing users with stronger economic incentives to migrate to Aave v3. Where practical, a standardized approach of reducing the Uoptimal parameter has been applied, alongside adjustments to the Base and Slope1 parameters to raise borrow rates. At the same time, the Slope2 parameter has been reduced to prevent excessive borrowing costs. Overall, a higher borrow rate will result without exposing users to extreme borrow costs at near full utilisation of the liquidity in each reserve. The updated Uoptimtal parameter exceeds the utilisation of each reserve and over time is expected to be progressively lowered towards a 25% target. For commonly borrowed assets the Base parameter is increased to 5% with further increases planned as the liquidity in the Reserves decreases. Over time the Base parameter will be increased gradually to ensure a minimum borrow rate is always maintained. The Reserve Factor is increased to 85% resulting in a reduced deposit rate that discourage depositing idle capital into v2. These changes represent a coordinated effort among several service providers to align incentives and ensure the long-term health of the Aave ecosystem. Specification The following parameters are to be updated. | Ethereum v2 |RF Current|RF Proposed|Base Current|Base Proposed|Uoptimal Current|Uoptimal Proposed|Slope1 Current|Slope1 Proposed|Slope2 Current|Slope2 Proposed| | ----------- | :------: | :-------: | :-------: | :------: | :-------: | :------: | :-----: | :-----:| :-----: | :-----:| | wETH | 85.00% | 85.00% | 00.00% | 5.00% | 80.00% | 25.00% | 3.80% | 5.00% | 80.00% | 40.00% | | wBTC | 90.00% | 90.00% | 00.00% | 20.00% | 65.00% | 25.00% | 00.00% | 00.00% |300.00% | 40.00% | | USDC | 70.00% | 85.00% | 00.00% | 5.00% | 90.00% | 60.00% | 12.50% | 12.50% | 60.00% | 40.00% | | USDT | 70.00% | 85.00% | 00.00% | 5.00% | 80.00% | 40.00% | 12.50% | 12.50% | 60.00% | 40.00% | | DAI | 70.00% | 85.00% | 00.00% | 5.00% | 80.00% | 50.00% | 12.50% | 12.50% | 60.00% | 40.00% | | Polygon v2 |RF Current|RF Proposed|Base Current|Base Proposed|Uoptimal Current|Uoptimal Proposed|Slope1 Current|Slope1 Proposed|Slope2 Current|Slope2 Proposed| | ----------- | :------: | :-------: | :-------: | :------: | :-------: | :------: | :-----: | :----: | :-----: | :-----:| | wETH | 99.99% | 99.99% | 00.00% | 5.00% | 40.00% | 25.00% | 10.00% | 15.00% |134.00% | 40.00% | | wBTC | 99.99% | 99.99% | 00.00% | 20.00% | 37.00% | 25.00% | 00.00% | 00.00% |134.00% | 40.00% | | USDC.e | 99.99% | 99.99% | 00.00% | 5.00% | 77.00% | 65.00% | 15.00% | 15.00% |134.00% | 40.00% | | DAI | 99.99% | 99.99% | 00.00% | 5.00% | 71.00% | 45.00% | 15.00% | 15.00% |134.00% | 40.00% | | USDT | 99.99% | 99.99% | 00.00% | 5.00% | 52.00% | 35.00% | 15.00% | 15.00% |134.00% | 40.00% | | POL | 99.99% | 99.99% | 00.00% | 5.00% | 48.00% | 25.00% | 12.00% | 15.00% |134.00% | 40.00% | | Avalanche v2 |RF Current|RF Proposed|Base Current|Base Proposed|Uoptimal Current|Uoptimal Proposed|Slope1 Current|Slope1 Proposed|Slope2 Current|Slope2 Proposed| | ----------- | :------: | :-------: | :------: | :-------: | :-------: | :------: |:------: | :----: | :-----: | :-----:| | wBTC.e | 99.99% | 99.99% | 20.00% | 20.00% | 45.00% | 25.00% | 0.00% | 0.00% |300.00% | 40.00% | | wETH | 80.00% | 85.00% | 0.00% | 5.00% | 45.00% | 25.00% | 10.00% | 15.00% |300.00% | 40.00% | | USDC.e | 80.00% | 85.00% | 0.00% | 5.00% | 80.00% | 25.00% | 0.00% | 0.00% | 75.00% | 40.00% | | AVAX | 80.00% | 85.00% | 0.00% | 5.00% | 45.00% | 25.00% | 5.00% | 15.00% |300.00% | 40.00% | | USDT.e | 80.00% | 85.00% | 0.00% | 5.00% | 80.00% | 45.00% | 9.00% | 15.00% | 75.00% | 40.00% | | DAI | 80.00% | 85.00% | 0.00% | 5.00% | 80.00% | 80.00% | 9.00% | 15.00% | 75.00% | 40.00% | Disclosure TokenLogic does not receive any payment for this proposal. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

Summary This publication proposes including Fluid Protocol on the Aave v3 Flashborrowers whitelist for Polygon and Avalanche. Motivation Fluid has been a long-standing partner in the Aave ecosystem, providing valuable infrastructure and user interfaces. After the recent tokenswap proposal, the Fluid and TokenLogic teams have been able to grow GHO to 80M in user deposits. This publication extends the flashloan fee waiver to include recent Fluid deployments on Avalanche and Polygon. Further details about Fluid Protocol: https://fluid.io/ Specification Whitelist Fluid Protocol as part of FlashBorrowers of Aave v3 on Polygon & Avalanche liquidity pools. 0x352423e2fA5D5c99343d371C9e3bC56C87723Cc7 This proposal aims to implement a single AIP, utilising two similar payloads (one for each network), which will call addFlashBorrower() on the ACL_MANAGER contract. The AIP when implemented grants permission to whitelist any Fluid Protocol contract for all use cases, such as leveraged positions, eMode, debt and collateral swaps, with one exception: no smart-contract that migrates a position outside of the Aave ecosystem is eligible for whitelisting. Next Steps 1. Using the Direct-to-AIP process, submit a proposal for vote. Disclaimer TokenLogic is not associated with or compensated by Fluid Protocol for publishing this proposal. Copyright Copyright and related rights waived under Creative Commons Zero CC0.

Simple summary Propose to the community further non-invasive deprecation steps on the technical side, by setting the CF (Close Factor) to 100% allowing smoother liquidations, cleaning bad debt via a new ClinicSteward adapted for v2, and minor code adjustments. --- Context After years of v2 being in a deprecated stage, with the majority (or all) of the assets on Ethereum/Polygon/Avalanche being frozen or disabled for borrowing, we believe it is necessary to continue with progressive deprecation steps for the system. Given that the pools are still relatively big (especially v2 Ethereum with approximately $300m in size), this phase is still not invasive to users, mainly focused on making smoother liquidations, for the DAO to be able to clean up all historic bad debt without systemically leaving dust. This proposal is, even if independent, complementary to this other by @TokenLogic and the risk providers. --- Specification The proposal will execute the following two steps on each network: 1. Replace the LendingPoolCollateralManager with a version implementing 100% CF (Close Factor). For clarity, this means that whenever a position is eligible for liquidation (when reaching 1 HF), the liquidator will be able to close 100% of the position, instead of 50% if over the Close Factor threshold. 2. Grant FUNDS_MANAGER role from the Collector to a ClinicStewardV2 smart contract, an adapted version of the one done HERE for Aave v3, for the DAO to clean up historic v2 bad debt with Collector’s funds. Additional details on its configuration: - The final budgets per asset (existing bad debt) will be defined later in this thread, before the AIP stage. To be confirmed by Chaos Labs as a risk provider. - The roles configuration of the steward will be the same as on v3’s: 2-of-3 for the superadmin (to not be really used), in this case, replacing kpk by one of the other risk providers. And a Dolce Vita EOA for the cleanup role, totally constrained by pre-defined budgets and on-chain logic. 3. Do very minor changes to the precision of the system to have more compatibility with v3. On the security side, the different components are to be reviewed by Certora. --- Next steps If this ARFC Snapshot is positive, proceed to AIP on-chain.

Summary This ARFC proposes deploying GHO on the Plasma blockchain and appointing ACI as the Emissions Manager for both GHO and aGHO. The goal is to establish GHO as a key stablecoin within Plasma’s ecosystem from inception, facilitating reward programs, liquidity incentives, and seamless integration with the upcoming Aave deployment on Plasma. Motivation Plasma is a purpose-built, EVM-compatible Bitcoin sidechain designed specifically for stablecoin scalability, speed, and security—offering zero-fee USDT transfers, lightning-fast finality, and Bitcoin-anchored settlement. The network is quickly approahcing launch with substantial USDT liquidity and an institutional partnership with Aave, including active GHO support on the platform. Deploying GHO concurrently with the Aave instance on Plasma ensures that GHO becomes foundational to DeFi and payments infrastructure on a chain optimized for stablecoin utility. Specification Roles and Responsibilities | Service Provider | Responsibility | |----------------------------|-----------------------------------------------------| | TokenLogic | Deploy GHO infrastructure and bridging components | | TokenLogic | Configure Facilitator, GSM, and Steward logistics | | Chaos Labs + LlamaRisk | Review initial risk parameters tailored to Plasma | | BGD + Aave Labs | Review Pull Requests ahead of voting submission | | Certora | Cold Review / Audit of Pull Requests | | ACI + TokenLogic | Design incentives and distribute emissions | | Aave Liquidity Committee | Coordinate GHO liquidity across Plasma DEXs | | GHO Stewards | Maintain risk parameters post-deployment | ACI Multi-sig Address: 0xac140648435d03f784879cd789130F22Ef588Fcd Gho Stewards Address: 0x8513e6F37dBc52De87b166980Fa3F50639694B60 GHO Parameters for Aave v3 on Plasma | Parameter | Value | |-----------------------|--------------| | Asset | GHO | | Market | Plasma | | Isolation Mode | No | | Borrowable | Yes | | Collateral Enabled | No | | Supply Cap | 5,000,000 | | Borrow Cap | 4,500,000 | | Debt Ceiling | – | | LTV | – | | Liquidation Bonus | – | | Variable Base | 0% | | Variable Slope1 | 6.5% | | Variable Slope2 | 50% | | Uoptimal | 90% | | Reserve Factor | 10% | | Stable Borrowing | Disabled | | Flashloanable | Yes | | Siloed Borrowing | No | Facilitator & Bridging Configuration Deploy a GhoDirectMinter facilitator on Ethereum to enable GHO issuance for Plasma. Mint Cap: 15M GHO CCIP Bridge Configuration: Bucket Capacity: 15M GHO Inbound Capacity: 1.5M GHO Outbound Capacity: 1.5M GHO Refill Rate: 300 GHO/sec GSM Parameters (stataUSDT0.plasma) | Parameter | Value | |-------------------------|----------| | GHO Bucket Cap | 10M GHO | | USDT Exposure Cap | 5M | | Freeze Lower Bound | $0.990 | | Freeze Upper Bound | $1.010 | | Unfreeze Lower Bound | $0.995 | | Unfreeze Upper Bound | $1.005 | | Mint GHO Fee | 0% | | Burn GHO Fee | 0% | USDT deposits into stataUSDT0.plasma trigger GHO transfers using Ethereum-held inventory via GSM. GHO Steward Configuration GhoAaveSteward updateGhoBorrowCap: ±100% updateGhoBorrowRate: ±5% on optimal usage ratio, base variable rates, slopes updateGhoSupplyCap: Up to +100% GhoGsmSteward updateGsmExposureCap: ±100% updateGsmBuySellFees: ±0.5% per side (FixedFeeStrategy) Both stewards remain callable only by the GHO steward protocol. Budget Bootstrap funding on Ethereum will be bridged to Plasma via the facilitator for initial liquidity and ecosystem stimulation. The exact Ethereum SAFE address will be defined in a follow-up AIP. Disclaimer TokenLogic receives no compensation for drafting or coordinating this ARFC. 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.

Summary This publication proposes deploying GHO on the Linea blockchain and appointing ACI as the Emissions Manager for both GHO and aGHO. The goal is to position GHO as the dominating decentralized stablecoin within Linea’s ecosystem. Motivation Linea is a high-performance, EVM-equivalent zk-rollup developed by ConsenSys, offering ultra-low fees, fast finality, and deep integration with Ethereum infrastructure such as Infura and MetaMask. Aave V3 has already launched on Linea, enabling increased DeFi adoption and liquidity flow. Linea is now launching Native Yield, an innovative mechanism that auto-stakes bridged ETH via Lido v3 stVaults, channeling staking rewards into DeFi liquidity incentives on Linea. Deploying GHO on Linea in concert with these momentum initiatives ensures GHO becomes a foundational stablecoin, enabling synergies with liquidity programs, boosting peg stability, and expanding GHO’s on-chain utility. Specification Roles and Responsibilities | Service Provider | Responsibility | |----------------------------|-----------------------------------------------------| | TokenLogic | Deploy GHO infrastructure and bridging components | | TokenLogic | Configure Facilitator, GSM, and Steward logistics | | Chaos Labs + LlamaRisk | Review initial risk parameters tailored to Linea | | BGD + Aave Labs | Review Pull Requests ahead of voting submission | | Certora | Cold Review / Audit of Pull Requests | | ACI + TokenLogic | Design incentives and distribute emissions | | Aave Liquidity Committee | Coordinate GHO liquidity across Linea DEXs | | GHO Stewards | Maintain risk parameters post-deployment | ACI Multi-sig Address: 0xac140648435d03f784879cd789130F22Ef588Fcd Gho Stewards Address: 0x8513e6F37dBc52De87b166980Fa3F50639694B60 --- GHO Parameters for Aave v3 on Linea | Parameter | Value | |----------------------|--------------| | Asset | GHO | | Market | Linea | | Isolation Mode | No | | Borrowable | Yes | | Collateral Enabled | No | | Supply Cap | 5,000,000 | | Borrow Cap | 4,500,000 | | Variable Base | 0% | | Variable Slope1 | 5.5% | | Variable Slope2 | 50% | | Uoptimal | 90% | | Reserve Factor | 10% | | Stable Borrowing | Disabled | | Flashloanable | Yes | | Siloed Borrowing | No | --- Facilitator & Bridging Configuration Deploy a GhoDirectMinter facilitator on Ethereum to support issuance for Linea. Mint Cap: 15M GHO Bridge Configuration (e.g., via CCIP or similar): Bucket Capacity: 15M GHO Inbound Capacity: 1.5M GHO Outbound Capacity: 1.5M GHO Refill Rate: 300 GHO/sec --- GSM Parameters (stataUSDT0.linea) | Parameter | Value | |-------------------------|-----------| | GHO Bucket Cap | 10M GHO | | USDT Exposure Cap | 5M | | Freeze Lower Bound | $0.990 | | Freeze Upper Bound | $1.010 | | Unfreeze Lower Bound | $0.995 | | Unfreeze Upper Bound | $1.005 | | Mint GHO Fee | 0% | | Burn GHO Fee | 0% | USDT deposits into stataUSDT0.linea trigger GHO transfers using Ethereum-held inventory via GSM. --- GHO Steward Configuration GhoAaveSteward updateGhoBorrowCap: ±100% updateGhoBorrowRate: ±5% on optimalUsageRatio, baseVariableBorrowRate, variableRateSlope1, variableRateSlope2 updateGhoSupplyCap: Up to +100% GhoGsmSteward updateGsmExposureCap: ±100% updateGsmBuySellFees: ±0.5% per side (FixedFeeStrategy) Both stewards remain callable only by the GHO steward protocol. --- Budget Initial capital will be deployed on Ethereum and bridged to Linea via the facilitator to support liquidity and incentive programs. Exact SAFE address to be specified in an upcoming AIP. Disclaimer TokenLogic receives no compensation for drafting or coordinating this ARFC. 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.

Summary The proposal aims to onboard MetaMask mUSD stablecoin to the Aave v3 Core Instance on Ethereum and Linea. Motivation MetaMask USD (mUSD) is designed to act as connective tissue across MetaMask - making it easier to ramp, swap, bridge, and spend in one seamless flow. Upcoming integrations will extend that foundation, with greater composability across MetaMask products. Aligning with Aave DAO’s commitment to offering diversification across widely held and in-demand assets, onboarding MetaMask USD mUSD will enable users to leverage MetaMask’s liquidity and reputation while benefiting from Aave’s established lending and borrowing functionalities. The initial launch of mUSD is expected to benefit from a major integration like Aave Protocol and attract more mainstream users, contributing to the growth and adoption of the platform. Specification Contract addresses will be added once mUSD is fully launched. - Risk parameters will be provided by Risk Service Providers as soon as possible, and the ARFC will be updated with that feedback. Disclosure TokenLogic is not directly affiliated with MetaMask and did not receive compensation for creating this proposal. Next Steps 1. If consensus is reached on this [TEMP CHECK], escalate the proposal to the Snapshot stage. 2. If the Snapshot outcome is YAE, escalate the proposal to the ARFC stage.3. Publish a standard ARFC and collect community & service provider feedback before escalating 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. Copyright Copyright and related rights waived via CC0.

Motivation and Context DeFi lending markets today share two fundamental vulnerabilities: large, discrete supplier exits and hyper-elastic, thin-margin borrower demand fueled by extensive rehypothecation. While these characteristics are common across pools, their combined impact is magnified significantly in whale-dominated and leverage-heavy environments such as ETH, USDT, and USDe. Under the current piecewise-linear interest rate regime, designed primarily as an ex-post compensation mechanism for suppliers, a sudden large withdrawal causes utilization, defined as borrowed capital B divided by total supplied liquidity S, to spike abruptly toward full utilization. The resultant APR spike theoretically rewards the remaining suppliers and deters full utilization. In practice, however, it often exacerbates the very liquidity stress it aims to prevent, triggering runaway borrower deleveraging and prolonged liquidity locks. These dynamics can generate severe downstream effects, such as instability in Liquid Staking Tokens (LSTs) and Liquid Restaking Tokens (LRTs), significant stress on stablecoin pegs or redemptions, and ultimately measurable bad-debt risks on the protocol’s balance sheet. The proposed mechanism aims explicitly to neutralize these pathological feedback loops by introducing a time-aware, convex, and bounded interest-rate response, aligning economic incentives in a more robust and predictable manner. Large Supplier Withdrawals: A Primary Shock Vector Empirically, the most destabilizing liquidity shocks are not gradual but instantaneous. DAO treasuries, structured products, or whale LPs withdrawing nine- to ten-figure amounts in single-block transactions create immediate and dramatic liquidity shortfalls. This discrete supply reduction causes the utilization ratio to surge abruptly, triggering rapid APR escalations designed to compensate suppliers and attract fresh liquidity. However, this “supplier-compensation / borrower-disincentive spike” overlooks a core dynamic: the temporal and directional misalignment between supply and demand responses. Elevated APRs may eventually draw in new deposits, but this inflow rarely matches the immediacy of the shock. Meanwhile, the same rate spike acts instantly on borrowers, prompting position unwinds or migration to cheaper venues. In other words, the mechanism compresses supply recovery into a slow path while accelerating demand contraction, worsening liquidity precisely when it is most fragile. Thin Borrower Margins and Hyper-Elastic Demand Response This structural issue is amplified by borrower elasticity. Loopers engaging in leveraged carry strategies, particularly prevalent in LST/LRT markets, run at leverage levels of 5–10×, with tail cases exceeding 20×. For these participants, carry margins are razor-thin, often on the order of 20–80 basis points. Even small incremental changes in borrowing APR, in the range of 20–50 basis points, can swiftly render these strategies unprofitable, flipping the economic incentive from positive to negative. The implications of such an outcome can be observed in the following heatmap, whereby jumps in ETH interest rates ultimately result in significant losses and even hypothetical liquidations stemming from interest accrual (the plot depicts a 15x levered position). As soon as looped positions become unprofitable, each additional minute compounds losses, prompting borrowers to rapidly unwind positions. !1.png Thus, as observed in the chart below, large supplier withdrawals that trigger sharp borrow rate spikes tend not to attract immediate new deposits. Instead, they prompt borrower debt repayments, causing both supply and borrow balances to contract. This synchronized shrinkage amplifies liquidity stress, with second-order effects such as intensified LST and LRT peg pressure and longer delays in the Ethereum exit queue. In parallel with the significant LST and LRT-collateralized stablecoin debt, under the assumption that such an event coincides with a drop in ETH price, can lead to difficulty in offloading such debt positions due to a combination of illiquidity and mispriced collateral eating into the liquidation bonus. !2.png Whale-driven Dynamics and Amplified Risks: USDT and Ethena These risks become particularly acute in stablecoin markets like USDT due to significant supplier concentration. For instance, the aUSDT pool is dominated by a small set of super-large entities, including wallets controlled by Justin Sun holding approximately 3.7B aUSDT (45 % of the pool), Ethena hedge wallets holding around 15%, and Plasma pre-deposit vaults holding another 6%. Such extreme concentration means a single whale exit can instantaneously spike utilization, causing drastic rate increases. In markets with highly concentrated supply, a large depositor can partially withdraw to shrink the denominator, pushing utilization into the steep segment of the rate curve and triggering a sharp, temporary spike in interest rates. By timing such withdrawals, the depositor can keep a smaller residual position that benefits from the elevated rate while freeing capital for other uses, until the market re-equilibrates. Ethena-denominated strategies compound this further. Ethena-related collateral assets maintain approximately $6B in yield-sensitive looped positions, whose profitability can flip negative under relatively minor rate spikes. In parallel, as a portion of USDe’s USDC and USDT-denominated backing is deposited in Aave aTokens, Ethena’s internal risk framework can stipulate a withdrawal if liquidity shrinks below roughly 1.25× their outstanding hedge exposure, accelerating deleveraging precisely at the peak of liquidity stress. This self-reinforcing cycle can rapidly deteriorate liquidity conditions, causing extended periods of elevated interest rates and widespread instability. Reflexivity in USDe/sUSDe Markets: Leveraged Supply Meets Leveraged Demand Similar dynamics are amplified even further in the USDe market due to dual-sided leverage. Liquid Leverage users, consisting of a 50-50 USDe-sUSDe position, generate the full yield of sUSDe while simultaneously rehypothecating base USDe back into lending pools (thereby generating interest). On the flip side, Ethena-denominated PTs leverage the underlying USDe debt to create recursive looping positions to lever into yields and points. As derived via our PT risk oracle, this enables superior capital efficiency and more lenient risk parameterization compared to USDC and USDT as debt assets, as the PTs share the same underlying anchor (USDe), thereby neutralizing fundamental losses in the underlying valuation relative to the debt. When external yields compress (e.g., sUSDe falls), contraction can initially commence on the USDe supply side, which is posted as collateral to borrow USDT/USDC for looping. As these suppliers unwind, USDe collateral exits, utilization jumps, and borrower costs spike, even if the borrow side remains sticky; PT-collateralized USDe debt rotation into USDT/USDC can follow, but it’s a second-order response to the initial supply withdrawal. (Importantly, in the current iteration of Liquid Leverage, the combination of USDe supplier yield coupled with sUSDe staking yield makes it such that the downside elasticity during sUSDe rate contractions is minimized due to net profitability relative to stablecoin borrow rates via PT borrowing demand generating significant interest) As outlined rigorously in the research paper "Aave’s Growing Exposure to Ethena: Risk Implications Throughout the Growth and Contraction Cycles of USDe", such events can lead to substantial interest rate spikes and temporary net looping unprofitability. Effective market stabilization in these scenarios demands active management, leaving slower-acting participants disproportionately harmed due to compounding interest losses over relatively short timeframes. Conversely, when PT demand surges after a cap increase, rate-agnostic participants will intentionally push USDe borrow rates sharply higher for a short window, expecting external users to close USDe debt or migrate liabilities to USDT/USDC. The result is a deliberate, temporary rate shock that redistributes liquidity but imposes acute costs on slower movers through rapid interest accrual. A Risk Oracle that Stages the Response To address these amplified risks systematically, the proposed solution employs a risk oracle designed explicitly around three clearly defined phases, providing a structured, time-aware escalation and recovery path. Instead of one abrupt spike: 1. Initial “Grace” Phase: When utilization crosses the kink, the interest rate increases gradually via a parameterized slope above the kink ($s_2$) in accordance with a minimum viable deterrent. This gentle escalation signals borrowers to unwind positions orderly without inducing panic or simultaneous exits. 2. Escalation Phase: If utilization remains high, slope growth compounds multiplicatively and exponentially. The longer the stress persists, the more expensive it becomes to stay levered. This aligns the mechanism’s “pressure curve” with the borrowers’ own convex cost sensitivity, forcing early deleveraging before liquidity is fully locked. 3. Decay Phase: Once utilization falls below the kink, the elevated slope decays exponentially on a predictable half-life. Borrowers who remain can re-enter at lower rates without facing a sharp reset. Governance does not need to flip switches; decay is automatic. By embedding a bounded but strictly convex response, this mechanism directly addresses the core solvency risk of prolonged liquidity lockups while preserving fairness for borrowers and safeguarding suppliers through an explicit probabilistic solvency constraint. Synthesizing the Integrated Rationale In summary, the necessity of a time-aware, bounded, and convex interest-rate response emerges clearly across all considered lending markets: ETH: Addressing one-sided borrower elasticity amidst sudden large supplier withdrawals. USDT: Mitigating dual-sided reflexivity driven by whale concentration and leveraged hedging exposure, while simultaneously affecting a plethora of yield-generating strategies. USDe: Neutralizing recursive liquidity spirals created by dual-sided leveraged exposure, collateral-debt rotations, and compounded yield sensitivity. Ultimately, the proposed solution explicitly aligns economic incentives across time and risk dimensions, ensuring market stability, predictable deleveraging paths, and rigorous supplier solvency guarantees across all structurally vulnerable pools. Design Goals Engineering an interest-rate mechanism for a highly leveraged DeFi market is fundamentally a problem of shaping dynamic incentives under stress. The curve must (i) induce timely borrower deleveraging before liquidity is exhausted, (ii) guarantee a hard solvency standard for suppliers, and (iii) expose only a minimal, transparent parameter surface to governance. The five goals below articulate these requirements in a formally stated, internally consistent manner. Convexity Under Stress: Escalating Marginal Penalties Requirement. For all $u>u_k$, the incremental cost of remaining levered must increase monotonically with both the magnitude of excess utilization and the duration spent above the kink. In discrete time, this is implemented by a multiplicatively compounding post-kink slope such that the effective marginal APR for “one more minute” is strictly larger than for the previous minute, holding u fixed. Rationale. Prolonged high utilization creates a negative externality: liquidity is rationed and liquidation pathways degrade. A convex penalty schedule internalizes this externality by making delay increasingly expensive, thus shifting individual best responses toward early deleveraging and reducing the expected residence time near full utilization. Boundedness: Hard Caps, Credible Floors Requirement. The borrowing rate must be bounded within $\[r\{\\min}, r\{\\max}\]$ with ⁡$r\{\\max}$ chosen as a “pain ceiling” (e.g., 80 % APR) and $r\{\\min}$ strictly above the relevant risk-free/staking yield. These bounds are enforced mechanically, not heuristically. Rationale. Above a certain level, further APR increases do not materially accelerate deleveraging but do induce panic, strategic default, or governance intervention. Conversely, a non-trivial floor prevents the resurgence of recursive carry trades at negligible cost once stress subsides. Boundedness preserves both behavioral credibility (no “infinite APR” fears) and economic discipline. Memory with Decay: Autonomous Relaxation on a Predictable Half-Life Requirement. When utilization falls back to or below the kink, the elevated post-kink slope must decay exponentially toward its floor at a governance-specified rate (half-life). No manual reset should be required. Rationale. A one-way ratchet erodes competitiveness and invites ad hoc overrides; a cliff reset is gameable and induces oscillatory behavior around u_k. Continuous exponential decay ensures that: (i) the system “remembers” stress long enough to deter immediate re-risking, and (ii) borrowers can anticipate precisely how fast costs will normalize, improving planning and trust. Two-Stage Optimization: Supply Safety First, Borrower Welfare Second We calibrate the growth and decay parameters (k,λ) through a structured two-step approach designed explicitly to align with the asymmetric economic realities of lending markets: 1. Feasibility filter (supplier solvency): We first apply a stringent feasibility filter that excludes any parameter combinations unable to satisfy a clearly defined probabilistic constraint ensuring supplier solvency. This constraint incorporates collateral price volatility, utilization dynamics, and liquidity duration, rigorously quantifying and bounding the risk of potential bad debt accrual. Parameter choices that fail to meet this solvency standard, validated through extensive simulation and statistical confidence, are strictly discarded. 2. Welfare optimization (borrower & systemic efficiency): Among parameter combinations meeting the solvency criteria, we select those that minimize a comprehensive welfare objective, W(k,λ). This welfare metric penalizes elevated nominal APR levels, representing borrower economic pain, and significant APR variance, reflecting systemic whiplash costs. As a result, borrowers are presented with the most economically efficient rate paths, subject explicitly to the primary constraint of guaranteed supplier safety. Calibratability: Data-Driven, Reproducible Parameterisation Requirement. Free parameters (growth k, decay λ, and caps/floors) must be calibrated from empirical telemetry: utilization distributions, stress-episode durations, APR path dynamics, collateral price volatility, and observed liquidation latencies. Recalibration should occur on a periodic cadence via a documented, methodologically consistent process. Rationale. Market structure is non-stationary: LST liquidity fragments, volatility regimes shift, and looping intensity evolves. Static parameter choices go stale. A well-specified calibration pipeline with recorded inputs and decision criteria reduces discretion, keeps updates principled, and sustains continuity over time. Synthesis These goals are mutually reinforcing: Convexity provides the time-critical deleveraging impulse. Boundedness constrains that impulse within socially and behaviorally acceptable limits. Memory with decay creates an algorithmic glide path back to normal conditions with respect to time, creating an approximative feedback loop whereby observed market volatility corresponds with the underlying fixed pricing mechanism at a given time t. Binary safety formalizes supplier protection as a hard feasibility frontier, not a tunable weight. Calibratability ensures the mechanism remains coupled to observed market dynamics and maintains credibility through reproducibility. Collectively, they define a rate curve that is stringent yet predictable, adaptive yet bounded, and aligned with the asymmetric economics of a recursively levered, liquidity-constrained environment. The intended outcome is rapid stress resolution, minimal post-shock drag, and a statistically guaranteed solvency profile for capital providers. !3.png !4.png !5.png !6.png !7.png !8.png !Captura de pantalla 2025-08-25 a las 9.24.49.png !10.jpg !11.png !12.png Disclaimer Chaos Labs has not been compensated by any third party for publishing this ARFC. Copyright Copyright and related rights waived via CC0

title: \[ARFC\] Launch GHO on Ink & set ACI as Emissions Manager for Rewards author: TokenLogic created: 2025-07-23 Summary This proposal aims to launch GHO on the Ink blockchain and designate ACI as the Emissions Manager for GHO and aGHO, facilitating potential rewards and incentive programs. Motivation Following the successful multichain expansion of GHO to Arbitrum, Base, Avalanche launching GHO on Ink represents the next step in growing GHO’s presence. Ink is an EVM-compatible, modular Layer 2 focused on scalable, capital-efficient DeFi applications brought to life by Kraken. With Aave’s anticipated deployment on Ink, bringing GHO to the network simultaneously ensures GHO becomes a foundational stablecoin in the ecosystem from day one. This ARFC seeks community support to approve the launch of GHO on Ink, ensuring the coordination of technical deployment, risk management, and ecosystem alignment. As learned from previous launches, successful expansion of GHO requires: Coordinated implementation of protocol and bridging infrastructure Definition of risk parameters tailored to Ink’s ecosystem Collaboration with local DEXs and applications for utility and liquidity Early incentive programs and strategic ecosystem engagement Specification Ink will be the next immediate focus for GHO growth alongside the Aave instance launch. The proposed launch of GHO on Ink involves the following components and responsibilities: | Service Provider | Responsibility | |----|----| | Aave Labs + Certora | Deploy GHO infrastructure and CCIP bridge | | TokenLogic | Deploy Facilitator, GSM, and Steward config | | Chaos Labs + Risk Llama | Set and monitor risk parameters | | ACI + TokenLogic | Incentive design and emissions distribution | | Aave Liquidity Committee | Coordinate DEX liquidity | | GHO Stewards | Maintain risk parameters over time | ACI multisig address: 0xac140648435d03f784879cd789130F22Ef588Fcd Timeline and exact implementation details will follow in subsequent AIPs after ARFC approval. GHO Parameters for Aave v3 Ink Deployment | Parameter | Value | |----|----| | Asset | GHO | | Market | Ink | | Isolation Mode | No | | Borrowable | Yes | | Collateral Enabled | No | | Supply Cap | 5,000,000 | | Borrow Cap | 4,500,000 | | Debt Ceiling | \- | | LTV | \- | | LT | \- | | Liquidation Bonus | \- | | Liquidation Protocol Fee | \- | | Variable Base | 0% | | Variable Slope1 | 5.5% | | Variable Slope2 | 50% | | Uoptimal | 90% | | Reserve Factor | 10% | | Stable Borrowing | Disabled | | Flashloanable | Yes | | Siloed Borrowing | No | | Borrowable in Isolation | No | | E-Mode Category | N/A | Facilitator and CCIP Configuration A GhoDirectMinter facilitator will be deployed on Ethereum to support GHO issuance for Ink: | Parameter | Value | |----|----| | Mint Cap | 15M GHO | CCIP configuration to support bridging to Ink: | Parameter | Value | |----|----| | Bucket Capacity | 15M GHO | | Inbound Capacity | 1,500,000 | | Outbound Capacity | 1,500,000 | | Refill Rate | 300 GHO/sec | GSM Parameters (stataUSDT0.ink) | Parameter | Value | |----|----| | GHO Bucket Cap | 10.00M | | USDT0 Exposure Cap | 5.00M | | Freeze Lower Bound | $0.990 | | Freeze Upper Bound | $1.010 | | Unfreeze Lower Bound | $0.995 | | Unfreeze Upper Bound | $1.005 | | Mint GHO Fee | 0.00% | | Burn GHO Fee | 0.00% | USDT0 deposits into stataUSDT0.ink will trigger GHO transfers from Ethereum-held inventory managed by the GSM. GHO Steward Configuration GhoAaveSteward: updateGhoBorrowCap: ±100% updateGhoBorrowRate: ±5% on optimalUsageRatio, baseVariableBorrowRate, variableRateSlope1, variableRateSlope2 updateGhoSupplyCap: Up to +100% GhoGsmSteward: updateGsmExposureCap: ±100% updateGsmBuySellFees: ±0.5% per side (FixedFeeStrategy) Only callable by the GHO Steward. Budget To bootstrap the Ink instance and support initial growth, a specific allowance on Ethereum will be created and bridged to Ink. ALC Ethereum SAFE: 0xA1c93D2687f7014Aaf588c764E3Ce80aF016229b Initial liquidity will be sourced via aUSDT0 and routed through Aave LP partners and Ink-native DEXs. Disclaimer TokenLogic is not compensated for the creation or coordination of this proposal. Next Steps 1. Gather feedback from the community 2. If consensus is reached, escalate to Snapshot vote 3. If Snapshot vote passes (YAE), proceed with AIP implementation Copyright Copyright and related rights waived via CC0

Authors: - Contributor and Threshold Committee member / @Ethan - tLabs Head of Business Development Date: 2025-05-30 Current ARFC has been updated on 2025-08-19 under Skywards by ACI to reflect latest Risk Service Providers parameters and to proceed with the governance next step. Summary This proposal seeks to onboard tBTC to Aave v3 on Base following a successful launch on Mainnet (Aave - Open Source Liquidity Protocol). As proposals for onboarding assets already onboarded in other Aave instances does not require a TEMP CHECK it is presented as an Aave Request for Comment (ARFC). Motivation/Background tBTC is Threshold’s decentralized and permissionless bridge to bring BTC to Ethereum, Base and 7 other chains. Users wishing to utilize their Bitcoin on Ethereum & Base can use the tBTC decentralized bridge to deposit their Bitcoin into the system and get a minted tBTC token in their EVM wallet. Threshold Network has recently brought direct minting of tBTC to Arbitrum and Base. It is live on Aave, Compound, GMX, EigenLayer, Synthetix, Morpho, Symbiotic and has strong, sticky liquidity to support liquidations. Following its approval on AAVE 3 Ethereum, tBTC’s initial supply cap was reached within 72 hours, prompting an increase to meet the overwhelming demand and now sits at over 2,200 BTC TVL. This rapid adoption underscores the market’s appetite for trust-minimized BTC solutions in DeFi. tBTC on AAVE v3 Arbitrum is just lacking an AIP and has already passed on ARFC and relevant risk analysis. tBTC on Base has a current supply of 116 BTC worth $12M at current price. Benefits for Aave High User Demand, since its initial deployment on Aave’s Ethereum market, tBTC reached its initial 500 BTC supply cap within the first week. The cap has been increased multiple times, now sitting at 2200 BTC, highlighting strong user interest. Something we hope to replicate on Base. Easy, direct onboarding of BTC capital via Threshold’s Base direct minting. Further decentralization and trust minimisation in the Aave stack. A range of lending options for those who wish to earn yield on their BTC. Preferable yields on tBTC through active incentive participation, boosting Aave protocol use, fees and TVL. Specification Ticker: TBTC Contract Address:Base: 0x236aa50979D5f3De3Bd1Eeb40E81137F22ab794b Chainlink Oracle:Base: 0x6D75BFB5A5885f841b132198C9f0bE8c872057BF Risk parameters Risk Parameters have been updated on 2025-08-19 Following the above analysis, we recommend the following parameter settings: | Parameter | Value | | --- | --- | | Isolation Mode | No | | Borrowable | Yes | | Collateral Enabled | Yes | | Supply Cap | 130 | | Borrow Cap | 13 | | Debt Ceiling | - | | LTV | 73% | | LT | 78% | | Liquidation Bonus | 7.5% | | Liquidation Protocol Fee | 10% | | Variable Base | 0% | | Variable Slope1 | 4% | | Variable Slope2 | 60% | | Uoptimal | 45% | | Reserve Factor | 20% | | Stable Borrowing | Disabled | | Flashloanable | Yes | | Siloed Borrowing | No | | Borrowable in Isolation | No | Symbol: TBTCBase Contract Address: 0x236aa50979D5f3De3Bd1Eeb40E81137F22ab794b Useful Links: Project: https: //www.threshold.network/Minting Dashboard: https://dashboard.threshold.network/tBTC/mintBridge to other Chains: https://portalbridge.com/tbtc-bridge/GitHub: https://github.com/keep-network/tbtc-v2Docs: https://docs.threshold.network/applications/tbtc-v2Audit: AboutImmunfi Bug Bounty: https://immunefi.com/bounty/thresholdnetwork/Llama Risk Report: https://hackmd.io/@LlamaRisk/tBTCTwitter: https://twitter.com/thetnetworkDiscord: https://discord.gg/threshold Dune: https://dune.com/threshold/tbtc Disclaimer: This proposal is powered by Threshold Network. The authors are FREDY (Contributor and Threshold Committee member) and @Ethan (tLabs Head of Business Development) Next Steps: Since proposals for onboarding assets already onboarded in other Aave instance does not require a TEMP CHECK it can go straight to an Aave Request for Comment (ARFC). Publication of this ARFC, collect community and service providers feedback before escalating the proposal to the ARFC Snapshot stage. If the ARFC Snapshot outcome is positive, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright: Copyright and related rights waived under https://creativecommons.org/publicdomain/zero/1.0/

[ARFC] Add XAUt to Aave v3 Core Instance Author: ACI Date: 2025-06-19 ARFC updated 2025-07-04 Summary The proposal aims to onboard Tether’s XAUt gold-denominated stablecoin, to the Aave v3 Core Instance, after successful [TEMP CHECK] Add XAUt to Aave V3 Core Instance and TEMP CHECK Snapshot. Motivation XAUt is a gold backed digital currency offered by Tether. XAUt represents a unique opportunity to bring gold-backed assets into DeFi lending markets. Adding XAUt to Aave v3 would: Diversify the protocol’s offerings with a historically stable store of value Enable users to use gold-backed tokens as collateral or for lending, creating new DeFi use cases Allow users a hedge against market volatility through exposure to physical gold Attract traditional finance users who are familiar with gold as an asset class The addition of XAUt aligns with Aave’s goal of expanding DeFi accessibility while maintaining strong risk management practices through the use of established, well-backed assets. Specification Ticker: XAUt Contract address: Risk Parameters will be provided by Risk Services Providers at the earliest possible and ARFC will be updated with that feedback. ARFC updated 2025-07-04 Parameter Value Asset XAUt Isolation Mode Yes Borrowable No Collateral Enabled Yes Supply Cap 5,000 Borrow Cap Debt Ceiling $3,000,000 LTV 70% LT 75% Liquidation Penalty 6% Liquidation Protocol Fee 10% Variable Base Variable Slope1 Variable Slope2 Uoptimal Reserve Factor Stable Borrowing Disabled Flashloanable Yes Siloed Borrowing No Borrowable in Isolation No E-Mode Category N/A Disclosure ACI (Aave Chan Initiative) is not afiliated with Tether and has not received compensation for creating this proposal. Next Steps Now - Publication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] Onboard tUSDe December expiry PT tokens on Aave V3 Core Instance Author: ACI Date: 2025-08-08 Summary This ARFC proposes to onboard tUSDe December expiry PT tokens on Aave V3 Core Instance. Motivation As PT tokens have proven to be a significant growth vector for Aave in recent months, we propose onboarding tUSDe December expiry PT token. This PT token is particularly attractive as the underlying is USDe, allowing for the deep USDe borrow liquidity on Aave to be made use of. In addition, the September expiry has extremely deep liquidity as a ratio of its marketcap which we expect to also be true of the December expiry, this should allow for rapid deposit cap increases as demand scales on Aave. In an effort to be prepared for onboarding soon after launch and taking into account time needed for due diligence for new Aave assets, we are initiating this onboarding process now. Specification Contract address will be updated once the December expiry is live. Risk Parameters Risk parameters will be provided by Risk Service Providers in the ARFC and will be updated accordingly. Useful Links https://docs.pendle.finance/ProtocolMechanics/YieldTokenization/PT [[TEMP CHECK] Onboard Pendle PT tokens to Aave V3 Core Instance](https://governance.aave.com/t/temp-check-onboard-pendle-pt-tokens-to-aave-v3-core-instance/20131) Disclaimer ACI is not directly affiliated with Pendle and did not receive compensation for creating this proposal. Some ACI employees may hold Pendle tokens. Next Steps 1. Period of discussion on this TEMP CHECK. 2. TEMP CHECK Snapshot vote for this proposal. 3. If TEMP CHECK is a YAE, publish a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. 4. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived under CCO

[TEMP CHECK] Onboard LsETH to Aave V3 Core Instance Author: ACI Date: 2025-07-22 Summary This is a TEMP CHECK to gauge community sentiment for onboarding Liquid Collective’s LsETH on Aave V3 Core. Motivation LsETH is an Ether liquid staking token. It’s unique in that it meets the security and compliance standards needed to serve both individual and institutional participants, and LsETH has recently gained traction with the Ethereum Treasury Company market. Over the past two months TVL has rapidly increased as the Crypto Treasury Company sector has gained traction, with TVL currently sitting around $1.3bn. We believe this sector will continue to see growth and present a set of new users to introduce to Aave. Chain to be deployed/listed Aave v3 Core instance on Ethereum mainnet. Proof of Liquidity and Deposit Commitments $200m of lsETH deposits are committed in the first 3 months after onboarding. 0.25-1% of token is committed to Aave incentives post-TGE. Specification Token Contract: 0x8c1bed5b9a0928467c9b1341da1d7bd5e10b6549 Risk Parameters: Initial Risk Parameters will be provided by Risk service providers during the ARFC phase. Useful Links Dune dashboard: https://dune.com/liquidcollective/liquidcollective Docs: https://docs.liquidcollective.io/v1/ Disclaimer The Aave Chan Initiative is not directly affiliated with Liquid Collective and did not receive compensation for creating this proposal. Next Steps 1. Period of discussion on this TEMP CHECK. 2. TEMP CHECK Snapshot vote for this proposal. 3. If TEMP CHECK is a YAE, publish a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. 4. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived under CC0.

Simple summary Proposal to kick-start the workflow of definition and implementation by Aave SPs of theAave Asset class Allowlist (AAcA), a simple governance framework to require explicit categorisation by asset class of asset listing candidates, and governance pre-approval of the asset class itself before proceeding to specific asset listings. --- Motivation Following the current governance frameworks, whenever an external team or the Aave community itself seeks a new asset listing on Aave v3, the process consists of the following steps: TEMP CHECK (forum discussion and Snasphot). During this stage, the community performs a discussion and vote to “soft” signal if there is appetite for the asset to be listed, usually boiling down to track record of the asset and team, growth opportunities, and other types of non-morphological (non-technical, non-risk related) aspects of the asset. ARFC (forum discussion and Snapshot). Once the asset passes TEMP CHECK positively, it enters the ARFC stage, whose main objective is to trigger operational work streams of the Aave Service Providers (SPs): risk analysis from @ChaosLabs and @LlamaRisk, technical/security analysis from BGD Labs, and any other particular feedback from professional contributors. AIP (optionally forum discussion and on-chain Aave governance vote). If the due diligence from Service Providers gives a positive output, the asset listing lifecycle proceeds to the crafting of the on-chain proposal executing the listing in the pool/s, and the creation of said proposal in the governance contract for AAVE holders to vote on it. We could say this procedure works relatively well: structured, but without falling into over-bureaucracy. Giving enough flexibility for SPs to maneuver, but without sacrificing quality. However, DeFi assets have become more and more complex/diverse over the years in DeFi across all their verticals, and clear and numerous asset classes have appeared. While this asset class diversity is overall positive for the DeFi ecosystem and Aave, it naturally forced Aave DAO’s internal procedures to adapt, mainly boiling down to the quality and flexibility of its SPs when doing their due diligence procedures for any type of DeFi asset. From BGD, we have observed lately that the complexity of assets combined with multiple parties involved in the evaluation has created high-level inefficiencies, for example, with assets arriving at analysis stages when, due to their nature, probably should not (cases like LP tokens, or assets having relatively complex strategies under the hood). We think that to address this, some extra “formalisation” of asset classes on Aave is required: 1. Explicitly define a list of DeFi asset classes currently listed on Aave, which covers a good part of all asset classes existing on DeFi. 2. Explicitly define a list of which asset classes are pre-authorised to be candidates for listing on Aave, and consider it as a pre-filter to not proceed to ARFC if not. If a candidate asset listing is of an asset class not pre-approved, it requires first pre-approval of the asset class. 3. Optionally define some simple alignment scale of the asset with Aave, considering aspects like whether the asset itself or the infrastructure around uses already the Aave protocol, if the asset belongs to/uses directly or indirectly a competitor of Aave, or if it is simply a neutral asset. The value of this categorisation + allow-list is important, including but not limited to: Avoiding situations of an asset arriving to SPs for due diligence, and requiring very contradictory and important effort: e.g. if tokenisation of liquidity supplied in a lending protocol would be a candidate listing, Aave SPs would need to make a formal due diligence of the whole lending protocol behind and procedures; due diligence that gives very high value to the team behind the asset itself (dubious for the interest of the Aave DAO), and with SPs spending massive resources. By not having, for example, competitors’ liquidity protocols tokenization on the allow list, the due diligence simply is not started, and resources can be allocated to more productive tasks. Generally, adapting the governance framework to the current landscape of assets, not to the one from 2-3 years ago. --- Specification The introduction of the Aave Asset class Allowlist (AAcA) is a task that, if approved by the community, Service Providers can perform as a joint effort. As with any collaborative project, it requires some initial organisation, and in our view, the steps for it could be the following: Assets' class initial categorisation SPs involved directly in asset analysis (BGD, Chaos Labs, LlamaRisk) can come up with a list of asset class categories covering all the assets currently listed on Aave. This will already help to identify both “pure” cases (e.g., AAVE as governance token), or “complex” ones (e.g., LRTs with more/less complex strategies). With risk providers working on a daily basis on asset profiling (liquidity monitoring, simulations), we think the work stream can be initiated by them (Chaos Labs, Llamarisk), and BGD will review the initial list and specifications before presenting the result here on the forum as a joint effort. The output of this task will be a document on a public repository on the aave-dao Github organisation, listing all categories and assets within each one of them. This repository will also act as the future Allow-List. Allow-list management To be consistent, all asset classes with at least one asset listed on Aave will be part of the Allow-list to start with. But going forward, we think the following guidelines are reasonable for management of the Allow-list (and implicitly categories): -> Addition to Allow-list Whenever a TEMP CHECK for a new listing is created on the forum (or before it if going through channels like ACI’s Skywards), there will need to be a categorisation exercise. If the asset belongs to a category in the Allow-list, the growth service provider (ACI) can simply assign the category, just confirming off-forum with analysis SPs (tech, risk) that it is correct. If the asset clearly doesn't belong to a category on the Allow-list, and the growth service provider (ACI) thinks adding to Allow-list could give value, they should request an analysis SP to initiate a process of categorisation of the asset first. This will trigger a process similar to what was described in categorisation: an analysis by SPs (BGD, Chaos, Llamarisk currently) to define the category with high-level pros/cons to the protocol. Once that is ready, the growth service provider can decide to proceed with an ARFC to add the asset class to the Allow-list, or not. -> Removal from Allow-list The removal of an asset class will be a mainly non-retroactive measure, to apply for new listings: e.g., LRTs could be removed from the Allow-list, and that would mean that no other LRTs are to be listed. In addition, this can potentially trigger risk work streams to reduce exposure to the asset class, but given that these could happen to be quite ad-hoc, we don’t see too much value in defining them at this stage. -> Visibility of the currently approved Allow-list See the previous categorisation section: a Github repository on the aave-dao org. IMPORTANT. The details of how the AAcA is finally implemented are subjected to changes during the creation process by SPs. This ARFC simply tries to outline a high-level goal and some guidance.

Title: [TEMP CHECK] Update forum features Author: @EzR3aL Date: 2025-07-24 Simple Summary This proposal seeks to update the Aave governance forum with features natively provided by Discourse. Motivation The Aave governance forum hasn’t really changed since inception in 2020. Over time many new features have been introduced by Discourse which would allow the DAO to be more transparent, offer more flexibility and efficiency, best examples are AI tools like “Summarize” or lables and custom pfp flairs. These could help to identify trusted member within the DAO like Orbit-Delegates or several SP.Here are some examples that could be implemented: !image (4).png As can be seen in the screenshot, we could add name tags to forum accounts and a small icon indicating that this user is a recognized delegate under the Orbit program/SP/etc. !AI_summary.png Discourse also enabled some AI tools. In this case its a tool to summarize threads, including comments. Making it easier to follow conversations, or get a quick update on a bigger proposal within a short timeframe. Specification The idea is to identify different options Discourse is offering and implementing these, if they have a positive impact and can be implemented without disturbing the workflow within the DAO. I will be taking care of these changes and accordingly adjust tags, logos, etc.In order not to create a governance overflow, the idea is to create only this one proposal to get approval from the DAO to implement these changes in the background continously. The DAO will be informed about each change and the benefits of the implemented features upfront.EDIT: All changes only include free of charge features. Disclaimer I have not been compensated for creating this proposal.I am an eligible Orbit delegate. Next Steps Publication of TEMP CHECK to gather community & service providers feedback, and escalate to TEMP CHECK Snapshot. If TEMP CHECK is approved, this thread will be updated continuously. Copyright Copyright and related rights waived via CC0

Title: [ARFC] Claiming AAVE Rewards for the Sablier Legacy v1.1 Contract Author: Sablier Labs powered by @ACI Skywards Date: 2025-05-05 --- Summary This ARFC proposes the transfer of 895.8057 AAVE (~$160K) in staking rewards from the Aave Safety Module to sablier.eth, due to the inability of Sablier’s Legacy v1.1 contract to claim them through standard mechanisms. Motivation Sablier Legacy v1.1 is a non-upgradeable smart contract that lacks an ERC-20 recovery or sweeping function. Over time, the contract has accrued staking rewards from participation in the Aave Safety Module. However, due to its immutable design and lack of reward-claiming logic, these tokens are currently inaccessible. To prevent permanent loss of funds, this proposal seeks governance approval to manually transfer the AAVE rewards to the Sablier treasury (sablier.eth), ensuring recovery of assets legitimately earned. Supporting context: The contract is publicly documented in Sablier’s official documentation. Source code is verified on Etherscan and open-source on Github. Specification This proposal calls claimRewardsOnBehalf() on 0xCD18eAa163733Da39c232722cBC4E8940b1D8888 and then transfer 895805689180182547296 wei of AAVE collected to sablier.eth Disclaimer Sablier Labs is not compensated for this proposal and presents it solely to recover unclaimable staking rewards. This proposal is powered by Skywards Next Steps Post ARFC Escalate proposal to ARFC Snapshot. If ARFC Snapshot pass, then escalate to AIP for final confirmation and enforcement of the proposal. Copyright Copyright waived under CC0.

Abstract This document presents a formal framework for dynamically calibrating the core parameters of the Correlated Asset Price Oracle (CAPO) system, namely maxYearlyRatioGrowthPercent and snapshotRatio, through autonomous Risk Oracles. These parameters jointly enforce a time-weighted upper bound on the permissible growth of a yield-bearing asset’s exchange rate relative to its base asset, thereby protecting downstream protocols from artificial inflation and oracle manipulation. Rather than relying on static limits or infrequent governance actions, the CAPO system leverages real-time analytics on yield behavior, reward distribution cadence, and market deviations to continuously constrain oracle outputs. The parameter maxYearlyRatioGrowthPercent defines the maximum annualized compound growth allowable in the asset’s exchange rate, while snapshotRatio, anchored by a past reference timestamp, serves as the historical baseline against which this growth is measured. Importantly, the effectiveness of CAPO is contingent not only on defensively parameterizing maxYearlyRatioGrowthPercent, but also on updating snapshotRatio at regular intervals. Without timely snapshots, even well-bounded growth parameters can permit excessive drift between the oracle's upper bound and the asset's true economic behavior. Continuous snapshotRatio refreshes are therefore critical to ensuring that CAPO remains tight, responsive, and manipulation-resistant across a diverse range of yield-bearing asset types. Risk Oracles act as autonomous agents that monitor these dynamics off-chain and reparameterize the CAPO system accordingly, enabling secure, low-overhead integration into protocols that depend on yield-sensitive exchange rates. Overview of CAPO and the Importance of Risk Oracles As detailed in the original CAPO framework, the system is architected to safeguard lending protocols against oracle-driven inflation vectors and donation-style exploits by imposing a deterministic, time-weighted upper bound on the exchange rate between a yield-bearing derivative (e.g., wstETH) and its base asset (e.g., stETH), capturing the upper envelope of organic yield accrual. This upper bound ensures that, even under adversarial conditions, such as unauthorized control of the price feed via compromised EOAs, centralized oracle dependencies, contract upgrade vulnerabilities, or donation attacks that exploit favorable exchange rate misalignments, the protocol remains protected against artificially inflated valuations that could otherwise be used to extract unbacked borrowing capacity or induce bad debt. This enforcement is governed by three key parameters: snapshotRatio: the reference exchange rate snapshotTimestamp: time of reference maxYearlyRatioGrowthPercent: the annualized cap on exchange rate growth The maximum ratio is determined via: ``python function _getMaxRatio() internal view returns (int256) { return int256(snapshotRatio + maxRatioGrowthPerSecond * (block.timestamp - _snapshotTimestamp) ` where maxRatioGrowthPerSecond = (snapshotRatio * maxYearlyRatioGrowthPercent)/SECONDSPERYEAR, effectively transforming a multiplicative derivation into fixed point arithmetic. To enforce temporal smoothing and prevent manipulation via micro-timeframe extrapolation, as discussed here, the snapshotRatio ensures the snapshot is taken at a sufficient temporal offset from the current block timestamp. The snapshotRatio functions as the foundational reference rate from which the upper bound on the exchange rate, denoted maxRatio—is derived. The parameter maxRatioGrowthPerSecond thus imposes a cap on the permissible rate of change in maxRatio relative to the time elapsed between the snapshotTimestamp and the current timestamp. This structure inherently positions snapshotRatio as the anchor for time-weighted evolution, with maxRatioGrowthPerSecond encoding the maximal compound growth over time. Importantly, this design implies that if snapshotRatio is not refreshed at a consistent cadence, the derived maxRatio becomes increasingly detached from real-world exchange rate dynamics. Over long intervals, the temporal averaging embedded in the model begins to dilute responsiveness, effectively introducing drift between the enforced upper bound and the actual prevailing rate. To illustrate this phenomenon, consider an example where maxRatioGrowthPerSecond is set to 9.68%, as wstETH is. If the factual growth in the exchange rate over the elapsed period is only 3.1%, then as the time delta increases, the upper bound maxRatio diverges significantly from the true rate. As observed below, the exchange rate can grow as much as 9% before reaching the upper bound during an inflation attack, which represents an equivalent 7 day APY of 450% in order to hit the upper bound. This growing discrepancy stems from the assumption of compounding at 9.68% per second, whereas reality reflects a much more tempered rate, thus highlighting the need for timely snapshotRatio updates to maintain effective control and fidelity in rate enforcement. !1.png Assuming the snapshotRatio is updated monthly with a 7-day delay, the same maxYearlyRatioGrowthPercent constraint results in a substantially tighter upper bound on the exchange rate trajectory and its derived annualized growth. Empirically, the realized exchange rate remains within ~0.7% of the computed maximum exchange rate at all times, demonstrating effective rate bounding. Notably, this occurs even as the implied annualized growth, computed as a function of the local exchange rate delta, ranges between 12% and 37%. This discrepancy illustrates how regular snapshotRatio updates act as a mechanism for bounding short-term rate expansions, minimizing artificial inflation in annualized growth metrics induced by infrequent updates or stale snapshots. !22.png Dynamic Responsiveness to Local Yield Spikes: Automating maxYearlyRatioGrowthPercent In the general case, updating maxYearlyRatioGrowthPercent is a relatively frictionless and statistically grounded process. Most yield-bearing assets, such as those driven by lending interest, validator rewards, or liquidity mining, exhibit deterministic or semi-deterministic return profiles, enabling historical data to reliably inform an optimal cap value in a relatively infrequent manner. The CAPO algorithm leverages this regularity by using observed historical behavior to tune bounds that are both tight and appropriate, minimizing over-constraining during periods of normal growth. However, in assets with more sporadic or bursty yield distributions, where updates occur less frequently and snapshotTimestamp values may trail current conditions, large injections of rewards, such as DAO-driven emissions, retroactive drops, or sudden staking incentives, can cause abrupt local spikes. In these cases, the growth rate inferred from such snapshots can become outdated or unrepresentative, lagging behind the true yield trajectory. Under the assumption that yield rates are experiencing local upward spikes, such that organic accrual temporarily approaches the configured maxYearlyRatioGrowthPercent, the CAPO algorithm, informed by its multidimensional parameter configuration, is designed to adaptively respond. It minimizes false positives by dynamically tightening or relaxing bounds in proportion to observed volatility, thereby reducing unnecessary artificial constraining during periods of legitimate growth. The parameter maxYearlyRatioGrowthPercent is computed as follows: !33.png Update Decision Rule under Rate Escalation Given the constraint that CAPO parameters can only be updated every 3 days, it is essential to design a conservative yet precise mechanism for deciding when to trigger an update of maxYearlyRatioGrowthPercent. The objective is to ensure that if a sudden escalation in staking yield begins, the CAPO mechanism still maintains an enforceable cap on the exchange rate before the next available update window. To achieve this, we introduce a decision rule that relies on short-term yield velocity as a proxy for immediate risk. !99.png In contrast, under the assumption that observed rates decrease over time, per the algorithm above, the recommended output is derived as a function of the last 90 days of data, hence updating downward when necessary. In this context, the underlying “decision rule” is structured such that half of the defined maximum relative change serves as the threshold for permissible deviation, effectively acting as the trigger condition for downward rate updates. Practical Examples and Backtesting To illustrate the behavior and responsiveness of the rate calibration framework under varying market conditions, we present two contrasting case studies, ezETH and wstETH, analyzed through historical reward dynamics, APY trajectories, and parameter updates observed during recent backtesting. ezETH’s reward distribution has historically been highly irregular, characterized by intermittent and uneven emissions. In March, ezETH’s exchange rate experienced a notable upward distortion due to the protocol’s one-time injection and distribution of EIGEN rewards directly into the ezETH contract. This distribution materially inflated the exchange rate by increasing the cumulative rewards per token, effectively front-loading yield accrual. Prior to this event, the system exhibited significant short-term volatility in reward emissions and the associated annualized APY, as reflected in elevated dispersion metrics and an initially calibrated maximum rate of 12.38%. !44.png Post-spike, the rate-setting algorithm executed a parameter recalibration in response to the updated reward trajectory. The underlying statistical properties, such as recent APY momentum and rate-of-change in cumulative rewards, registered an upward shift, thereby impacting the computed max rate recommendation. Crucially, the required minimum 3-day trailing APY, used as a guardrail to prevent excessive rate increases, converged below the observed realized 3-day APY. As a result, the updated max rate, governed by the 3-day constraint, was deemed optimal and within bounds, thereby increasing the associated maxYearlyGrowthPercent. The system thus exhibited resilience by adapting to the anomalous input while maintaining rate integrity and responsiveness. !55.png By contrast, wstETH exhibits highly deterministic rate growth and a stable state trajectory, which minimizes the need for active updates. The protocol operates under a dynamically constrained cap, continuously adjusted through real-time updates to the snapshotRatio. Given the low volatility and predictable accrual pattern, updates to the maxYearlyRatioGrowthPercent have been largely unnecessary, with the current value of 4.6% remaining sufficient to accommodate its steady yield progression. !66.png Internally, while the effective recommended rate evolves, the magnitude of change remains within the tolerance defined by the existing maxYearlyRatioGrowthPercent, thereby not triggering an update. Specifically, the required 3-day APY has consistently remained below the observed 3-day APY, ensuring that the rate adjustment constraint remains satisfied. It is only toward the later stages of the observation window that we see a decline in the recommended rate, driven by the sustained smoothing of short-term yield signals, reflected in both the capped maximum rate and a concurrent reduction in measured volatility. !77.png Proposed Parameter Constraints for CAPO Risk Oracle Updates To maintain the integrity, predictability, and neutrality of the CAPO system, Risk Oracle parameter updates are subject to explicit constraints that govern their frequency and magnitude. These constraints are designed to ensure that CAPO remains a minimally trusted, credibly neutral mechanism, where bounded reactivity to market conditions does not come at the expense of system stability or over-centralized control. snapshotRatio Constraint: The snapshotRatio, which serves as the historical anchor for computing the time-weighted upper bound on exchange rates, can be updated at most once every 14 days and by no more than 5% relative to the prior value. The underlying algorithm will in practice only update once a month in most settings, representing an approximate upper bound of ~60% APR over a monthly horizon, aligned with aggressive but plausible yield scenarios. Importantly, snapshotRatio is simply obtained from the relevant smart contract currently utilized to calculate the exchange rate for a given asset, at a given timestamp snapshotTimestamp, which adheres to the associated time-weighted logic expressed here (generally 7-14 days prior). maxYearlyRatioGrowthPercent Constraint: The parameter that controls the annualized rate ceiling can be adjusted once every 3 days, with a maximum 10% relative change per update. This strikes a balance between responsiveness to dynamic yield environments and measured, rate-limited evolution of the enforced cap. | Parameter | Max Relative Change per Update | Timelock | | --- | --- | --- | | snapshotRatio | 5% | 14 Days | | maxYearlyRatioGrowthPercent` | 10% | 3 Days | Disclaimer Chaos Labs has not been compensated by any third party for publishing this ARFC. Copyright Copyright and related rights waived via CC0

[ARFC] Orbit Program Renewal - Q2 2025 Author: ACI (Aave Chan Initiative) Date: 2025-07-03 --- Summary Proposing the renewal of the Orbit program for recognized delegates, compensating them with GHO, associated with their governance activity during Q2 2025 ( From 2025-04-01, last date, until 2025-06-30). Motivation Orbit recognizes the added value of the Delegates in the decentralization & diversity of the Aave DAO. This compensation allows them to focus on Aave and keep their contribution efforts to our governance. The ACI proposes the extension of Orbit for a new quarter, Q2 2025, from 2025-04-01 to 2025-06-30. As a reminder, a new cutoff had been set on previous renewal, starting at AIP 224, to apply again previous rules of a minimum of 20k voting power and 85% vote ratio on all Snapshots and AIP to be considered elegible to Orbit. Specification Period Coverage: Q2 2025 from 2025-04-01 2025 to 2025-06-30 Eligible Platforms: - EzR3al: 0x8659d0bb123da6d16d9394c7838ba286c2207d0e - stablelabs: 0xecc2a9240268bc7a26386ecb49e1befca2706ac9 - IgnasDefi: 0x3DDC7d25c7a1dc381443e491Bbf1Caa8928A05B0 Budget: 45,000 GHO (aEthLidoGHO) Relevant Links: - ACI’s Orbit tracker Additional considerations: As a reminder, Service Providers will not be considered elegible to Orbit Program. Funds are distributed based on 90 days, as seen on budget. Next Steps 1. Gather community feedback on this ARFC. 2. If consensus is achieved, escalate this proposal to the ARFC snapshot stage. 3. If the ARFC snapshot outcome is YAE, proceed to the AIP stage for implementation and funding allocation in cooperation with Aave Finance service providers via an ad-hoc AIP vote or bundled in one of their treasury management AIPs. Disclosure The ACI is independent and has not received any form of compensation from related parties for the drafting of this proposal. Copyright Copyright and related rights waived under Creative Commons Zero (CC0)

[ARFC] Deploy a Whitelabel Aave V3 Instance on Ink Author: Ink Foundation & ACI Date: 2025-06-19 Summary This proposal aims to deploy a whitelabel version of Aave V3 for the Ink Foundation. By granting a license to deploy a centralized version of the Aave codebase, Aave can expand its technology adoption while creating new revenue streams through partnerships with innovative platforms. Motivation The Ink Foundation seeks to leverage Aave's battle-tested infrastructure to create a native lending platform. This partnership represents an opportunity for Aave to expand its influence in the institutional lending space while maintaining its commitment to technological excellence. Specification Key aspects of this deployment include: Centralized Governance: The instance will initially be centrally governed by the Ink Foundation without a governance token Service Provider Support: Aave DAO service providers (including ACI, Chaos Labs, and others) will maintain and contribute to the deployment for the initial 6-month period, after which Ink Foundation will need to establish a commercial arrangement for continued support Revenue Sharing: The Aave DAO will receive a share of all revenue generated by the platform. This should be greater than or equal to the equivalent of a Reserve Factor of 5% based on borrow volume in all pools. Insurance Disclaimer: This instance will not be covered by the DAO-operated Umbrella. Branding: The instance will be branded as "Powered by Aave" but retain unique branding as determined by Ink Foundation. Ink Foundation and its centralized partners will focus on this instance as their exclusive onchain lending vertical and will refrain from communicating, incentivizing, integrating or doing partnerships with other lending protocols for a minimal period of 12 months after deployment. POL and Incentives The Ink Foundation has committed significant incentives to bootstrapping this instance. This includes multiple liquidity mining programs that are expected to bring over $250m in early supply to the instance. A initial amount of 4% of future governance token supply has been allocated to bootstrapping incentives. In addition the Aave DAO will authorize incentives for a mix of use cases including but not limited to user borrowing rebates, GHO liquidity incentives, and revenue cash back. These incentives can be in a mix of GHO or Aave tokens. AFC is responsible to manage the incentives paid by Aave DAO and will finance them via treasury AIPs. The Ink Foundation is committed to making the instance a success and will work with Aave service providers to plan and distribute incentives to users. Next Steps 1. If consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is YAE, this proposal will be escalated to AIP stage. 3. AIP written with relevant infrastructure deployment made on Ink chain and governance transferred to Ink Foundation. Disclaimer: This proposal is powered by Skywards. The Aave Chan Initiative is not directly affiliated with Ink and did not receive compensation for the creation of this proposal. Copyright: Copyright and related rights waived under CC0

Summary This publication outlines the next incremental reduction in AAVE emissions being distributed to stkAAVE and stkABPT holders. Motivation stkAAVE On the 5th June 2025, the Umbrella upgrade went live and the AAVE emissions for stkAAVE reduced by 45 AAVE/day from 360 to 315 AAVE/day. The chart below show the stkAAVE yield reducing from 4.58% to 4.0% as intended when the Slashing risk was reduced from 30% to 20%. !Screenshot 2025-07-07 at 18.58.18 The current stkAAVE yield is 3.95% and represents 19.33% of Total AAVE supply with 22,675 unique users, up from 20,023 on the 5th June 2025. Since early April AAVE deposits in stkAAVE have been gradually increasing and only 3.82% of stkAAVE in cooldown, indicating stkAAVE has achieved an equilibrium with only minor flows in and out of the contract. !Screenshot 2025-07-07 at 13.12.48 Over the last 30 days, an additional 43,664 AAVE has been deposited into stkAAVE, with 26,595 deposited on the 7th June, two days after the Umbrella upgrade went live. !Screenshot 2025-07-07 at 19.07.50 Given the strong support for stkAAVE over the 30 day period since Umbrella went live, exceeding our expectations, this publication proposes the next reduction in Slashing Risk and AAVE emissions. By reducing Slashing from 20% to 10%, the risk exposure is reduced by half. With an improving risk profile, the AAVE emissions are to be revised lower to 260 AAVE/day, or 3.25% at current deposit levels. Umbrella User deposits into Umbrella have been growing steadily with 280.7M of Coverage relative to a Target Coverage of $248.9M. !Screenshot 2025-07-09 at 19.52.05 Source: https://aave.tokenlogic.xyz/umbrella-eth-core !Screenshot 2025-07-09 at 19.49.26 Source: https://aave.tokenlogic.xyz/umbrella-eth-core Prior to the Umbrella Upgrade, Aave DAO was distributing 700 AAVE/Day and if this proposal is implemented the Emission rate becomes 390 AAVE/Day. Upon implementing this proposal, emissions will have been reduced by 310 AAVE/day since Umbrella was launched, valued at an estimated $30.5M annually. | Category | Pre-Umbrella Emission Rate | Post Umbrella Emission Rate | Proposed Below| | :------- | :-----------------: | :-----------------: | :---: | | stkGHO | 100 | 0 | 0 | | stkABPT | 240 | 215 | 130 | | stkAAVE | 360 | 315 | 260 | | Amount($)| 700($189k) | 530($143.1k) | 390($105.3k) | Assuming: 1 AAVE = 270 USD The reduction in AAVE emissions, $30.5M, compares favourably to the current Umbrella $8.7M budget, consisting of 7.2M stablecoins and 550 WETH. Upon implementing this proposal, the net reduction in emissions from Umbrella and the Safety Module is valued at $20.8M annually. More broadly, the shift from AAVE emissions to Cashflow reflects the progressive implementation of AAVEnomics which also contains a 26 week buyback program at an annualised rate $52M. stkABPT Since the Umbrella upgrade went live on the 5th June 2025, when stkABPT emissions reduced from 240 AAVE/day to 216 AAVE/day, only 51,217 BPT tokens, or 8.21% of the liquidity has been withdrawn from the Balancer liquidity pool. The vast majority of the withdrawal volume was by a single user that withdrew 50k units on Jun-06-2025. Otherwise, the number of unique users remains unchanged with a net reduction of 2 users over the last 30 day period. !Screenshot 2025-07-04 at 22.19.02 Source: https://aave.tokenlogic.xyz/stkabpt !Screenshot 2025-07-04 at 22.21.50 Note: Exponential Y-Axis. Source: https://aave.tokenlogic.xyz/stkabpt Over the last 30 days, the average yield received by ABPT stakers is 11.99% comprised of 0.55% from wstETH, 1.35% swap fees and 10.09% from AAVE emissions. At near 12%, the APY is at the top of the previous target guidance of 10-12% with a 20% Slashing exposure. !Screenshot 2025-07-05 at 13.45.08 With only 1.25% of stkABPT in Cooldown, it indicates an equilibrium has been achieved, and we are now well placed to revised the AAVE emissions. Reducing the Slashing exposure from 20% to 10%, improves the overall risk profile of holding stkABPT. A new guidance of 8% total yield for holding stkABPT is proposed comprised of 0.55% wstETH yield, 1.35% swap fee derived yield and 6.10% in AAVE emissions. Whilst this represent as material change from ~12% to ~8% total yield, the liquidity pool contains generous levels of liquidity relative to swap volume passing through the pool. Utilisation of liquidity, Swap Volume / Pool TVL, remains mostly unchanged with 91.4% of swaps being $40k USD or smaller in size relative to a $211M TVL liquidity pool. A reduction in pool TVL is not likely to impede the pools ability to attract swap volume. The emergence of new liquidity pool(s) mentioned in the next section presents an opportunity to measure the impact of new liquidity pools with improved capital efficiency. !Screenshot 2025-07-04 at 22.24.16 Source: https://aave.tokenlogic.xyz/stkabpt AAVE Liquidity Balancer As mentioned in the earlier forum post, we continue to work closely with the Balancer team to explore new concentrated liquidity pools with automated built in rebalancing. The first reCLAMM prototype pool is now live on Ethereum and we expect to start working with LPs to grow deposits and gather more data on how the pool behaves over time before we consider providing Protocol Owned Liquidity (POL). !Screenshot 2025-07-05 at 14.10.07 Source: Balancer AAVE/wETH Pool with further insights available in Balancer's documentation. The below outlines some of the advantages of this pool type: All the benefits of concentrated liquidity: higher fees and better capital efficiency (when in range, same math as UniV3) None of the maintenance required with traditional concentrated liquidity pools: LP-and-forget Moreover, unlike third party ALMs, the rebalancing is entirely transparent Fungible positions can be incentivised, making them ideal for guaranteeing deep DAO token liquidity Calculations simplified by having all LPs share the same price range reCLAMM Pools automatically adjust to market conditions; LPs should always be earning fees While designed to be maintenance-free, reCLAMM Pools are tuneable by admins if necessary in extreme conditions Aerodrome Previous efforts to support AAVE liquidity on Base continue to support ±10M TVL in AAVE/WETH liquidity earning 24.56% APR at no cost to Aave DAO for Liquidity Providers on Aerodrome. The yield currently exceeds what is available on Ethereum, and the pool continues to grow steadily whilst being dependent upon a concentrated liquidity provider base. !Screenshot 2025-07-05 at 16.43.19 Source: https://dune.com/0xkhmer/aerodrome !Screenshot 2025-07-05 at 16.33.44 Source: https://dune.com/0xkhmer/aerodrome Specification This proposal when implemented via AIP will: Reduce AAVE Emissions | SM Category | Current | Proposed | | :---------- | :-----: | :------: | | stkAAVE | 315/day (3.94% APY) | 260/day (Est. 3.25% APY) | | stkABPT | 216/day (10.09% APY) | 130/day (Est. 6.10% APY) | Total yield for stkABPT holders revised from 11.99% to 8.00%, with 0.55% from wstETH, 1.35% swap fees and 6.10% from AAVE emissions. When implemented the AIP will reduce daily AAVE emissions by 141 AAVE, from 531 AAVE/day to 390 AAVE/day. The reduction in AAVE emissions is equivalent to a cost saving of $13.9M assuming $270 price. After the AIP is implemented, the annualised AAVE Emission rate is 142,350 AAVE/year, equivalent to $38.4M annual spend at $270/AAVE. Reduce Slashing Risk | SM Category | Current | Proposed | | :---------- | :-----: | :------: | | stkAAVE | 20% | 10% | | stkABPT | 20% | 10% | Forward Looking Statement In approximately 30 days after the AIP is executed, we will review how users have responded to the rewards adjustments and the impact of various growth initiatives being pursued before presenting the next steps towards optimising the Safety Module. Directionally, users can expect the following: With an increasing focus on Umbrella, Slashing on stkAAVE and stkABPT is to be reduced to 0. Further optimisation of AAVE emissions to stkABPT and stkAAVE holders is expected within the next update to reflect the improved risk profile of reducing Slashing from 10% to 0% in line with the broader AAVEnomics implementation. The DAO is currently pursuing several growth initiatives that could lead to stkAAVE rewards may be revised lower than expected with capital being reallocated towards medium to longer term growth initiatives. Continue to trial new AAVE DEX liquidity pools as we prepare to migrate liquidity to new more capital efficient concentrated liquidity pools. * Aerodrome on Base AAVE/WETH * Balancer on Ethereum AAVE/WETH Deploy Protocol Owned Liquidity leading to further reductions in AAVE emissions being used to sustain AAVE liquidity across DEX pools. Disclosure TokenLogic does not receive any payment for this proposal. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] Onboard fxSAVE to Aave V3 Core Instance Author: ACI (Aave Chan Initiative) Date: 2025-06-23 --- Summary This TEMP CHECK proposes the onboarding of f(x) Protocol's token into the AAVE ecosystem. f(x) Protocol is an innovative DeFi protocol that creates decentralized stablecoins and leveraged tokens by splitting yield-bearing assets, offering unique opportunities for capital efficiency and yield optimization. Motivation f(x) Protocol launched in September 2023 and introduces a new paradigm for decentralized stablecoins, providing returns on stable assets collateralized by lower-risk derivatives. The protocol operates through two main versions: V1 Features: Splits any yield-bearing asset into two tokens: a stablecoin and a leveraged xToken Offers stablecoins including fETH, rUSD, btcUSD, and cvxUSD fETH captures only 10% of ETH's volatility while xToken absorbs the rest V2 Features: Delivers exceptionally high and sustainable yields derived from PERP trading commissions USD delta-neutral stability pool that avoids counterparty risk Up to 10x leverage on ETH with minimal liquidation risk through xPOSITION Strategic Benefits 1. Diversified Yield Sources: Access to f(x) Protocol's unique yield generation mechanisms, including stETH staking rewards, perpetual trading fees, and FXN emissions. 2. Risk-Adjusted Returns: The protocol's stability mechanisms ensure 100% collateralization with tier-1 DeFi assets, primarily Lido's stETH, aligning with fxSAVE's risk management principles. 3. Capital Efficiency: The f(x) invariant ensures unparalleled capital efficiency while maintaining full collateralization, maximizing returns per unit of capital deployed. Specification Risk Parameters will be provided by Risk Service Providers and proposal will be updated accordingly at ARFC stage. Next Steps 1. Publication of TEMP CHECK to gather community & service providers feedback, and escalate to TEMP CHECK Snapshot. 2. Publication of a standard ARFC, if TEMP CHECK Snapshot passed, to continue collecting community & service providers feedback before escalating proposal to ARFC snapshot stage. 3. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Disclaimer The current proposal has been powered by Skywards. ACI is not afiliated with f(x) Protocol and has not received compensation for the creation and edit of this proposal. Copyright Copyright and related rights waived via CC0.