Aave Governance

2025-03-26: This post was edited to reflect @LlamaRisk and @ChaosLabs parameters recommendations. When they differ, the most conservative one is selected. [ARFC] Launch GHO on Gnosis Chain author: kpk date: 2025-03-13 Summary This proposal aims to launch GHO on the Gnosis chain and designate ACI as the Emissions Manager for GHO rewards and incentives. Deploying GHO to Gnosis is one part of kpk’s (formerly karpatkey) mandate and a milestone towards sGHO (savings GHO) deployment. Gnosis Chain has low transaction fees, an engaged community, and a rapidly growing suite of DeFi applications focused on RWAs and innovative payment solutions like Gnosis Pay. Motivation The sGHO vault will provide a risk-minimized yield alternative that can be used as collateral for enhanced capital efficiency, debuting on Gnosis Chain. The first step of this deployment is introducing GHO to the Gnosis Chain, which is renowned for its cost-efficiency, active community, and innovative DeFi landscape, making it an ideal environment for GHO. As GHO Growth Service Provider, kpk has been entrusted with driving community engagement, forging strategic partnerships, and ensuring the successful liquidity bootstrapping of GHO. This proposal leverages kpk’s expertise and the favorable market conditions on Gnosis to deploy GHO with risk parameters and smart contract implementations that are finely tuned to the unique characteristics of the Gnosis ecosystem. sGHO deployment, the enhancements proposed to the GC Instance and future incentives for GHO (subject to an upcoming proposal on both DAOs) will work together to position GHO as a strong player within Gnosis, enhancing the TVL and revenue for Aave on this chain. Specification The deployment of GHO on Gnosis will be executed through coordinated efforts among various service providers. The necessary smart contracts and supporting infrastructure will be designed and deployed to enable full GHO functionality on the Gnosis chain, including the implementation of any required cross-chain bridge infrastructure to ensure seamless integration within the Aave ecosystem. In parallel, risk and finance service providers will collaborate to establish risk parameters and collateral requirements specifically optimized for the Gnosis environment, incorporating insights gained from previous network launches. Therefore, kpk is inviting all Service Providers to provide input on their scopes in this proposal. The proposed launch of GHO at Gnosis Chain will have the following key components: BGD and Avara (Aave Labs) to implement and deploy the necessary smart contracts for GHO on the Gnosis Chain network, including cross chain bridge infrastructure and addition to Aave v3 Gnosis Chain. Risk service providers and finance service providers should collaborate on appropriate risk parameters and collateral requirements tailored to the Gnosis Chain ecosystem. Additionally, a strategic plan will be developed to bootstrap initial liquidity on Gnosis, including tailored incentives and partnerships with established protocols in the ecosystem. @ACI will serve as the Emissions Manager for GHO rewards and incentives. ACI multisig address: 0xac140648435d03f784879cd789130F22Ef588Fcd The exact timeline and detailed technical specifications for each component will be determined by the service providers and presented in subsequent AIPs, pending the approval of this ARFC. GHO parameters |Parameter|Value| | --- | --- | |Asset|GHO| |Market|Gnosis| |Isolation Mode|No| |Borrowable|Yes| |Collateral Enabled|No| |Supply Cap|2,500,000| |Borrow Cap|2,250,000| |Debt Ceiling|-| |LTV|-| |LT|-| |Liquidation Bonus|-| |Liquidation Protocol Fee|-| |Variable Base|0%| |Variable Slope1|6.5%| |Variable Slope2|50%| |Optimal|90%| |Reserve Factor|0%| |Stable Borrowing|Disabled| |Flashloanable|Yes| |Siloed Borrowing|No| |Borrowable in Isolation|No| |E-Mode Category|N/A| Ethereum ↔ Gnosis GHO Facilitator A facilitator will be deployed on Ethereum specifically to support Gnosis with this initial configuration: |Parameter|Value| | --- | --- | |Mint Cap|10M Units| CCIP Configuration Bridge Facilitator parameters: |Parameter|Value| | --- | --- | |Bucket Capacity|+15M Units| |Rate Limit Capacity|1,000,000 units| |Refill Rate|200 GHO/sec| GHO Stewards As with every GHO deployment, GHO Stewards are recommended to be deployed. Stewards would have the same parameter change capabilities as on other chains. Disclaimer kpk is not presenting this ARFC on behalf of any third party and is not compensated for creating this ARFC. Next Steps If consensus is reached on this ARFC, the proposal will be escalated to the Snapshot stage. Upon a positive Snapshot outcome, service providers will proceed with the appropriate AIPs. Copyright Copyright and related rights waived via CC0.

Summary This framework outlines a general approach for utilizing GHO as the gas token of a network. The framework is designed to be adaptable for any network looking to use GHO in this capacity. Unlike bridging GHO as an ERC-20 token, this framework establishes a structured approach to integrating GHO as a gas token through a native bridge. The framework uses the canonical network bridge for minting GHO as a gas token. It also explores extensions such as integrating messaging protocols like Chainlink CCIP to align with the existing GHO cross-chain strategy. Additionally, a wrapper contract on Ethereum allows the GHO implementation to be upgraded and extended for future innovations. Motivation Stablecoins offer a fast, efficient, and stable means of transferring value on blockchain networks. Decentralized stablecoins like GHO add transparency and censorship resistance. Using GHO as a gas token makes it a core part of the network’s transaction layer, allowing it to function as a standard economic unit. This creates predictable pricing for gas fees, particularly in low-fee networks where transaction costs are often subsidized. The decision to use a canonical bridge as the primary liquidity pool is based on the unique requirements of deploying GHO as a gas token rather than as a bridged ERC-20, and ties security of token bridging to the underlying network bridge. Messaging protocols generally work with ERC-20 transfers, meaning a custom implementation would be required for network gas tokens. A native bridge allows for a more streamlined approach, embedding gas token bridging into the network’s primary liquidity bridge and does not introduce new attack surfaces or security assumptions. The framework can be made compatible with Aave’s broader GHO cross-chain strategy by integrating messaging protocols into the native bridge, aligning with the existing cross-chain implementation, where Chainlink CCIP is the canonical messaging layer for GHO as an ERC-20 token. Specification The framework defines the architecture for adopting GHO as a gas token across L2 networks. It outlines how the native bridge operates as the primary liquidity pool for GHO minting, embedding security and liquidity management directly into the network’s base infrastructure. The approach limits fragmentation across multiple bridges and reduces dependency on external liquidity providers. Future governance decisions could introduce more granular controls over bridging frameworks to refine security and liquidity strategies. !Aave Governance Post - Launch Instead of locking the framework into any specific messaging protocol, the design remains modular, allowing for future integrations. If messaging protocols become natively supported by canonical bridges, governance can set parameters to manage liquidity distribution and bridging constraints. The GHO Wrapper contract on Ethereum mainnet provides flexibility for upgrades and extensions without modifying the core bridge infrastructure. The contract has been audited by Pashov Audit Group. It allows for upgrading implementations of the underlying GHO token or supporting additional innovation in the future. This modular design makes it possible to introduce new functionalities without disrupting the existing bridge and minting architecture. Sourcing liquidity on the destination chain requires careful consideration of how GHO is introduced and maintained in the network. GHO is minted on Ethereum and bridged to the destination chain as needed, meaning liquidity only enters circulation when the remote facilitator puts it into use. This follows GHO’s cross-chain strategy, where all liquidity originates on Ethereum. Conclusion This framework lays the groundwork for adopting GHO as a gas token across multiple networks. It provides a structured approach to liquidity management while allowing for future expansions, including governance-controlled messaging integrations, modifications to bridging on Ethereum, and mechanisms to enable liquidity to be pre-minted on destination chains. The Aave community is invited to contribute to refining this framework. Next Steps If Snapshot outcome is YAE, escalate this proposal to AIP.

Summary This publication details the initial configuration of 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. Motivation Overview Service providers have been progressively streamlining the management of the Aave DAO’s funds by shifting approved ARFC proposals from on-chain vote to trusted smart contracts that act as stewards. Building on the success of the initial Risk Stewards and the introduction of the Clinic Steward and GHO Stewards, the Finance Steward modules will further enhance the efficiency and coordination of DAO operations. 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. The initial set up of the Finance Steward includes deploying two separate modules (smart contracts), the PoolExposureSteward and the MainnetSwapSteward. PoolExposureModule Features The PoolExposureModule is granted permission to facilitate the following routine operational tasks: Migrations Withdraw assets from Aave V2 and deposit into Aave V3. Withdraw assets from a given Aave V3 pool and deposit into another Aave V3 pool (ie: Core to Prime). Deposit Passive Assets Deposit idle Collector funds into Aave V3. Withdraw Assets Withdraw funds from Aave V2 or Aave V3 into the Collector. These funds can then be used for runway or to perform swaps where applicable. SwapModule The SwapModule is granted permission to swap tokens held by the Collector for other tokens to be sent to the Collector as well. The SwapModule will only be available on Mainnet initially. The below details frequent routine operations supported by the MainnetSwapSteward module: Swap assets to support near term DAO financial expenses such as ensuring incentive campaigns and Service Providers are adequately funded. Reduce exposure to long-tail assets by exchanging these assets for stablecoins or wETH. Convert ETH to a liquid staking token (LST) to earn additional yield;. Budget Limits To align the MainnetSwapSteward module’s functionality with immediate operational requirements, the contract is designed with a predefined budget per token, which can only be adjusted through Aave’s governance. This budget parameter serves as a safeguard, ensuring controlled exposure for the DAO by limiting the volume of assets that can be swapped from the Treasury. Specification The publication will be rolled-out in two steps. The first step will launch the PoolExposure module and the second proposal will launch the MainnetSwap module. Both contracts have the DAO as the owner of the contract and the following SAFE acting as the guardian 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa. The SAFE is to be 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 PoolExposureModule will be deployed on the following chains, with the listed pools approved for interaction. | Network | Pools | | --- | --- | | Mainnet | V2, AMM V2, V3 Core, V3 Prime | | Polygon | V2, V3 | | Avalanche | V2, V3 | | Optimism | V3 | | Arbitrum | V3 | | Scroll | V3 | | Base | V3 | | BNB | V3 | | Gnosis | V3 | | Sonic | V3 | | Linea | V3 | For each pool, ~$100 worth of each reserve will be sent to the DustBinSteward contract. The DustBin is a special contract that, as the name implies, holds a dust amount of tokens. This is done to ensure that the pools are never emptied and the PoolExposure module can operate without having to worry about possibly emptying a given reserve. If the corresponding DustBin for a specific reserve holds about ~$100 worth of the token, then that token will not be transferred. If the DustBin does not yet have that token, the mentioned amount will be sent alongside this proposal. Based on runway projections, historical swaps and future consolidation projections, the following initial budget for the SwapModule on Mainnet is proposed. | Asset | Budget (units)| | ----- | :-----------: | | USDC | 8M | | USDT | 9M | | DAI | 3M | | MATIC | 600k | | LUSD | 50k | The assets are to be used for acquiring AAVE, GHO and USDS as part of the Tokenomics upgrade and maintaining the runway. 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 Chaos Labs proposes establishing the addition of the following E-Modes: weETH/WETH Liquid E-Mode on Arbitrum, Base, and Core Instances. wstETH/WETH Liquid E-Mode on Arbitrum, Base, and Core Instances. We also propose adjusting weETH’s LTV on Base and Arbitrum to enhance user capital efficiency. weETH After carefully observing weETH’s liquidity and volatility across multiple chains, we recommend a series of changes to improve the asset’s capital efficiency. Below, we present weETH's liquidity across Ethereum, Base, and Arbitrum over the past six months. weETH's liquidity on Arbitrum has shown a strong reliance over the past six months, steadily increasing despite the recent price changes. Currently, selling 500 weETH incurs less than 2% price slippage. !image - 2025-03-23T082239.816.png weETH's liquidity on Base has remained similarly stable following an increase in the 4th quarter of 2024. Currently, selling 650 weETH incurs less than 2% price slippage. !image - 2025-03-23T082243.366.png weETH’s DEX liquidity on Ethereum has remained stable over the last 6 months, with the current sell liquidity under a 1% price impact being of 15,000 weETH. !image - 2025-03-23T082246.864.png Peg Stability Below, we analyze weETH’s peg stability during the August 5, 2024, market stress event, in which WETH fell 21%. Evaluating weETH’s exchange rate stability is critical for assessing LTV and E-mode parameters, as price deviations between weETH and WETH can lead to delays in liquidation and arbitrage-driven borrowing, impacting risk exposure. !Screenshot 2025-03-10 at 3.30.44 PM (1).png On August 5, the weETH/WETH market rate followed a similar trajectory, with a maximum deviation reaching 140 bps. While the recovery speed on both chains was comparable, Ethereum exhibited a slightly faster reversion to the internal exchange rate. On Arbitrum, the market rate took longer to revert compared to Base and Ethereum. However, all three instances demonstrated a successful recovery and quick mean reversion. LT & LTV Based on the above observations, weETH’s liquidity on Base has remained stable after recent improvements, and its ability to maintain a stable peg under stressful market conditions supports an LTV&LT increase. Therefore, we recommend increasing LTV to 75% and LT to 77%. Additionally, we propose establishing a separate weETH/WETH Liquid E-Mode with higher parameters to enhance users' capital efficiency rather than adjusting the parameters within the existing E-Mode. On Arbitrum, weETH demonstrates similar stability in liquidity compared to Base but exhibits slightly weaker peg stability than on Base and Ethereum. However, its properties are still sufficient to recommend increasing its collateral parameters to 75% and 77%, aligning them with those on Base. However, given the reduced liquidity present on the Base chain we recommend adjusting the Liquidation Bonus within the weETH/WETH E-Mode to 1.25% to mitigate the price impact caused by large highly correlated positions. wstETH Following the introduction to Liquid E-Modes with Aave v3.2, which enables targeted combinations of collateral and debt assets, we propose aligning the wstETH’s more aggressive parameters currently present on the Prime instance across all Aave deployments. Thanks to wstETH’s battle-tested stability, this change will improve capital efficiency while maintaining reduced risk. To align the LT and LTV of wstETH to those used within Prime’s E-Mode, we cover the asset's volatility and peg over multiple instances. On Base, wstETH’s liquidity against WETH has declined in recent months. However, thanks to the fast bridging speed and quick mean reversion properties, it is still sufficient to support the proposed parameters. !image - 2025-03-23T082253.225.png Its liquidity has also fallen slightly on Arbitrum, though it has been more stable in the past two months, with a 1,000 wstETH for WETH swap able to be completed for less than 1% price slippage. !image - 2025-03-23T082256.676.png Peg Stability Price deviations can cause problems like arbitrage exploitation, where, given the underlying liquidation threshold, users take advantage of price differences between the protocol’s fundamental valuation of an asset and its market price, potentially destabilizing liquidity. This can lead to WETH debt accrual and thus, in tandem with WETH collateral liquidations and withdrawals due to the underwriting of temporary mispriced debt, lead to interest rate and utilization spikes, with LST/LRT-collateralized e-mode LTVs gradually (net) increasing while WETH collateralized stablecoin debt positions risk unperformed liquidations due to such utilization rates. These deviations typically arise during periods of market stress. In such scenarios, deviations are driven by complex factors, including investor de-risking from volatile assets, liquidation cascades triggered by non-correlated positions such as stablecoin borrows against WETH, and, in rare cases, slashing events that erode confidence in an asset. The speed of reversion is generally contingent on the market priced implied duration risk associated with such a WETH-correlated asset, which can be dynamic dictated by exit queue considerations, as well as the game-theoretic value given by the fundamental robustness and on-chain liquidity of the asset itself. For this reason, to gauge the resilience of wstETH’s peg to ETH across different chains, given by the available liquidity and leverage on the chain, we analyze price behavior during the market drop that occurred on August 5, 2024, during which WETH suffered a 21% daily drop, with the rest of the market following suit and LST/LRT assets showing significant deviations. Despite that, wstETH demonstrated strong reversion characteristics across Base, Arbitrum, and Scroll. This observation indicates a high degree of stability that supports the proposed E-Mode parameters. Ethereum: On Ethereum, wstETH dropped to a minimum of 1.1531 WETH, representing a 1.85% depeg. The asset quickly returned within 0.5% from its exchange rate, showing a strong mean reversion tendency. !image - 2025-03-23T082259.823.png Base: On Base, wstETH dropped to a minimum of 1.1490 WETH, representing a 2.1% depeg. Despite this dip, the asset quickly returned to its peg, demonstrating resilience and a tendency toward mean reversion under stress. !image - 2025-03-23T082302.791.png Arbitrum: On Arbitrum, wstETH experienced a smaller depeg of 1.66%, reaching a low of 1.1550 WETH. Although this recovery was slightly slower than on Base, wstETH still demonstrated consistent mean reversion and stability. !image - 2025-03-23T082305.579.png LT and LTV The combination of robust liquidity, strong peg stability, and the inherent resilience of wstETH ensures that aligning LTV and LT parameters for the wstETH/WETH E-Mode on Arbitrum, Base and Core to the one on Lido instance is both feasible and prudent. This is because the ETH-correlated E-Mode configuration is constrained by the least liquid and least stable assets within the pool, limiting capital efficiency across the board. However, with these updated configurations, we can adopt parameters that better reflect the liquidity and stability of wstETH, allowing for higher capital efficiency in isolated E-Modes. Hence, we recommend setting the LTV at 93.5% and the LT at 95.5%. By enabling a high level of leverage, these parameters are also expected to increase demand for WETH across the chains. Collateral and Borrowable To prevent same-asset looping, which could undermine future use of liquidity incentives and lead to unintended utilization, we recommend configuring wstETH as collateral and WETH as borrowable in the proposed E-Mode. This structure aligns with the approach detailed in this post, which advocates for selective collateral and borrowing configurations to maintain market efficiency. Specification Based on the observations and considerations outlined above, we recommend implementing the following liquid E-Mode configuration for the weETH/WETH pair on Base and proposing an LTV adjustment for weETH on both Arbitrum, Base, and Core Instances. weETH/WETH E-Mode (Base) | Parameter | Value | Value | | --- | --- | --- | | Asset | weETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93% | - | | Liquidation Threshold | 95% | - | | Liquidation Penalty | 1.25% | - | weETH LT&LTV | Asset | Chain | Current LTV | Recommended LTV | Current LT | Recommended LT | | --- | --- | --- | --- | --- | --- | | weETH | Base | 72.5% | 75% | 75% | 77% | | weETH | Arbitrum | 72.5% | 75% | 75% | 77% | wstETH/ WETH E-Mode (Base) | Parameter | Value | Value | | --- | --- | --- | | Asset | wstETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.5% | 93.5% | | Liquidation Threshold | 95.5% | 95.5% | | Liquidation Penalty | 1.00% | 1.00% | wstETH/ WETH E-Mode (Arbitrum) | Parameter | Value | Value | | --- | --- | --- | | Asset | wstETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.5% | 93.5% | | Liquidation Threshold | 95.5% | 95.5% | | Liquidation Penalty | 1.00% | 1.00% | wstETH/ WETH E-Mode (Ethereum Core) | Parameter | Value | Value | | --- | --- | --- | | Asset | wstETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.5% | 93.5% | | Liquidation Threshold | 95.5% | 95.5% | | Liquidation Penalty | 1.00% | 1.00% | Disclaimer Chaos Labs has not been compensated by any third party for publishing this ARFC. Copyright Copyright and related rights waived via CC0

[TEMP CHECK] Onboard lisUSD to Aave V3 BNB Instance Author: ACI Date: 2025-03-07 --- Summary The Lista DAO team proposes that Aave lists Lista DAO’s decentralized stablecoin, lisUSD, to Aave V3 Core pool on BNB chain. Motivation Introduction 1. About Lista DAO (1) Lista DAO is the leading liquid staking and decentralized stablecoin protocol originally built on the BNB chain. Users can undergo staking and liquid staking on Lista DAO, as well as borrow lisUSD against a variety of decentralised collateral. (2) Lista DAO consists of the following major components working in conjunction: ● BNB liquid staking token: slisBNB ● Decentralized stablecoin: lisUSD ● Participate in Binance launchpool: clisBNB 1. About lisUSD lisUSD is a decentralized, unbiased, collateral backed stablecoin soft-pegged to the US Dollar. Users who have collateralized their assets via Lista DAO are eligible to take out a loan in lisUSD against their collateral. lisUSD is generated, backed, and kept stable through collateral assets that are deposited into CeVault functioning as the Lista DAO collateral vault. Currently the total lisUSD borrowed amount has reached over $62M, with over $363M collateral value, ranked as 4th largest CDP among all the chains in terms of TVL, only behind Maker DAO, Avalon and Beraborrow according to Defillama. There is already a strong ecosystem and mass adoption of lisUSD on BNB chain with the integration of major Defi protocols such as Pancake Swap, Venus, Thena, Kinza, APX, Stakestone, Solv, Lido, FDUSD, etc, the onchain liquidity of lisUSD has reached around $20M. Benefits of listing 1. Enhance liquidity on Aave Lista DAO will mint $1M lisUSD upon the approval of the proposal on Lista DAO governance , the newly minted lisUSD will specially be supplied for Aave core pool. 2. Multiple layers of yield opportunities for users Lista DAO will provide additional incentives in LISTA tokens to incentivize the supplying and borrowing of lisUSD on Aave, furthermore, users who borrow lisUSD will be able to enjoy up to 40% apr through lisUSD’s Defi integrations. 3. Innovative Defi strategies Integration of lisUSD on Aave will also allow a variety of possibilities on Defi strategies, therefore further increasing the demand for supplying and borrowing lisUSD, as a result, higher protocol fee will be generated for Aave. Specifications Details will be shared on ARFC stage. 1. lisUSD is native BEP-20 token 2. Chainlink Price Feed Contract Address of lisUSD: 0x3f5fc2cb37dA3B351F7EF968d72bE2eC3e1da08e 3. Token Address: lisUSD: 0x0782b6d8c4551b9760e74c0545a9bcd90bdc41e5 Useful Links 1. Website: https://lista.org 2. Github: https://github.com/lista-dao 3. Audit: Security | Lista Docs 4. X (Twitter): @listadao 5. Medium: Lista DAO – Medium 6. Telegram EN: Telegram: Contact @ListaDAO Disclaimer 1. This proposal is powered by Skywards. 2. The Aave Chan Initiative is not directly affiliated with Lista DAO and did not receive compensation for creating this proposal. Next Steps 1. If consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is YAE, this proposal will be escalated to ARFC stage 3. Publication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage 4. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal Copyright Copyright and related rights waived via CC0.

[ARFC] Launch GHO on Sonic & set ACI as Emissions Manager for Rewards --- title: [ARFC] Launch GHO on Sonic author: @ACI & @TokenLogic created: 2025-03-05 --- Summary This proposal aims to launch GHO on Sonic & set ACI as Emissions Manager for GHO and aGHO. Motivation GHO has gone multichain with its expansion to the Arbitrum and Base networks. As Aave continues its growth across new ecosystems, it presents a strategic opportunity to extend GHO’s reach alongside it. Sonic’s DeFi sector is currently thriving, and with Aave set to launch on Sonic in the coming weeks, deploying GHO there would be a natural next step. Sonic’s current growth is largely driven by the anticipation of its upcoming airdrop, scheduled for June. Users earn points while protocols accumulate gems based on their activity within the ecosystem. A key part of the early GHO growth strategy on Sonic will be securing liquidity in an Aave Boosted StableSurge Pool on Beethoven, a friendly fork of Balancer v3. This integration enables idle liquidity to be automatically redeployed into Aave to maximize capital efficiency. Additionally, as part of Aave’s collaboration with Balancer, these pools will receive further support, with Beethoven allocating a portion of their “gems” rewards to incentivize GHO liquidity. Just as with the Base deployment, a well-coordinated strategy is crucial for GHO’s expansion to Sonic. A successful launch will require close collaboration among service providers to build a strong infrastructure, establish appropriate risk parameters, and solidify GHO’s role as a key stablecoin within Sonic’s DeFi ecosystem. This ARFC vote seeks community consensus to move forward with GHO’s deployment on Sonic, paving the way for its continued multichain growth and deeper integration across emerging ecosystems. Specification The proposed deployment of GHO on Sonic will require coordination across several key components: |Service Provider|Responsibility| | --- | --- | |Aave Labs + BGD + Certora|Deploy CCIP & Aave Protocol Updates| |TokenLogic|Deploy Facilitator, GSM & GHO Steward Updates| |Chaos Labs + Risk Llama|GSM, CCIP & Aave Protocol Parameters| |ACI + TokenLogic|Incentive Program & Distribution| |Aave Liquidity Committee|DEX Liquidity| |Gho Stewards|Maintain Risk Parameters| ACI multisig address: 0xac140648435d03f784879cd789130F22Ef588Fcd The final timeline and technical specifications for each component will be determined by the service providers and outlined in subsequent AIPs, pending approval of this ARFC. Aave Protocol - GHO Reserve Parameters Updated proposal 2025-03-15 with Chaos feedback |Parameter|Value| | --- | --- | |Asset|GHO| |Market|Sonic| |Isolation Mode|No| |Borrowable|Yes| |Collateral Enabled|No| |Supply Cap|2,500,000| |Borrow Cap|2,250,000| |Debt Ceiling|-| |LTV|-| |LT|-| |Liquidation Bonus|-| |Liquidation Protocol Fee|-| |Variable Base|0%| |Variable Slope1|6.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| Ethereum <> Sonic Facilitator A facilitator will be deployed on Ethereum specifically to support Sonic. GHO is considered to have entered circulating supply when users exchange USDC.e for GHO via the stataUSDC.e GSM on Sonic. The initial configuration for the Sonic GhoDirectMinter facilitator as shown below: |Parameter|Value| | --- | --- | |Mint Cap|10M Units| This is to be implemented by setting the newFacilitatorBucketCapacity to to 10M. Reference: GhoDirectMinter CCIP Configuration To support the launch of GHO on Sonic, the following parameter adjustments are proposed: |Parameter|Value| | --- | --- | |Bucket Capacity|+15M Units| |Rate Limit Capacity|1,000,000 units| |Refill Rate|200 GHO/sec| The Bucket increase is additional to the Bucket Capacity at the time to ensure the GSM can be supplied with GHO. This is expected to support strong initial growth with the DAO and other expected to be moving large amounts of GHO through the bridge. Reference: GHO Deployment GSM Configuration The below provides the initial configuration of the stataUSDC.e GSM to be deployed on Sonic. |Parameter|Value| | --- | --- | |GHO Bucket Cap|10.00M| |USDC 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%| With GHO being minted on Ethereum and being transferred to the GSM, the Mint() function on the Ethereum instance of stataGSM is to be replaced by Transfer() functionality. Pre-minted GHO held by the stataGSM on Sonic is to be transferred when USDC is received. stataUSDC Revenue A bot, deployed as part of Dolce Vita will periodically claim the revenue to the DAO's treasury. GHO Stewards GhoAaveSteward updateGhoBorrowCap The update changes up to 100% upwards and downwards * Only callable by the GHO Steward updateGhoBorrowRate The update changes up to 5.0% (configurable by the DAO) upwards or downwards the following four variables: * optimalUsageRatio * baseVariableBorrowRate * variableRateSlope1 * variableRateSlope2 * The initially allowed amount of change for these variables is 5%, but is configurable by the DAO * Only callable by the GHO Steward updateGhoSupplyCap The update changes up to 100% upwards * Only callable by the GHO Steward GhoGsmSteward updateGsmExposureCap The update changes up to 100% upwards * Only callable by the GHO Steward updateGsmBuySellFees The update changes up to 0.5% upwards or downwards (in both buy and sell individually) * Asumes that strategy is FixedFeeStrategy created by FixedFeeStrategyFactory * Only callable by the GHO Steward Budget Create an Allowance for GHO on Ethereum for a total of 1,000,000 GHO from Sonic instance to support the initial growth of GHO on Sonic. ALC Ethereum SAFE: 0xA1c93D2687f7014Aaf588c764E3Ce80aF016229b Acquire GHO and deposit into Sonic instance: Ethereum aEthUSDT (1.00M) Disclosure The ACI & 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 proposal seeks governance approval for the first part of the implementation of updated Aavenomics, updating AAVE tokenomics, protocol excess revenue redistribution, deprecating LEND, and updating AAVE secondary liquidity protocol management. Motivation Before we start This proposal is the natural continuation of the [[TEMP CHECK] Aavenomics update](https://governance.aave.com/t/temp-check-aavenomics-update/18379) presented in July 2024 and approved by governance in August 2024; it is suggested that readers of the current proposals familiarize themselves with the TEMP CHECK for better context. The current proposal is focused on implementing Aavenomics and is meant to be more concise than the TEMP CHECK for improved readability. Introduction The Aavenomics update TEMP CHECK was approved around six months ago, since then, the Aave protocol reinforced it’s leadership in the Defi vertical and became the #1 Defi protocol in general. Aave's market share has increased every quarter for the past two years, and GHO crossed $200m supply with healthy revenue despite harsher market conditions at the end of Q1 2025. Every triggering milestone for implementation has been met, and Aave successfully upgraded to Aave 3.3 recently, thanks to the relentless efforts of @bgdlabs. Aave protocol revenue remains strong despite market conditions, and the "cash" portion of our Aave DAO has increased by 115% since the adoption of the Aavenomics TEMP CHECK—now sitting at $115M. This growth occurred despite having the largest budget in Aave DAO history, due to V4 financing to Aave Labs (half of the DAO service providers budget but “one-off” expense) and the Merit revenue sharing experiment (around 20% of the Aave DAO budget). While the downturn in interest rates affects the Aave DAO revenue, the protocol still maintains near-total dominance over revenue generated by lending protocols in the industry. Expected growth of revenue in 2025 High revenue and high cash reserves put Aave in a comfortable position to initiate the Aavenomics update, and current market conditions allow Aave to become even more competitive and gain market share. Most competitors do not have cash in hand to finance incentives, so they must rely on distributing their native assets; yield farmers are wary of holding these tokens and are more willing to exchange them for cash as token valuations decline in secondary markets. Aave is the only current protocol with an impeccable reputation for quality, making it the natural choice for most DeFi users even when yields are equal to or slightly lower than competitors'. Additionally, the protocol has the cash reserves necessary to distribute incentives in high-quality assets—a luxury no one else can afford in the current industry environment. Aave revenue is also expected to increase with the introduction of Chainlink-powered SVR, allowing the protocol to extract revenue while protecting users from bad debt in market downturns. This revenue—while difficult to predict since it's tied to market volatility that is inherently unpredictable—is expected to be significant (up to more than $10M/year) and can be mobilized to finance part of the Aavenomics. Another exclusive Aave perk is Umbrella. With this new self-protection system, Aave will be the only protocol able to protect users from bad debt up to billions, as competitors have essentially given up on protecting their users. This unique advantage will make Aave even more attractive, especially for institutions concerned with on-chain risks. Lastly, one "unexpected" side effect of Umbrella is the de facto commitment of liquidity that will remain in the protocol until cooldown maturity. This will secure liquidity, make potential bank run events less harmful, and, more importantly, can be mobilized to build new products and revenue streams around this "committed liquidity." Examples include cross-chain position financing and "restacking" of Aave committed liquidity for the safety of third-party protocols. Aave is well-armed to enter this strategic DeFi vertical and generate significant new revenues from it. Creation of the Aave Finance Committee and Umbrella focus We propose utilizing Umbrella as both a protective mechanism for Aave users and a growth tool by redistributing part of the Aave DAO excess revenue to Umbrella aToken stakers. We also recognize a strategic opportunity in the L2 landscape to mobilize revenue from existing networks toward L2s that are most strategic for Aave's growth. For implementation, we propose mobilizing the talent of current Aave DAO service providers to form an Aave Finance Committee (AFC). This committee will be tasked with managing Aave collector contract holdings and defining the Umbrella liquidity target ratios and budgets tailored for both safety and growth. We propose founding members who equally represent risk, growth, and treasury management, with a 3/4 signature threshold. By definition, the committee needs to be reactive to market conditions. Implementing every change on every network via AIPs is not compatible with efficient management. Therefore, we suggest that part of the AFC's mandate execution stems from token approvals done by Tokenlogic during their monthly treasury management AIPs, which will allow the committee to pull and distribute budgets as needed. This approach will also simplify implementation, as some L2 revenue is expected to be spent on other, more strategic L2s. While cross-chain bridging by AIPs is theoretically possible (and done regularly between Avalanche, Polygon & Mainnet), it remains inefficient. This is why a new Bridge Steward connecting Collectors contracts on all networks is required, and Bgd Labs will propose one shortly. This will allow Treasury management AIPs to be slightly less complex and more focused on swapping major assets and delivering token approvals, making the risk surface thinner and review more seamless. We suggest mandating both Tokenlogic and ACI to lead this AFC under the supervision and control of risk service providers who can block any potential collusion between them. Umbrella Asset Focus For efficiency and to reflect which tokens are the most strategic, borrowed and in need of Umbrella protection, we suggest focusing Umbrella on the following assets: wETH USDC USDT GHO (via StkGHO) And when needed native assets to be defined separately such as wAVAX, wS, GNO Rewards Distribution Tokens For rewards tokens, we suggest the following tokens: Sourced from RF collection: wETH USDC USDT Sourced from the Ecosystem reserve AAVE and if available, third-party funded incentives budgets. Network Implementation We suggest activating Umbrella on the following networks: Ethereum Mainnet, Core & Prime instances Avalanche Network Sonic Arbitrum Gnosis Base Aave Finance Committee funding members Chaos Labs Tokenlogic Llamarisk ACI AAVE secondary liquidity management The Aave DAO currently allocates a significant portion of the Ecosystem Reserve—approximately $27 million per year at current AAVE valuation—to secondary liquidity incentives. While AAVE's secondary liquidity remains critical for the protocol, the Umbrella upgrade has rendered the old Safety Module ready for deprecation in favor of a more efficient system. We believe we can achieve the same or even greater amounts of secondary liquidity for AAVE at a fraction of the current budget. Since one of the main goals of the Aavenomics global project is to eventually have the DAO source all AAVE distribution through secondary market buybacks, maintaining tight control over spending efficiency is crucial. Therefore, we propose gradually complementing the current StkBPT staking with a hybrid system. This new approach will continue to leverage StkBPT staking while allocating part of the budget to the current Aave Liquidity Committee (ALC). This will enable the committee to take a more hands-on approach to shaping secondary liquidity for the AAVE token. To implement this, the proposal seeks governance approval to grant the ALC a mandate for AAVE token allowance from the Ecosystem reserve, enabling them to define budgets and distribute rewards efficiently—similar to what has been achieved with GHO. Close the LEND chapter As announced multiple times over the past years and nearly half a decade after opening the LEND to AAVE migration contract, it's time to close the LEND chapter and focus on AAVE. This proposal will remove all remaining AAVE—320k tokens at the time of writing—from the migration contract and redirect them to the ecosystem reserve. Given that the community has had multiple years of notice, we consider it fair to close down the migration process. These long-dormant funds (approximately $65M at current AAVE price) will then be available to the DAO to be mobilized for growth, safety, or burn proposals by governance. Protocol excess revenue for AAVE stakers The previous elements of this proposal will impact the Aave DAO budget, yet they are not expected to significantly harm Aave protocol excess revenue. Furthermore, the growth anticipated from updates, new products, and our substantial current cash reserves makes us confident that we can initiate and maintain a "Buy and distribute" program, even in the face of recent unfavorable market conditions. The protocol has already successfully implemented and maintained a revenue redistribution program in the form of Merit for more than a year, distributing $12m/year of protocol revenue to GHO stakers at current GHO borrow rates and supply. This program is now self-sufficient and no longer financed by revenue from third-party stables, making the "Merit is forever" meme a strong reality. It's now time to increase our ambitions to match the current protocol economy and upgrade both StkAAVE & StkBPT tokenomics. This will enhance rewards to Aave ecosystem stakers with excess protocol revenue. Creation of Anti-GHO The "anti-GHO" name derives from "anti-matter." Anti-GHO is a non-transferable ERC20 token generated by AAVE and StkBPT Stakers. It is produced linearly through the Merit/MASIv system, with boosts and diluters applied, and is claimable bi-weekly by all Aave stakers. Anti-GHO can be used in two ways: Burned at a 1:1 ratio against GHO debt in the protocol (hence the "anti-GHO" name), allowing users to reduce their GHO debt in Aave at no extra cost Converted to StkGHO, which is fully eligible for Merit & other Aave incentives, and after cooldown, convertible to GHO Anti-GHO is designed to fully deprecate and replace the current GHO discount. This represents a leap forward in excess revenue distribution, as the GHO discount was only available to StkAAVE stakers who also had GHO debt in the protocol, whereas Anti-GHO will be generated by all AAVE and StkBPT Stakers. The Anti-GHO budget stems from GHO revenue generation by the protocol and scales linearly with it. A governance-defined percentage of all GHO facilitators' revenue is dedicated to minting and distributing Anti-GHO. These parameters will adjust in line with the actual protocol economy, making it both a sustainable and scalable budget tied to Aave's success. The current large DAO cash reserve provides the protocol with a comfortable buffer to maintain Merit rewards on top of Anti-GHO generation, even if the protocol economy faces pressure from a cyclical industry "bear" downturn. We propose setting the initial parameters of Anti-GHO generation at 50% of GHO revenue. At the time of writing, the GHO supply is 186M generating a 6.45% (non-discount) yield; therefore, GHO revenue is currently at $12M/year. The current proposal would generate 6M anti-GHO/year for Aave stakers. We propose distributing 80% of anti-GHO rewards to StkAAVE holders and 20% to StkBPT holders. Any slight deficit in the GHO balance sheet due to Merit & ALC budgets will be financed with excess revenue from other stablecoins in the Aave protocol, with the clear goal of reaching GHO sustainability and profitability in 2025. AAVE Buy and Distribute program The protocol still has substantial AAVE reserves. The closing of the LEND chapter will significantly contribute to these reserves. Nevertheless, we believe it's crucial to begin the journey toward long-term sustainability of the DAO's AAVE budget. This proposal gives mandate to Tokenlogic to provide token approvals to the AFC during their monthly treasury management AIPs, allowing the AFC to execute and/or work with market makers to buy AAVE tokens on secondary markets and distribute them to the ecosystem reserve. After the initial six-month period, Tokenlogic will include a quarterly buyback budget in their treasury management reports. They will size these buybacks according to the protocol's overall budget, with the objective to eventually match—and even surpass—all protocol AAVE spending. These budgets will then be converted into token approvals for the AFC to execute the buybacks. During the Aavenomics TEMP CHECK phase, it was stated that a conservative approach would be to always keep in the collector's contracts an amount equivalent to 2× the "OPEX" or Aave service providers' & incentives budget for the DAO to mitigate treasury risk in case of a prolonged market downturn and reduced protocol revenue. The service providers' budget is expected to evolve in 2025. Half of the 2024 budget went to support Aave Labs for the creation of V4—this large investment is not meant to be renewed in 2025. While we expect some compensation inflation from other service providers, we believe a $40–45M total budget (outside umbrella & buyback financing) is a credible conservative higher range scenario for the 2025 budget. While staying extremely conservative with Aave treasury funds, the ACI considers this proposal can mandate the AFC to start an AAVE buyback and distribute program immediately at the pace of $1M/week for the first 6 months of the mandate. With new upcoming revenue during 2025 from various sources, the AFC will likely be able to increase the buyback budget via a subsequent proposal. Tokenlogic has a mandate to define the tokens used to finance these buybacks according to Aave treasury holdings on a month-to-month basis. Specification This proposal can largely be executed in a single AIP, though not entirely. It provides an official mandate for committee creation and expands the ALC's scope. Execution will continue through Treasury management AIPs and AFC execution. However, ending the GHO discount and implementing Anti-GHO might require additional development and audit time depending on service providers' feedback. These elements will likely be implemented in a separate "Aavenomics Part Two" proposal. The specification for this first part of the Aavenomics implementation includes the following key technical components: Technical Implementation Details 1. Aave Finance Committee Creation: Establish a 4-member committee with a 3/4 signature threshold consisting of Chaos Labs, Tokenlogic, Llamarisk, and ACI. 2. Give mandate to Tokenlogic to implement financing of the proposed budget for the first 6 months of the Aavenomics via monthly treasury management proposals and setting token approval allowances. 3. AAVE Secondary Liquidity Restructuring: Gradually reduce the current StkBPT rewards in favor of a hybrid approach combining StkBPT staking (with no slashing element) with defined liquidity targets and partial budget allocation and distribution via AIP allowances dedicated monthly to the Liquidity Committee. 4. Protocol Revenue Redistribution: Deprecate the current StkAAVE slashing element entirely, maintain AAVE rewards, and implement a system to distribute 50% of GHO protocol revenue to StkAAVE & StkBPT stakers using the Merit/MASIv framework with Anti-GHO. Anti-GHO will be distributed monthly in sync with Merit Rewards. 5. Buy and Distribute Program: Mandate the AFC to leverage Treasury management token allowances to acquire AAVE on secondary markets and/or through MM partners, then send acquired tokens to the ecosystem reserve. The program will start with a $1M/week AAVE acquisition for the first 6 months, after which it will be sized according to the overall protocol budget with quarterly reporting. According to service provider feedback, especially @bgdlab, this might be implemented during an "Aavenomics Part Two" proposal to allow time for development and audit of these new features. 1. Anti-GHO Implementation: Create a non-transferable ERC20 token that: - Is generated by AAVE Umbrella Stakers through the Merit/MASIv system - Can be burned at a 1:1 ratio against GHO debt - Can be converted to StkGHO (eligible for Merit & other incentives) - Will replace the current GHO discount mechanism 2. LEND Migration Closure: Remove all remaining AAVE from the LEND migration contract and redirect these tokens to the ecosystem reserve, formally ending the migration process after nearly five years. The key objectives of these specifications are to optimize the DAO's AAVE distribution, improve secondary liquidity management efficiency, formalize the LEND deprecation, implement a sustainable revenue distribution model, and establish a pathway toward long-term sustainability of the DAO's AAVE budget. Disclaimer The ACI and its team hold significant staked and unstaked GHO and AAVE positions and will directly benefit from this AIP alongside, and equally to, all GHO and AAVE holders. The ACI is not presenting this ARFC on behalf of any third party and is not compensated for creating this ARFC. Acknowledgments The ACI extends its sincere gratitude to all Aave service providers, delegates, and community members who contributed to this proposal's peer review. Your expertise and insights have been invaluable in refining and strengthening this proposal. Special thanks to @BgdLabs for their crucial input on this proposal and the conception of the Umbrella Safety module. This proposal reflects the collaborative spirit and dedication of the Aave DAO. Next Steps 1. Invite community & service providers to provide feedback on this proposal with the goal of reaching consensus. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If the Snapshot outcome is YAE, give a mandate for the creation of committees, increase the scope of the current ones, and implement the rest of the proposal via AIP. Copyright Copyright and related rights waived via CC0. !image|1280x776

[ARFC] Risk Steward Parameter Updates Phase 3 Author: ACI Date: 2025-02-18 LT, LTV and Lb decreased to 0.5% 2025-03-12 ---- Simple Summary This proposal aims to update the Risk Steward parameters to enhance the efficiency of risk parameter management and reduce governance overhead. Motivation The Risk Steward mechanism has proven to be an effective tool for managing risk parameters without requiring full governance proposals. After several months of successful operation, we propose updating the parameters to allow for more responsive risk management while maintaining appropriate safety constraints. Technical service providers spend significant time reviewing risk parameter update AIPs, which could be more efficiently handled through the Risk Steward mechanism. With well-defined processes in place and months of successful operation, we can safely expand the scope of parameter adjustments allowed through this system. Specification The following parameter updates are proposed for the Risk Steward: Updated Parameters LT, LTV and LB decreased to 0.5% 2025-03-12 Supply and Borrow Caps: 100% relative change with 3 days minimum delay Debt Ceiling: 20% relative change with 3 days minimum delay LST Cap adapter params: 5% relative change with 3 days minimum delay Stable price cap: 0.5% relative change with 3 days minimum delay Base Variable Borrow Rate: 1% absolute change with 3 days minimum delay Slope 1: 1% absolute change with 3 days minimum delay Slope 2: 20% absolute change with 3 days minimum delay Optimal Point (Kink): 3% absolute change with 3 days minimum delay Loan to Value (LTV): 0.5% absolute change with 3 days minimum delay Liquidation Threshold: 0.5% absolute change with 3 days minimum delay Liquidation Bonus: 0.5% absolute change with 3 days minimum delay Security Considerations The proposed parameter updates maintain conservative limits while allowing for more efficient risk management. The minimum delay periods ensure adequate time for review and response to any changes. Implementation The implementation will require updating the RiskSteward smart contract with the new parameter constraints. Useful Links https://governance.aave.com/t/arfc-bgd-risk-steward-phase-2-risksteward/16204 Next Steps 1. Collect community & service providers feedback before escalating proposal to ARFC snapshot stage. 2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Disclaimer ACI did not received payment for the creation of this proposal. Copyright Copyright and related rights waived via CC0

[ARFC-ADDENDUM] Aave DAO & Chainlink Smart Value Recapture (SVR) Author: ACI Date: 2025-03-12 --- Summary The current proposal pretends to formalize a six-month collaboration agreement between Aave DAO and Chainlink regarding the potential integration of Chainlink’s Smart Value Recapture (or SVR) system. Motivation The DAO is currently discussing the activation of Chainlink’s SVR system in Phase 1, (as its currently being discussed at ARFC Snapshot stage) If proposal passes, SVR is expected to enhance Aave’s value recapture in liquidation scenarios, potentially generating significant additional revenue. Therefore it makes sense to formalize an agreement that would include a revenue sharing model and exclusivity to align incentives and ensure focused development on the Aave ecosystem. This proposal is an addendum of [[ARFC] Aave <> Chainlink SVR v1. Phase 1 activation](https://governance.aave.com/t/arfc-aave-chainlink-svr-v1-phase-1-activation/21247). Specification Revenue Sharing Mechanism The revenue split initially proposed will be set to: - 65% to Aave - 35% to Chainlink This distribution will be in effect for six months from the date of activation of the first SVR in Aave pools. Chainlink will send the proceeds of SVR directly to the Aave Ethereum Collector on https://etherscan.io/address/0x464C71f6c2F760DdA6093dCB91C24c39e5d6e18c, weekly or any reasonable minimal period for gas cost of the transfer being substantially lower than the value transferred Mutual Exclusivity Terms During a 3-month period: - Aave will exclusively work with Chainlink for price oracle SVR-related value recapture. - Chainlink will exclusively provide SVR services to Aave. Implementation After the 6 months period, a new ARFC can be proposed, to reassess and redefine the collaboration terms ( based on feedback, metrics, etc). Useful Links [[TEMP CHECK] Aave <> Chainlink SVR v1 integration](https://governance.aave.com/t/temp-check-aave-chainlink-svr-v1-integration/20378) [[ARFC] Aave <> Chainlink SVR v1. Phase 1 activation](https://governance.aave.com/t/arfc-aave-chainlink-svr-v1-phase-1-activation/21247) TEMP CHECK Snapshot [[ARFC Snapshot]](https://snapshot.box/#/s:aave.eth/proposal/0x29721c3f2d61a793b310720ffd671fe349b4f9603f066e0f5644a40e59549b96/discussion) Disclaimer The current proposal is powered by Skywards. ACI is not directly affiliated with Chainlink and did not receive compensation to this proposal. Next Steps 1. Escalate proposal to ARFC Snapshot. 2. If the ARFC snapshot outcome is YAE, consider the proposal canon and enforce the agreement. Copyright Copyright and related rights waived under CC0.

[TEMP CHECK] Deploy Aave v3 on Plasma Author: ACI Date: 2025-03-05 Simple Summary This TEMP CHECK 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. 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: Disclaimer This proposal is powered by Skywards. ACI is not directly affiliated with Plasma and did not receive compensation for this proposal. Next Steps Publish a TEMP CHECK in order to get initial feedback from Community and Service Providers. Escalate proposal to TEMP CHECK Snapshot. If TEMP CHECK Snapshot passes, publish an ARFC to continue gathering community and Service Providers feedback. Escalate proposal to ARFC Snapshot. 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.

2025-03-10: This post was edited to reflect @LlamaRisk and @ChaosLabs parameters recommendations. When they differ, the most conservative one was selected. Summary This publication proposes changes in the Gnosis Chain instance to improve the capital efficiency of USDC.e and sDAI assets by promoting changes on its parametrisation. Motivation The Gnosis Chain’s DeFi landscape has evolved considerably since these assets were first introduced. With a vibrant ecosystem now in place, it’s time to enhance capital efficiency, reduce capital fragmentation, and create useful debt vs no risk looping within the Aave GC instance to attract more capital and increase utilisation. USDC to USDC.e Transition: Gnosis Chain is committed to making USDC.e (the version that aligns with Circle’s standards) the defacto version of this stablecoin within its ecosystem, by accelerating the transition from USDC and making it the major market within Aave’s GC instance (replacing xDAI). To incentivise this migration and accommodate increased capital inflows, we propose the following adjustments for USDC.e: Supply and Borrowing Cap Increase: Enacted via the Risk Steward. Emode Creation: Establish an Emode pairing between USDC.e and sDAI, similar to the existing sDAI/EURe Emode. Those changes will incentivise looping strategies with USDC.e similar to those with EURe/xDAI. To further promote the transition to USDC.e, we propose reducing the LTV factor for USDC. This measure will prevent the initiation of new borrowings using USDC, thus encouraging users to adopt USDC.e. sDAI Borrowability This proposal also asks to make sDAI a borrowable asset. There is little justification for depositing xDAI into Aave on Gnosis, as sDAI offers the same risk profile. The optimal configuration, then, would be to phase out xDAI in favour of sDAI (this will be presented in a future proposal). sDAI becoming borrowable ensures a more efficient and market-driven borrowing system on the platform. Specification The tables below show the current and proposed parameters for each asset. A subsequent AIP will be submitted to implement these changes upon implementing this proposal. USDC.e |Parameters|Current|Proposed| | --- | --- | --- | |Isolation Mode|No|No| |Borrowable in Isolation|Yes|Yes| |Enable Borrow|Yes|Yes| |Enable Collateral|Yes|Yes| |Loan To Value (LTV)|75%|75%| |Liquidation Threshold|78%|78%| |Liquidation Bonus|5%|5%| |Reserve Factor|10%|10%| |Liquidation Protocol Fee|10%|10%| |Supply Cap|10M|10M| |Borrow Cap|9M|9M| |Debt Ceiling|N/A|N/A| |Optimal|90%|90%| |Base|0%|0%| |Slope1|9.5%|9.5%| |Slope2|40%|40%| |Emode|No|Yes| Create sDAI/USDC.e E-mode |Parameters|Value|Value| | --- | --- | --- | |Asset|sDAI|USDC.e| |Collateral|Yes|No| |Borrowable|No|Yes| |Max LTV|90%|90%| |Liquidation Threshold|92%|| |Liquidation Bonus|4%|| USDC |Parameters|Current|Proposed| | --- | --- | --- | |Supply Cap|11m|2m| |Borrow Cap|11m|2.5m| |Reserve Factor|25%|40%| |LTV|75%|65%| sDAI |Parameters|Current|Proposed| | --- | --- | --- | |Isolation Mode|No|No| |Borrowable in Isolation|Yes|Yes| |Enable Borrow|Yes|Yes| |Enable Collateral|Yes|Yes| |Loan To Value (LTV)|75%|75%| |Liquidation Threshold|78%|78%| |Liquidation Bonus|5%|5%| |Reserve Factor|10%|10%| |Liquidation Protocol Fee|20%|20%| |Supply Cap|48M|48M| |Borrow Cap|0|4M| |Debt Ceiling|N/A|N/A| |Optimal|90%|90%| |Base|0%|0%| |Slope1|4%|4%| |Slope2|75%|20%| |Emode|No|Yes| Disclosure karpatkey has not received payment for this proposal. karpatkey is a delegate within the Aave community. Next Steps 1. Gather feedback from the community and Service Providers. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, escalate this proposal to AIP stage Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] GHO Aave Savings Upgrade --- title: [TEMP CHECK] GHO Aave Savings Upgrade author: @TokenLogic @ACI created: 2025-03-04 --- Summary This proposal seeks governance feedback and consensus for creating sGHO and defining the Aave Savings Rate (ASR). Motivation Aave's GHO stablecoin is growing strongly during 2025 and is the 20th largest stablecoin. Whilst growth to date has been strong, growing from 200M to over 300M presents a different set of challenges requiring a different approach. To date, stkGHO launched by @ACI, rewards users for contributing to the protocol's security, has been instrumental to GHO's growth journey and currently represents 67% of GHO's circulating supply. After the Umbrella upgrade, stkGHO will remain vital to Aave Protocol's security and is expected to transition towards a size reflective of the protocol's security needs. By sizing stkGHO to reflect the Aave Protocol's security needs, this creates an opportunity for Aave to offer a variety of risk profile yield products. This presents an opportunity for the Aave DAO to introduce a new low risk profile saving product that is expected to lead the next chapter of GHO's growth and adoption. Introducing sGHO, a low risk savings product that rewards users for staking GHO by earning the Aave Savings Rate (ASR), that compounds over time. sGHO By depositing GHO into sGHO, users will earn the Aave Savings Rate by holding an ERC-20 receipt token accruing value over time which is easily integrated with other protocols. sGHO is to be sustained from revenue generated by Aave Protocol and is specifically designed to have the lowest risk profile of Aave DAO's yield product offering. The below outlines key benefits of sGHO's design: Interest compounding Aave Savings Rate; No rehypothecation providing instance liquidity; Minimal smart contract risk surface area; and, No Deposit or Withdrawal Fees. A configurable Aave Savings Rate provides the DAO with sufficient flexibility to offer either a fixed or variable savings rate that moves with the broader market conditions. Re-hypothecation To minimise risk, deposited GHO will remain in the sGHO contract and shall not be deployed to generated yield. This ensures liquidity is always available for users to withdraw and users are not exposed to any protocol risk. Whilst depositing GHO held within sGHO appears to be the most capital efficient path, this introduces some exit liquidity risks whereby GHO deposited into a protocol can be borrowed by another user. By using a facilitator to Mint and deposit GHO into the yield source, the same capital efficiency upside can be acheived in a more controlled manner. Facilitator With sGHO expected to create substantial demand for GHO, facilitators are to provide liquidity for user to access GHO. stataGSMs are to provide GHO liquidity via aggregators to avoid GHO deviating from peg whilst other facilitators support GHO being borrowed into circulating supply. New Facilitator(s) can Mint and deploy GHO to earn yield. In doing so, rather than deploying GHO held within the sGHO contract, GHO can be Minted and deployed in a controlled manner by the Gho Stewards. This approach preserves the utilisation of liquidity within reserves enabling it to be optimised for achieving a intended borrow rate and maintaining the peg. Furthermore, Minting GHO via a facilitator increases GHO circulating supply when borrowed. Overal, this approach is similar to how the Gho Stewards manage GHO and how Sky manages USDS on the Prime instance. The process of depoloying any additional GHO facilitator(s) is controlled by DAO governance and will be handled separately to this proposal. Supply Cap With each unit of sGHO being minted, the Aave DAO provides a defined amount of yield that extends the DAOs financial outlay. In isolation, as the portion of GHO held by sGHO increases, the revenue derived from GHO is distributed across the larger sGHO holding base results in either the Aave Savings Rate being revised lower, or requiring additional funding to sustain the savings rate. To facilitate processing large withdrawals from sGHO and users exchanging GHO to another asset, DEX liquidity and GSM holding balances are key to sustaining the peg. With these interwoven co-dependencies in place, a Supply Cap on sGHO is proposed. The sGHO Supply Cap will be maintained by the Gho Stewards. Fees To enhance the user experience, there are no deposit or withdrawal fees applied to sGHO. Being a yield product, creating friction via fees would act to reduce the appeal of the offering placing sGHO at a disadvantage to similar offerings available in the market. Introductin Aave Savings Rate Before reading on, a brief recap of some key terms referenced within. i) Deposit Yield = Incentive Yield + Native Yield Where, Incentive Yield = Yield derived from incentives, commonly referred to as LM rewards. Native Yield = Yield derived from fees native to Aave Protocol. Deposit Yield = Total Yield user receives. Across Aave Protocol there are two dominant stablecoins, USDC by Circle and USDT by Tether. USDT is the largest, with an emerging trend of some networks preferring to favour one stablecoin over another. Two fast growing networks, Base and Sonic both exhibit a clear bias for USDC over USDT, of which Base has generated substantial growth for Aave Protocol in recent months. When comparing the Native Yield of USDC and USDT across variaous instances Aave Protocol, USDC was found to exhibit a less volatile and more consistent Native Yield relative to USDT. USDC offers both strong market correlation and lower volaility relative to USDT, both are favourable qaulities for deriving a market correlated savings rate. The chart below shows USDT and USDC Native yield across Core instances on Ethereum, Arbitrum, Avalanche, Base and Optimism. !Screenshot 2025-02-18 at 19.11.02 When specifically comparing USDT to USDC, the chart below provides a clear visual reflecting USDCs smoother Native yield profile relative to USDT. !Screenshot 2025-02-18 at 19.15.58 The Core instance of Aave v3 on Ethereum offers the deepest USDC liquidity and for this reason, the Aave Savings Rate incorporated the USDC Native Yield Rate from the Core instance on Etheruem as its preferred Index Rate . The Aave Savings Rate definition: Aave Savings Rate = Amp x Index Rate + Premium Where, Index Rate = Representative of market conditions Amp = Amplification Factor Premium = Nominal Amount A linear function provides sufficient flexibility to curate the yield to be either variable or fixed and to change the Index Rate to which the Aave Savings Rate is correlated to. The Amp can be adjusted to offset periods of low USDC utilisation, whilst the Premium allows for a discrete amount of extra relative yield to be applied. Whilst the Aave Savings Rate is expected to exceed the GHO Borrow Rate, the differential is to be managed such that it encourages adoption whilst being insufficent to promote arbitrage. Beyond 200M GHO Growth Phase sGHO is the next step towards realising GHO's longer term growth potential, and with a very well capitalised balance sheet, Aave can accelerate the next chapter of GHO's growth potential. The introduction of the Aave Savings Rate is expected to stimulate demand for GHO that will initially improve the peg and then lead to new GHO entering circulating supply via the stataToken GSMs. During the early growth phase for GHO, significant traction was achieved by aggressively incentivising growth and then tapering rewards to retain the growth. Aave DAO is in a very fortunate financial position that is supportive of pursuing an aggressive growth strategy that captures the upside during what is a depressed yield market relative to late Q4, 2024. Launching sGHO with a premium to other similar savings products is expected to lead to significant growth whilst balancing the yield profile as to not overly encourage arbitraging the GHO Borrow Rate and Aave Savings Rate. The chart below shows sUSDe, SSR, USDC Native Yield and USDS Deposit Yield on Core instance. !Screenshot 2025-03-02 at 16.08.50 In terms of risk profile, sGHO is most similar to sUSDS offering from the Sky Ecosystem. For sGHO to compete, given its relative size, a premium would be required to attract meaningful amounts of capital. The USDS Deposit Yield realtive to the SSR highlights the premium for introducing Aave Protocol risk and the utility of being collateral. On a risk adjusted basis, the Aave Savings Rate used for sGHO would fall somewhere between the SSR and USDS Deposit Yield on Aave from a competition for capital perspective. Further details on the precise Aave Savings Rate to be used when sGHO launches will be provided in the ARFC stage of the governance process. Sustainability During the expansion phase, the Aave Savings Rate is expected to present an appealing interest rate that exceeds the GHO Borrow Rate and the Native Rate of the assets held within the stataGSMs. Especially during the early growth stage, the overal economic balance of GHO revenue and costs is going to be heavily shaped by the proportion of GHO's circulating supply deposited in sGHO. The below highlights current and near term GHO revenue sources: GHO Borrowed via Core instance; stataToken GSM holdings; and, Facilitator liquidity deposits. Borrowing GHO that has been minted by a facilitor, generates revenue for the DAO through either Borrow Interest like on Core or Native Yield plus Reserve Factor fees as on Prime. stkGHO Longer term, right sizing stkGHO reflecting the Aave Protocol's security needs, is expected to free up budget contributing to sustaining sGHO. Allocating budget from stkGHO to sGHO is exected to reduce per unit of GHO staked spend and lead to an increase in the circulating supply of GHO. This transition is expected to materially impact GHO's revenue upside. Details relating to the optimal yield and amount of stkGHO are presented in the Umbrella forum post. stataGSM The rollout of stataGSMs across Ethereum, Arbitrum and Base is expected to improve the DAO's revenue streams with currently idle capital being deployed to earn yield for the Aave DAO. On Arbitrum and Base, the GSMs will provide users with the ability to Transafer GHO into circulating Suppy. Specification This proposal is to be further refined at the ARFC stage, the following summarises the key characteristics of sGHO: No Re-Hypothecation minimising smart contract risk; Facilitators are to be used to Mint and Deploy GHO for yield; No Deposit & Withdrawal Fees promoting frictionless user experience; Introduce a Supply Cap to limit DAO's financial exposure; and, Aave Savings Rate set by GHO Stewards determines sGHO yield; Execution and implementation is to be a collaboration between by Aave DAO service providers. The Aave Savings Rate, budget and sGHO paramaters are to be finalised during the ARFC stage of the governance process. Disclosure The TokenLogic team extends its sincere gratitude to all Aave service providers, delegates, and community members who contributed to this proposal’s peer review. Your expertise and insights have been invaluable in refining and strengthening this TEMP CHECK. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, escalate this proposal to the [ARFC] stage. Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] Onboard scETH, scUSD, and scBTC to Aave V3 Sonic Instance Author: ACI Date: 2025-03-04 --- Simple Summary: We propose onboarding scETH, scUSD, and scBTC as collateral on the Aave V3 Sonic instance. We also propose making scETH and scUSD borrowable. With the launch of Sonic and increased usage and incentive programs, users are looking for looking for broader collateral options on the chain, we believe scETH and scUSD are good candidates for onboarding to meet this need. Motivation/Background: scETH, scUSD, and scBTC are created by Rings. Rings is a meta-asset for USD, ETH & BTC offering competitive yield for stakers, providing deep liquidity for Sonic DeFi, and funding Sonic DeFi projects via its lockers. Built on Veda BoringVaults and drawing inspiration from Blast’s bridge capital efficiency and Solidly’s ve(3,3) model. Rings aims to establish itself as the premier medium of exchange within the Sonic ecosystem. Benefits of listing this token: These tokens earn points from Rings, Veda, and Sonic. We believe these tokens will be popular given the popularity of leveraged point farming strategies on Aave. Chain to be deployed/listed: Sonic. Proof of Liquidity (POL) and Deposit Commitments: POL and Deposit Commitments will be discussed at the ARFC stage. Useful Links: Docs: https://docs.rings.money/ App: https://app.rings.money/ Disclaimer: This proposal is powered by Skywards. ACI is not directly affiliated with Rings and did not receive compensation for the creation of this proposal. Next Steps: 1. If consensus is reached on this TEMP CHECK, escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is YAE, escalate to ARFC stage. 3. Publication of a standard ARFC, collect community & service providers feedback. 4. If consensus is reached on this ARFC, escalate this proposal to the ARFC Snapshot stage. 5. 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] Add stS to Aave v3 Sonic Instance --- title: [TEMP CHECK] Add stS to Aave v3 Sonic Instance author: @ACI created: 2025-02-28 --- Summary The proposal aims to onboard Beets's stS, to Aave v3 Sonic instance. Motivation Launched in December 2024, Beets Staked Sonic (stS) is an ERC-20 Liquid Staked Token offering seamless exposure to Sonic network staking rewards via validator delegation, while remaining fully liquid in users’ wallets. Similar to wstETH, stS passively accrues value—each time delegation rewards are added to the staking pool, the stS-to-S exchange rate increases automatically, with no action needed from holders. The underlying S delegation enhances Sonic’s decentralization across a diverse set of validators and strengthens the network’s economic security. Previously known as sFTMx, the leading LST on Fantom Opera, stS quickly established itself as the kingmaker LST in the Sonic ecosystem, capturing over 12% of all staked S liquidity and 76% of S LST liquidity. Demand for leverage looping strategies using stS has been steadily rising, with over $160 million already deployed across other lending markets. Despite this strong demand for leveraged positions, stS has maintained a solid peg, currently trading at 99.72%. Users can easily convert their S into stS via the Beets minting UI and redeem their stS with a 14-day unbonding period. Alternatively, they can trade stS directly on any of the following DEXs: Odos Beets Shadow Current exchange rate as of 2/28/25: 1 stS = 1.0113 S Security Considerations Security is at the forefront of stS operations. Beets Staked Sonic was launched in December 2024, with its contracts originally audited by Spearbit, and then further audited by Trail of Bits in January. Beets maintains an Immunefi bug bounty of up to $200,000. Regarding Oracles stS currently integrates a Redstone, Pyth, and Stork stS/S price feed, with a Api3 and Chainlink Oracle integration currently being worked on. Aave will use a CAPO oracle leveraging chainlink's infrastructure. Beets in numbers Beets Staked Sonic has seen continuous growth since launching on December 16th 2024, with 138.65m S and $86.20m currently staked within the protocol. !image Beets Staked Sonic is growing at a steady rate and is currently the number one spot by TVL on Defillama for LST projects on Sonic, with over 3.4x as much TVL as the second largest protocol: !image Beets also runs a DEX on Sonic, resulting in it being the 2nd largest source of TVL across all protocols on Sonic: !image Points program Due to both the underlying exposure to APR (currently ~5%), and the current Sonic points program which offers 4x passive points and 8x activity points on stS, S borrows vs stS have a seen continuous growth with users seeking efficient means to leverage capital. !image Being the largest LST on the network, stS is integrated into a variety of protocol verticals, including DEXs, Vaults, Yield Tokenization, and Lending markets: Spectra Shadow Beefy Stability Vicuna Silo v2 Euler Stablejack Benefits of listing Beets Staked Sonic Adding lending and borrowing support for stS on Aave would allow users to supply, borrow, and leverage Sonic’s flagship LST. A dedicated stS market on Aave’s Sonic deployment would drive meaningful TVL growth and generate additional revenue for the Aave DAO through active S loans and liquidations. This integration would also position Aave as the go-to venue for risk-adjusted capital efficiency, enabling advanced looping strategies while providing exposure to Sonic points. It’s worth noting that Beets also operates a DEX on Sonic, powered by Balancer technology. Beets contributors operate as technical Service Providers to the Balancer DAO and have played a key role in the development and deployment of 100% Boosted Pools, which have successfully re-hypothicated over $50M in liquidity to Aave. With the launch of Aave on Sonic, Beets will deploy Aave Boosted Pools, creating a highly efficient mechanism for simultaneously growing Aave’s supply-side liquidity and strengthening Sonic Swap markets. Alongside stablecoin liquidity such as USDC.e, scUSD and GHO, an stS | S Boosted Pool would likely see strong adoption from Sonic users—helping bootstrap supply while keeping borrowing costs low in leverage markets. Proof of Liquidity (POL) and Deposit Commitments As mentioned, Beets can deploy Aave Boosted Pools to help seed Aave’s capital markets on Sonic. While Beets would not directly supply stS or S POL to Aave, it would deposit POL from the DAO treasury into these pools, effectively routing 100% of capital straight to Aave. Additionally, Beets is in discussions with Sonic Money Managers regarding the bootstrapping of the stS market through stS <> S looping strategies, as well as Boosted Pool POL deposits. Specific amounts will be determined in collaboration with the Aave team and the ACI, with further details to be shared during the ARFC stage of the proposal process. Risk Parameters will be provided by Risk Services Providers at the earliest possible and ARFC will be updated with that feedback. Useful links Beets Website Beets Staked Sonic stS Analytics Docs Github Beets Staked Sonic Contract Spearbit Audit Trail Of Bits Audit Blog Discord Twitter Disclosure The ACI is not directly affiliated with Beets and did not receive compensation for creation this proposal. Next Steps 1. If consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is YAE, this proposal will be escalated to ARFC stage. Publish a standard ARFC, collect 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 Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] Add USR to Aave v3 Core Instance --- title: [TEMP CHECK] Add USR to Aave v3 Core Instance author: @ACI & @TokenLogic created: 2025-03-03 --- Summary The proposal aims to onboard Resolv's USR, to Aave v3 protocol Core Market on Ethereum. Motivation Introduction Resolv is a decentralized protocol designed to maintain and manage USR a over-collateralised USD stablecoin backed by a delta-neutral ETH denominated strategy, alongside the Resolv Liquidity Pool (RLP), which acts as a liquid insurance reserve ensuring USR remains overcollateralized. Resolv has been one of the latest growing stablecoins from last few months with TVL surging from 37M in December to now over 675M at the moment and with a USR circulating supply of 570M. Resolv is currently running an ongoing points campaign, with Season 1 set to conclude between the end of Q1 and Season 2 set to begin during Q2. As part of this campaign, wstUSR holders earn 5 points per wstUSR held daily. Mint / Redeem USR is minted using USDT or USDC at a 1:1 ratio, with minting fees currently set to zero but subject to future adjustments. Users can stake USR to receive wstUSR, which is the wrapped version of stUSR, to earn rebasing staking rewards. USR can also be redeemed back into USDC or USDT, with redemptions currently processed without fees. The redemption process, though infrequent, averages approximately 1 hour and 50 minutes per transaction, with a maximum stated duration of 24 hours. At present, minting and burning functionalities are limited to whitelisted addresses. USD and RLP Relationship Of the revenue generated, 30% is allocated to RLP holders who absorb any losses whilst insuring USR remains over-collateralised. RLP is valued at 99.3M USD, which compares to $558.7M in USR at the time of writing. Further details are visibile on this Dune Dashboard. Specification Ticker: USR Contract address on mainnet: 0x66a1E37c9b0eAddca17d3662D6c05F4DECf3e110 Chainlink oracle: upcoming Project: https://resolv.xyz/ Collateral pool addresses: https://app.resolv.xyz/overview GitHub: https://github.com/resolv-im Docs: https://docs.resolv.xyz/litepaper Audit: https://docs.resolv.xyz/litepaper/resources/security Twitter: https://x.com/resolvlabs Risk Parameters will be provided by Risk Services Providers at the earliest possible and ARFC will be updated with that feedback. Disclosure The ACI and TokenLogic are not directly affiliated with Resolv and did not receive compensation for creation this proposal. Next Steps 1. If consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is YAE, this proposal will be escalated to ARFC stage. Publish a standard ARFC, collect 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 Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] Add wstUSR to Aave v3 Core Instance --- title: [TEMP CHECK] Add wstUSR to Aave v3 Core on Ethereum author: @ ACI & @TokenLogic created: 2025-03-03 --- Summary The proposal aims to onboard Resolv's wstUSR, to Aave v3 protocol Core Market on Ethereum. Motivation Resolv is a decentralized protocol designed to manage USR, a stablecoin backed by a delta-neutral, ETH-denominated strategy. To ensure USR remains overcollateralized, Resolv operates the Resolv Liquidity Pool (RLP), which serves as a liquid insurance reserve. Details relating to onboarding USR can be found here. wstUSR is the wrapped version of stUSR, staked USR. wstUSR, like wstETH is designed for better compatibility with DeFi protocols. 42.65% of USR on Ethereum is staked and further insights are available on this Dune dashboard. Staked USR holders receive 70% of the Base Rewards from the Collateral Pool which consists of the ETH, USDC and USDT used to mint USR. Collateral Pool The Collateral Pool holds the assets backing USR and is structured to generate yield while mitigating exposure to ETH price fluctuations by employing hedging strategies similar to those used by Ethena. 70% of the Base Reward generated by the Collateral Pool are directed to staked USR holders. The other 30% is allocated to the insurance like asset RLP. The composition of the Collateral Pool ($653.65M) is majority ETH-correlated ($582.65M), 56.8% of which is wstETH, and the remainder ($71.00M) held in stablecoins. The assets are currently allocated as shown below: 55.1% held in on-chain treasury 24.7% secured in institutional custody—leveraging Ceffu for Binance collateral and Fireblocks for Deribit; and, 20.2% is allocated to exchanges, including Binance Hyperliquid and Deribit. Furthermore, to efficiently manage short-term liquidity demands, such as redemptions or margin requirements, Resolv utilizes Aave v3 on Ethereum to borrow WETH against wstETH. !Screenshot 2025-02-23 at 14.31.38 At the time of writing, the Collateral Pool is generating a return of 5.69% and staked USR is providing a 7.12% return to stakers. Ongoing Points Campaign Resolv is currently running a points-based incentive campaign, with Season 1 scheduled to conclude between the end of Q1 and the beginning of Q2. As part of this initiative, wstUSR holders earn 5 points per wstUSR held daily, providing an additional incentive for participation. Specification Ticker: wstUSR Contract address on mainnet: 0x1202F5C7b4B9E47a1A484E8B270be34dbbC75055 Chainlink oracle: upcoming Project: https://resolv.xyz/ Collateral pool addresses: https://app.resolv.xyz/overview GitHub: https://github.com/resolv-im Docs: https://docs.resolv.xyz/litepaper Audit: https://docs.resolv.xyz/litepaper/resources/security Twitter: https://x.com/resolvlabs Risk Parameters will be provided by Risk Services Providers at the earliest possible and ARFC will be updated with that feedback. Disclosure The ACI and TokenLogic are not directly affiliated with Resolv and did not receive compensation for creation this proposal. Next Steps 1. If consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is YAE, this proposal will be escalated to ARFC stage. Publish a standard ARFC, collect 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 Copyright Copyright and related rights waived via CC0.

Simple summary Proposal for the community to pre-approve the final activation/configuration of SVR (Smart Value Recapture) oracles on a sub-set of Aave v3 Core Ethereum assets, a system created by Chainlink to recapture MEV from Aave liquidations and return it to the Aave ecosystem. Context As described in the TEMP CHECK stage, this proposal seeks the community’s approval to integrate Chainlink’s SVR v1 system. Extensive details about its rationale and specifications can be found on Snapshot and the associated governance forum. This ARFC delves more into the proposed initial configuration details of the initial phase (Phase 1). Specification To recap, the architecture of the new Chainlink SVR feeds to be connected to Aave is as follows:!svr-diagram-arfc.jpg In the integration side of Aave, there are two major components to take into account: SVR Feed. This will be the one plugged into the Aave Oracle smart contracts (with the necessary CAPO adapters on top if applicable), receiving the OEV-recapturing price on-chain. Fallback feed. This is a mirror of the “standard” price feeds currently plugged into Aave, without OEV recapture. The SVR Feed has a configurable delay fallback in seconds: as both SVR and Fallback feeds get submitted to their respective mempools in parallel, whenever the OEV doesn’t reflect on-chain for more than the delay fallback seconds but the Fallback does, the price reading is routed to the Fallback feed. The fallback mechanism is completely fundamental security-wise, as it gives one important assurance: on average, the price availability of the overall system will be equal to or superior to the current feeds, but even in the worst-case scenario, the maximum delay to read from a “standard” Chainlink feed will be of the configured delay fallback seconds. Initial assets configuration: controlled approach Even considering that the technology (Chainlink, Flashbots) is battle-tested, and the protection mechanisms embedded into SVR like the fallback, we believe the rollout of feeds should be progressive, only enabling a very limited subset of assets on v3 Core Ethereum during the first month or so. From our discussions with Chainlink, we think the following principles for choosing the initial assets are reasonable: The assets consuming the feeds should have a meaningful volume of historic liquidation. The majority of liquidations happening on positions consuming the chosen feeds should be due to those feeds, and not due to other assets. E.g. in positions using AAVE as collateral and borrowing USDC, the majority of liquidations happen due to the AAVE/USD price feed updates on the collateral side, as the USDC/USD feed barely changes. In this first activation batch, major assets size-wise should be avoided: ETH, wstETH, WBTC, weETH. Ideally, we plug in production feeds that will affect assets correlated with major ones, but smaller in size. Both tBTC and WBTC use the hood of the same BTC/USD feed, but the first is ~$82m in size versus the second ~$3b. With the previous principles in mind, and also taking into account the extensive testing/simulations performed by Chainlink in their infrastructure during the previous couple of months, the recommendation is to enable the following SVR feeds: BTC/USD affecting exclusively LBTC and tBTC. AAVE/USD. LINK/USD. Other configurations: fallback delay and its nuances When choosing specific values per asset for a fallback delay, there are different points of consideration: The fallback delay is a mechanism that will not be used on the “happy” path: when the Chainlink DON submits prices to the Flashbots auction, historical analysis shows that the majority of price updates (and so liquidations) are included in the next block, and close to 100% in the range of 1-2 blocks. That means that price reading being redirected to the “public” feed will only happen if a fallback delay is configured to less than 2 blocks (in seconds), or in very edge scenarios when auction participants don’t show up for more than 2 blocks, even if economically sound. Aside from the auction aforementioned average auction speed of 0-2 blocks, configuring too low (e.g. 2 blocks) the fallback delay opens to an edge, but theoretically existing censorship vector: it could be profitable for a builder with control to build the +2 block from next on the public mempool to censor the price update on the 2 blocks on the Flashbots auction, to wait for their to-be-mined block on the public mempool. Again, this vector is very theoretical but technically exists whenever the fallback delay is very short. Any increase in the fallback delay configuration makes the censorship vector exponentially more expensive, as the cost of “capturing” multiple blocks in a row gets increasingly more expensive, Aave is configured very conservatively risk-wise, which means that the difference of processing a liquidation in the same block of price update versus some blocks after doesn’t put the system at all at risk. This will not really be the case on the average scenario of the price being included into the block via Flashbots, as it will precisely incentivise as fast as possible inclusion, but it is a consideration to not configure the fallback delay too tigh, avoiding any type of censorship attack, even if very theoretical. Considering the previous rationale, and also using historical analysis from Chainlink showing that there will be no loss on the risk profile of the protocol, the recommendation is to set the fallback delay on BTC/USD, AAVE/USD and LINK/USD to 5 blocks. The Aave DAO via its risk provider will reserve executive power over modifying this parameter by communicating to Chainlink. Extra protection: SvrOracleSteward Given the criticality of the infrastructure activation, and to be even extra cautious, we also propose to include a new steward smart contract: the SvrOracleSteward. The SvrOracleSteward allows for the Aave Protocol Guardian to replace, on the Aave Oracle side, a feed (e.g. CAPO) consuming one the new SVR by exclusively one used before the SVR replacement. This way, even in the very unexpected worst-case scenario of the new SVR simply not being functional or having a really major issue, the Aave Protocol Guardian could immediately swap back to the standard price feeds currently used in production. We don’t expect this mechanism to be used anyhow, but we think it is reasonable as an extra line of defense when enabling a pretty innovative system like SVR v1 Chainlink. OEV-recaptured recipient When using systems like Flashbots for a case like this of SVR, it is necessary to define an address to receive the native currency (e.g. ETH) recapture. Ideally, the Aave DAO would have full control over this address, but in practice, as the Chainlink DON is the entity factually building the transaction and submitting it to Flashbots, they have control over configuring it or changing it. The Aave protocol already has a RevenueSplitter smart contract to be used as OEV beneficiary, for any non-100%/0% split between Aave and Chainlink. But given that using it or not is a purely operational consideration (as still Chainlink can change it unilaterally), we will coordinate with them to decide whats the most reasonable venue. In any scenario, the final recipient of the OEV fees should be the Aave Collector, and we consider mandatory that distribution to it happens minimum once a week, no matter if via RevenueSplitter or via transfer from the Chainlink side. Aave/Chainlink fee split terms Similar to any other terms of the Aave <> Chainlink SVR partnership, it is outside of the scope of this ARFC to define the percentage of a split between Aave and Chainlink on the OEV recapture, as we (BGD) are technical service providers, and the community should vote on the configuration separately from those. We will abide by any decision approved by the DAO via ARFC, configuring any technical component accordingly.

[ARFC] Recognize HyperLend as a Friendly Fork Author: ACI Date: 2025-02-18 Proposal updated to reflect latest changes on negotiations 2025-03-07 --- Summary This proposal seeks to recognize HyperLend as a friendly fork of Aave, deployed on the Hyperliquid EVM chain (HyperEVM), after successful TEMP CHECK and TEMP CHECK Snapshot. Motivation HyperLend aims to support Aave’s ecosystem by sharing 10% of its protocol revenue with the Aave DAO and allocating 3.5% of its token supply to the DAO treasury. Additionally, 1% of the total supply will be airdropped to stAAVE holders, ensuring alignment with Aave’s community and stakeholders. About HyperLend: Beyond core multi-asset lending pools, we will have isolated pools to support riskier assets, and we are working with vault curators to create optimized yield strategies on top of our markets. Additionally, HyperLend will tokenize the HLP vault and perpetual positions, which will be available as collateral in the isolated pools. This will position HyperLend as the leading lending protocol on HyperEVM, driving liquidity and composability within the ecosystem. We are currently deployed on HyperEVM testnet (using MIT-licensed v3.0.2 codebase), with over 200k total users (10-20k daily, excluding known sybils). We are working with Block Analitica as our risk manager, had additional audits done by Ackee, Cantina, and Pashov, and have partnered with Resolv, Swell, ThunderHead, Stargate, RedStone, Pyth, Theo and more. By formally recognizing HyperLend as a friendly fork, Aave DAO can establish a mutually beneficial relationship with us, capturing additional value for the DAO and AAVE token holders, while allowing HyperLend to use its secure & battle-tested codebase. Specification We propose that HyperLend: share 10% of the revenue (derived from the Aave codebase*) with the Aave DAO (either distributed monthly or by using RevenueSplitter contract) distribute 3.5% of the HyperLend (HPL) token supply to the Aave DAO (at TGE) distribute 1% of the HPL token supply to stkAAVE holders (at TGE) revenue from isolated pools, P2P, and non-lending aspects of the protocol (such as potential tHLP fees) is excluded In return, Aave DAO should: Grant HyperLend the license to use the Aave codebase. In this sense, license to use the prior most recent release of Aave V3 (3.3) and any fix that could create functional or security issues with said version. License will be limited to Hyperliquid EVM only. Disclaimer: This proposal is powered by Skywards. The ACI is not directly affiliated with Hyperlend and did not receive any compensation for creating this proposal. Next Steps 1. Publication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. 2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived via CC0.

[ARFC] Orbit Program Renewal - Q1 2025 Author: ACI (Aave Chan Initiative) Date: 2025-02-27 --- Summary Proposing the renewal of the Orbit program for recognized delegates, compensating them with GHO, associated with their governance activity during Q1 2025 ( From 2024-12-14, last date, until 2025-03-31). 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, Q1 2025, from 2024-12-14 to 2025-03-31. From now on, all renews will be applied strictly by Quarters, and a new cutoff has been set on 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: Q1 2025 from December 14th 2024 to March 31st 2025 Eligible Platforms: - EzR3al: 0x8659d0bb123da6d16d9394c7838ba286c2207d0e - areta: 0x8b37a5af68d315cf5a64097d96621f64b5502a22 - stablelabs: 0xecc2a9240268bc7a26386ecb49e1befca2706ac9 - IgnasDefi: 0x3DDC7d25c7a1dc381443e491Bbf1Caa8928A05B0 Budget: 60,000 GHO (aEthLidoGHO) - 15k total budget per platform - 15000 aGHO stream through 80 days Relevant Links: - ACI’s Orbit tracker Additional considerations: As a reminder, Service Providers will not be considered elegible to Orbit Program. A new vote rate cutoff will apply, starting next Orbit Renewal, where a minimum of 20k voting power and 85% vote ratio on all Snapshots and AIP will be considered in order to be elegible to Orbit Program, from AIP 224. 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)

Simple summary Introducing a new Aave ClinicSteward smart contract, with capabilities to liquidate and repay non-healthy positions with bad debt on Aave v3, using funds of the Aave Collector, this way cleaning up all Aave v3 bad debt before the activation of the upcoming Umbrella. Context Since the initial Aave v3 activation three years ago, due to the nature of liquidations, the system has accrued a minimal bad debt of approximately $400’000. This amount is pretty irrelevant in comparison with the ~$12 billion outstanding borrowings, but given the imminent activation of the Umbrella system (to automatically cover bad debt), and the recent upgrade of Aave to v3.3 (formally accounting for deficit/bad-debt post-liquidation), we believe it is appropriate to raise a proposal to clean the “legacy” bad debt, and this way start with clean accounting. The Aave ClinicSteward is a smart contract that simply facilitates for a permissioned entity to execute the clean-up on behalf of the DAO, by authorizing a constraint budget from the Aave Collector for exclusive usage on liquidations/repayments of unhealthy positions (liquidatable). Specification The Aave ClinicSteward is a highly permissioned and constraint steward smart contract, that allows for the following: Batch liquidate. Allows to liquidate positions on the configured Aave Pool, by pulling the asset to repay from the Aave Collector, and transferring the liquidated collateral back to the Collector too. Batch repay. On Aave v3 there are some existing positions pre-Aave v3.3 with “pure” bad debt: they have outstanding borrowings, but exactly zero collateral. For those cases, this steward contract allows to just repay and zero that debt, even if no collateral is recovered. In terms of access control, the system is permissioned in the following way: To be able to access any funds from the Aave Collector, the Aave governance needs to give FUNDS_ADMIN role to each ClinicSteward associated with an Aave v3 pool. There is a strict budget constraint (in USD) for the amount the steward can pull from the Collector (table after). A DEFAULTADMINROLE acts as “a super-admin” of the steward, with permissions to enable any other address to call the batch liquidate and batch repay methods. This is designed to be assigned to a multi-sig smart contract, which in our opinion could be one of the denominated currently composed by ACI, TokenLogic and Kpk, with 2-of-3. Given that the initial setup via governance will assign one initial CLEANUP_ROLE, we don’t expect this multi-sig to be used. A CLEANUP_ROLE acts as the address that will factually trigger the liquidations/repayments. This is designed to be an EOA, given that its capabilities are limited by: - The DEFAULTADMINROLE granting permissions. - The steward contract has a constraint of maximum budget (in USD) to spend, which only the Aave governance can modify. Our recommendation is to use an EOA of the Dolce Vita service by ACI for this role, already in use for multiple other aspects now and in the past (migration of deprecated stable debt positions, accrue of fees to the treasury, etc). The contract is not designed to have any funds at rest, so it has Rescuable capabilities to send any token there to exclusively the Aave Collector. --- In terms of budget constraints per network (maximum allowance that the ClinicSteward will be able to use from the Collector), the idea is to be able to cover current levels of bad debt per network, with some extra margin on top. This allowance can be potentially renewed in the future, but only via another Aave governance proposal. | Network | Maximum allowance | | --- | --- | | Ethereum core | $30’000 | | Ethereum prime | $5’000 | | Polygon | $30’000 | | Avalanche | $350’000 | | Arbitrum | $60’000 | | Optimism | $5’000 | | Base | $15’000 | | Metis | $1’000 | | Gnosis Chain | $1’000 | | BNB Chain | $2’000 | | Scroll | $1’000 | | ZKSync | $1’000 | | Linea | $1’000 | *Total expenses will potentially be substantially lower than “Maximum allowance”, as in the majority of the cases, some collateral will be sent to the Collector, even if this is lower than the debt of the position. v3 Avalanche being substantially higher than in other networks is due to the USDC de-peg event on 11th March 2023 In addition to all its constraints, the ClinicSteward is been audited by Certora, and we will share the report on the Aave governance forum once completed.

[ARFC] Onboard rstETH to Aave V3 Prime Instance Author: ACI (Aave Chan Initiative) Date: 2025-01-07 ARFC updated with Risk Parameters provided by Chaos 2025-03-03 ---- Summary This is an ARFC to gauge community sentiment for onboarding P2P’s rstETH on AAVE V3 Ethereum. To align best with goals of all relevant stakeholders, this proposal suggests onboarding rstETH to the Aave v3 Prime instance. Motivation Adding rstETH to the Aave v3 Prime instance brings additional synergies for all stakeholders. rstETH will add additional demand for wstETH borrowing, making the wstETH looping more favorable for the main users. Incentives from P2P can bring additional wstETH liquidity to the Prime instance, bolstering the existing liquidity mining campaigns. Chain to be deployed/listed Aave v3 Prime instance on Ethereum Proof of Liquidity and Deposit Commitments Additional information of any potential Proof of Liquidity and Deposit Commitments will be provided during ARFC stage. Specification rstETH: https://etherscan.io/address/0x7a4EffD87C2f3C55CA251080b1343b605f327E3a Risk Parameters: E-Mode Category: rstETH/wstETH | Parameter | Value | Value | | --- | --- | --- | | Asset | rstETH | wstETH | | Collateral | Yes | No | | Borrowable | No | Yes | | LTV | 90% | - | | LT | 93% | - | | Liquidation Penalty | 1% | - | rstETH Risk Parameters (Non E-mode) | Parameter | Value | | --- | --- | | Asset | rstETH | | Isolation Mode | No | | Borrowable | No | | Collateral Enabled | Yes | | Supply Cap | 5000 | | Borrow Cap | - | | Debt Ceiling | - | | LTV | 0.05% | | LT | 0.1% | | Liquidation Penalty | 7.5% | | Liquidation Protocol Fee | 10.00% | | Variable Base | - | | Variable Slope1 | - | | Variable Slope2 | - | | Uoptimal | - | | Reserve Factor | - | | Stable Borrowing | Disabled | | Flashloanable | Yes | | Siloed Borrowing | No | | Borrowable in Isolation | No | | E-Mode Category | rstETH/wstETH | | MINIMUMSNAPSHOTDELAY | ratioReferenceTime | maxYearlyRatioGrowthPercent | | --- | --- | --- | | 7 days | monthly | 9.68% | Useful Links P2P Documentation Github [[TEMP CHECK] Onboard rstETH to Aave V3 Prime Instance](https://governance.aave.com/t/temp-check-onboard-rsteth-to-aave-v3-prime-instance/20255) TEMP CHECK Snapshot Disclaimer The Aave Chan Initiative is not directly affiliated with P2P and did not receive compensation for creation this proposal. Next Step 1. Publish a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. 2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived under CC0.

[ARFC] Onboard tBTC to Aave v3 on Arbitrum Authors: @Ethan - Threshold Network Growth Coordinator & @mcitizen42 - Contributor to Threshold Network Date: 2024-11-11 --- ARFC has been edited by ACI to reflect latest risk parameters provided by Risk Service Providers 2025-02-27 Summary This proposal seeks to onboard tBTC to Aave v3 on Arbitrum following a successful launch on Mainnet (https://app.aave.com/reserve-overview/?underlyingAsset=0x18084fba666a33d37592fa2633fd49a74dd93a88&marketName=protomainnetv3). Motivation/Background tBTC is Threshold’s decentralized and permissionless bridge to bring BTC to Ethereum, Arbitrum and 6 other chains. Users wishing to utilize their Bitcoin on Ethereum & Arbitrum 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 brought native minting of tBTC to Arbitrum, is live on GMX and has strong, sticky liquidity to support liquidations. Following its approval on AAVE V3 Ethereum, tBTC’s initial supply cap was reached within 72 hours, prompting an increase to meet the overwhelming demand and now sits at over 1,000 BTC TVL. This rapid adoption underscores the market’s appetite for trust-minimized BTC solutions in DeFi. 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 Arbitrum. Easy, direct onboarding of BTC capital via Threshold’s Arbitrum native minting. 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: Arbitrum: 0x6c84a8f1c29108f47a79964b5fe888d4f4d0de40 Chainlink Oracle: Arbitrum: 0xE808488e8627F6531bA79a13A9E0271B39abEb1C ARFC has been edited by ACI to reflect latest risk parameters provided by Risk Service Providers 2025-02-27 | Parameter | Value | | --- | --- | | Isolation Mode | No | | Borrowable | No | | Collateral Enabled | Yes | | Supply Cap | 50 | | Borrow Cap | 25 | | Debt Ceiling | - | | LTV | 73% | | LT | 78% | | Liquidation Bonus | 7.5% | | Liquidation Protocol Fee | 10% | | Variable Base | 0% | | Variable Slope1 | 4% | | Variable Slope2 | 300% | | Uoptimal | 45% | | Reserve Factor | 20% | | Stable Borrowing | Disabled | | Flashloanable | No | | Siloed Borrowing | No | | Borrowable in Isolation | No | Useful Links: Project: https://www.threshold.network/ Minting dashboard: https://dashboard.threshold.network/tBTC/mint GitHub: https://github.com/keep-network/tbtc-v2 Docs: https://docs.threshold.network/applications/tbtc-v2 Audit: https://threshold.network/about#audits Immunfi Bug Bounty: https://immunefi.com/bounty/thresholdnetwork/ Llama Risk Report: Collateral Risk Assessment: Threshold BTC (tBTC) - HackMD 4 Twitter: https://twitter.com/thetnetwork Discord: https://discord.gg/threshold Dune: https://dune.com/threshold/tbtc, https://dune.com/sensecapital/tbtc-liquidity & https://dune.com/lrsaturnino/tbtc-on-arbitrum What is the link between the author of the AIP and the Asset? Threshold Network has no link and is not compensated to present this ARFC proposal. Provide a brief high-level overview of the project and the token. tBTC is a decentralized wrapped Bitcoin that is 1:1 backed by native BTC. Unlike other wrapped Bitcoins, the BTC that backs tBTC is not held by a central intermediary, but is instead held by a decentralized network of nodes using threshold cryptography. tBTC is trust minimized and redeemable for native BTC without a centralized custodian. It can be used across the entire DeFi ecosystem. tBTC can be used as collateral, liquidity, a store of value, and can be integrated with DeFi apps across all supported blockchains. As with other BTC wrappers, tBTC provides cryptocurrency traders and general users with a BTC-pegged token, that can be used to generate yield whilst holding native BTC. Explain the positioning of the token in the AAVE ecosystem. Why would it be a good borrow or collateral asset? Adding support for tBTC on Aave v3 (Arbitrum) as an asset would allow tBTC holders to obtain a yield on their tBTC holdings. tBTC is the only way to permissionlessly borrow and lend BTC in a decentralized manner. This gives Aave direct access to the 1.7 trillion market of BTC, for which centralised competitors provide limited access to. Provide a brief history of the project and the different components: DAO (is it live?), products (are they live?). How did it overcome some of the challenges it faced? tBTC was created by a decentralized effort of contributors at the Threshold Network DAO, and extensively utilizes the Threshold Network’s threshold cryptography to create a secure BTC asset. tBTC is a product launched on Threshold Network, on which many other decentralized applications are being built. Threshold Network DAO was born out of the first on-chain merger between two decentralized protocols, Keep Network and NuCypher early in 2022. The DAO has successfully operated since that time, and supports an active community of contributors that work towards building tBTC liquidity and usability. How is tBTC currently used? tBTC is used across a variety of chains and use cases. Some key utlities include Aave, GMX, EigenLayer, Synthetix, Morpho, Symbiotic, collateral asset for crvUSD, thUSD and solvBTC. A comprehensible list can be found here: https://defillama.com/yields?token=TBTC 4 & https://linktr.ee/earnyield Emission schedule tBTC is one-to-one backed with real Bitcoin, meaning that there isn’t an emissions schedule, but a mint and redeem function that adjusts the supply of tBTC based on native BTC coming into and out of the system. Token (& Protocol) permissions (minting) and upgradability. Is there a multisig? What can it do? Who are the signers? For tBTC, wallets are created periodically based on governance. In order for the wallet to move funds, it produces signatures using a Threshold Elliptic Curve Digital Signature Algorithm, requiring 51-of-100 Signers to cooperate. The 100 signers on each wallet are chosen with our Sortition Pool, and the randomness is provided by the Random Beacon. More can be found here - Wallet Generation | Threshold Docs 2 The Threshold Council multisig is a 6/9 Gnosis Safe multisig with 9 unique signers that form the Threshold Network Council. The Council has limited upgrade privileges over the smart contracts. However, those privileges do not include any custodial power over deposited BTC: Council Multisig Ethereum Address: 0x9F6e831c8F8939DC0C830C6e492e7cEf4f9C2F5f Market data (Market Cap, 24h Volume, Volatility, Exchanges, Maturity) Market capitalisation: $350m USD / 4,286 BTC Decentralized exchange liquidity pools: https://defillama.com/yields?token=TBTC Dashboard on Decentralized LP liquidity: https://dune.com/sensecapital/tbtc-liquidity & https://dune.com/lrsaturnino/tbtc-on-arbitrum Social channels data (Size of communities, activity on Github) Discord: 9,191 Twitter: 37,900 Github: 4,596 commits Contracts date of deployments, number of transactions, number of holders for tokens Date of Deployment: February 2023 Number of transactions: 74,721 Number of token holders: 1,665 Risk parameters We suggest waiting for the feedback from risk teams for suggested parameters. Symbol: TBTC Arbitrum Contract Address: 0x6c84a8f1c29108f47a79964b5fe888d4f4d0de40 Disclaimer: This proposal is powered by Threshold Network. The authors are @Ethan (Growth Coordinator for Threshold Network) and @mcitizen42 (Contributor to Threshold Network). Next Steps: 1. If consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is positive, this proposal will be escalated to the Aave AIP stage for final confirmation and enforcement of the proposal. Copyright: Copyright and related rights waived under CC0.

Summary This framework outlines a general approach for utilizing GHO as the gas token of a network. The framework is designed to be adaptable for any network looking to use GHO in this capacity. Unlike bridging GHO as an ERC-20 token, this framework establishes a structured approach to integrating GHO as a gas token through a native bridge. The framework uses the canonical network bridge for minting GHO as a gas token. It also explores extensions such as integrating messaging protocols like Chainlink CCIP to align with the existing GHO cross-chain strategy. Additionally, a wrapper contract on Ethereum allows the GHO implementation to be upgraded and extended for future innovations. Motivation Stablecoins offer a fast, efficient, and stable means of transferring value on blockchain networks. Decentralized stablecoins like GHO add transparency and censorship resistance. Using GHO as a gas token makes it a core part of the network’s transaction layer, allowing it to function as a standard economic unit. This creates predictable pricing for gas fees, particularly in low-fee networks where transaction costs are often subsidized. The decision to use a canonical bridge as the primary liquidity pool is based on the unique requirements of deploying GHO as a gas token rather than as a bridged ERC-20, and ties security of token bridging to the underlying network bridge. Messaging protocols generally work with ERC-20 transfers, meaning a custom implementation would be required for network gas tokens. A native bridge allows for a more streamlined approach, embedding gas token bridging into the network’s primary liquidity bridge and does not introduce new attack surfaces or security assumptions. The framework can be made compatible with Aave’s broader GHO cross-chain strategy by integrating messaging protocols into the native bridge, aligning with the existing cross-chain implementation, where Chainlink CCIP is the canonical messaging layer for GHO as an ERC-20 token. Specification The framework defines the architecture for adopting GHO as a gas token across L2 networks. It outlines how the native bridge operates as the primary liquidity pool for GHO minting, embedding security and liquidity management directly into the network’s base infrastructure. The approach limits fragmentation across multiple bridges and reduces dependency on external liquidity providers. Future governance decisions could introduce more granular controls over bridging frameworks to refine security and liquidity strategies. !Aave Governance Post - Launch Instead of locking the framework into any specific messaging protocol, the design remains modular, allowing for future integrations. If messaging protocols become natively supported by canonical bridges, governance can set parameters to manage liquidity distribution and bridging constraints. The GHO Wrapper contract on Ethereum mainnet provides flexibility for upgrades and extensions without modifying the core bridge infrastructure. The contract has been audited by Pashov Audit Group. It allows for upgrading implementations of the underlying GHO token or supporting additional innovation in the future. This modular design makes it possible to introduce new functionalities without disrupting the existing bridge and minting architecture. Sourcing liquidity on the destination chain requires careful consideration of how GHO is introduced and maintained in the network. GHO is minted on Ethereum and bridged to the destination chain as needed, meaning liquidity only enters circulation when the remote facilitator puts it into use. This follows GHO’s cross-chain strategy, where all liquidity originates on Ethereum. Conclusion This framework lays the groundwork for adopting GHO as a gas token across multiple networks. It provides a structured approach to liquidity management while allowing for future expansions, including governance-controlled messaging integrations, modifications to bridging on Ethereum, and mechanisms to enable liquidity to be pre-minted on destination chains. The Aave community is invited to contribute to refining this framework. Next Steps If Snapshot outcome is YAE, escalate this proposal to the ARFC stage.

[TEMP CHECK] Deploy Aave v3 on megaETH Author: ACI Date: 2025-02-21 Simple Summary This TEMP CHECK proposes the deployment of an Aave V3 pool on megaETH. Motivation MegaETH is an EVM-compatible blockchain that aims to bring Web2-level real-time performance to the crypto world for the first time. Their goal is to push the performance to hardware limits, bridging the gap between blockchains and traditional cloud computing servers. MegaETH plans to offer several distinguishing features, including high transaction throughput, abundant compute capacity, and millisecond-level response times even under heavy load. The network offers a performant location to the deploy the Aave protocol, and the megaETH 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. Useful Links megaETH - Website: https://www.megaeth.com/ - Whitepaper: https://www.megaeth.com/research Disclaimer The current proposal is powered by Skywards. ACI is not directly affiliated with megaETH and did not receive compensation related to this proposal. Next Steps 1. Publish a TEMP CHECK in order to get initial feedback from Community and Service Providers. 2. Escalate proposal to TEMP CHECK Snapshot. 3. If TEMP CHECK Snapshot pass, publish an ARFC to continue gathering community and Service Providers feedback. 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.

[TEMP CHECK] Deploy Aave on Soneium Author: Mingshi S. Date: 2025-02-10 Summary This Temperature Check advocates for the deployment of Aave on Soneium, an Ethereum L2 developed by Sony Block Solutions Labs (a joint venture between Sony Group Corporation and Startale Group). The proposal aims to provide general background information to gauge the community’s interest in the opportunity to deploy Aave V3 on Soneium. This deployment proposal is an opportunity to tap into a consumer-focused Ethereum L2 and utilize Sony’s distribution channels and access to real-world consumers. Built with OP Stack, Soneium offers a scalable, low-cost, and highly interoperable infrastructure for DeFi protocols. The deployment would integrate Aave into an Ethereum L2 designed for mainstream adoption, potentially tapping into Sony’s user base and an upcoming dynamic ecosystem of DeFi, gaming, NFTs, RWAs, and entertainment applications. The proposal includes an ecosystem-wide liquidity incentive campaign, targeting a 7-figure USD commitment (100,000,000 ASTR) to support DeFi protocols, including Aave, to bootstrap liquidity on Soneium. Soneium is also willing to integrate and increase the adoption of GHO stablecoin in its ecosystem, especially for future real-world-focused use cases. Motivation "Empowering individuals and communities to collaborate, create, and fill the world with emotion together." Sony Block Solution Labs believes that the development of a comprehensive Web3 solution based on blockchain technology has big potential for the company, which has developed a wide variety of businesses as part of its purpose to "fill the world with emotion, through the power of creativity and technology". Soneium launched its mainnet on January 14, 2025, settled 10M+ on-chain transactions with 2M+ unique wallet addresses as shown on Blockscout, and achieved $45M+ total value secured according to L2Beat, within 3 weeks. Soneium has also launched the Soneium Spark Incubation Program, attracting over 1,700 builders and projects. The participating Sony Group Companies include Sony Group, Sony Music, Sony Pictures, Sony Innovation Fund, Inzone, and Sony Global Education. Please refer to here for the list of winners of the first Soneium Spark. We see DeFi as the backbone of blockchain adoption and is built with a vibrant DeFi ecosystem that promises to be both innovative and robust, featuring a well-rounded mix of multichain and native protocols. Notable names including Uniswap v4, Velodrome, QuickSwap, Stargate, Squid, Lido, Mellow, StakeStone, KelpDAO, Solv, OpenEden, etc. Our Soneium Spark program also incubated several standout projects that will be launching as native DeFi protocols on Soenium, bringing unique features and services to our users, including Kyo Finance (AMM), SoneX (AMM), SuperVol (On-chain Options), WaveX (Perpetuals), Macaron Finance (Leveraged Farming), etc. In addition to the existing Web3 services, the Soneium team has been investigating how new services that collaborate with businesses within the Sony Group can be developed as Soneium-compatible apps. Specifically, we will explore protecting the rights of content created by creators, new mechanisms for distributing profits to support creators and fans, and opportunities for creators to be active across the digital and real worlds. Furthermore, by utilizing Web3 services, such as the Japan-regulated crypto exchange operated by Sony Group's S.BLOX Inc., and adding new value to the various businesses and utilizing IPs,, we aim to create apps that can be used daily by people who have never had the opportunity to experience Web3, and to build a world where Web3 services permeate people's daily lives. Reasons for Integration: Potential to tap into the existing users from the Sony ecosystem and further expand Aave user base with Soneium’s distribution networks and go mainstream together. Soneium settled 10M+ on-chain transactions with 2M+ unique wallet addresses and achieved $45M+ total value secured within 3 weeks after launch. Establish Aave’s position as the major liquidity market and early mover on Soneium and capture a rapidly growing market in the ecosystem with a focus on real-world adoption (e.g. JPY-USD carry trade on-chain to explore, etc.) * We envision Soneium to be one of the most unique ecosystems in the crypto world that truly foster Web3 mainstream adoption utilising Sony’s distribution channels and business opportunities. We see Aave as an important and reliable partner to facilitate users’ demand in lending, borrowing, leveraging, and earning passive income. * Integrate closely with Soneium’s rapidly growing DeFi ecosystem, including strategic integrations with top-tier dApps like Uniswap, Velodrome, QuickSwap, Stargate, Squid, Lido, StakeStone, Mellow, Solv, OpenEden, etc. Soneium has been in the first batch of blockchains for Uniswap v4 deployment with Uniswap frontend supported by Uniswap Labs. Operates in a high throughput, tps, and low gas fees environment based on OP Stack to provide a smooth UX and efficient lending experience. Soneium is also equipped with top-tier infrastructures including Chainlink, Pyth, RedStone, LayerZero, Axelar, Superbridge, Across, Hyperlane, Li.Fi, Jumper Exchange, The Graph, etc. Receive liquidity incentives for Aave depositors in any upcoming ecosystem-wide liquidity incentive campaign on Soneium from now to the future and help Aave bootstrap liquidity on Soneium. * We have been working on a 100M-ASTR (worth of $4M now) liquidity incentive campaign for mainnet launch at the moment as a starter, which can include Aave if Aave's deployment timeline aligns. More details can be found here. Technical Feasibility 1. Seamless Integration and Compatibility with v3: * Soneium is an EVM-equivalent Ethereum L2 built using OP Stack, which means Ethereum smart contracts are fully compatible. 2. Chainlink Integration: * Chainlink has deployed Chainlink Data Feeds and Chainlink Data Streams on Soneium, supporting a wide variety of assets including BTC, ETH, wstETH, USDC, etc. 3. The Graph Integration: * The Graph has integrated with Soneium and has Full Protocol Support for data indexing on Soenum. 4. Development and Testing * Startale Group will assist Aave’s technical team through its Integration and Support team to ensure a smooth integration. 5. Security Audits: * Startale Group will cooperate with the Aave DAO in order to run audits to ensure that the deployment meets all security requirements, should this be requested by the DAO. Deployment Plan 1. Phase 1: Initial Discussion * Gather community feedback through this TEMP CHECK. 2. Phase 2: Detailed Proposal * If the TEMP CHECK indicates positive support, submit a detailed ARFC (Aave Request for Comment) outlining the technical, economic, and security aspects of the integration. 3. Phase 3: Implementation and Monitoring * Upon eventual approval, deploy Aave V3 on Soneium and monitor the integration closely to address any issues and ensure stability. Risks and Mitigations: 1. Technical Challenges: * Startale Group will work closely with Aave’s developers and service providers to address any technical challenges during integration. 2. Security Risks: * We are open to conducting security and risk audits to identify and mitigate potential risks associated with this proposal and deployment. Startale Group will be available to address raised concerns, and support these potential audits. 3. Community Adoption: * Soneium and Astar will activate its community to engage with the Aave community ensuring support and adoption. Also it will work aligned with the Aave community to engage and attract users to Soneium. Call to Action: We invite the Aave community to express their support or concerns regarding this TEMP CHECK. Your feedback is crucial in determining whether to proceed with a detailed ARFC for the Aave V3 deployment on Soneium, and will help us ensure that the integration aligns with Aave’s goals and community interests. Useful Links: Soneium Website: https://soneium.org/ Soneium L2Beat: https://l2beat.com/scaling/projects/soneium Soneium Blockscout: https://soneium.blockscout.com/ Soneium Defillama: https://defillama.com/chain/Soneium Sony Block Solution Labs Website: https://www.sonynetwork.co.jp/sonynetworkcomlabs/en/ Sony Web3 Solution: Launch of a comprehensive blockchain-centric Web3 solution Startale Group Website: https://startale.com/en ACS Liquidity Incentive Campaign: https://forum.astar.network/t/treasury-proposal-for-acs-campaign/7806 Aave Documentation: https://aave.com/docs Next Steps 1. Publication of TEMP CHECK, collect community & service providers feedback before escalating proposal to TEMP CHECK snapshot stage. 2. If the TEMP CHECK snapshot outcome is YAE, publish an ARFC to continue gathering community and Service Providers feedback. 3. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Thanks to @ACI for TEMP CHECK references in the forum. Copyright and related rights waived under CC0.