Aave Governance

!|904x509 Summary Horizon, an Aave Labs tokenization initiative, creates RWA products tailored to institutions, where regulatory compliance requires some centralization for permissionless DeFi integrations. This ARFC proposes a friendly fork for Horizon to create a white label instance of the Aave Protocol, enabling the Aave DAO to capture new revenue from the Horizon RWA instance, one that is currently uncaptured. Motivation Aave Labs is launching an initiative that works in the RWA space, providing support for existing tokenized assets in the market and tokenizing assets such as Money Market Funds, Credit, Equities and Real Estate. Eligible users can subscribe and redeem these assets onchain. This initiative is also meant to facilitate the flow of value into Aave Protocol through collateralization of these tokenized assets. Currently, the Aave DAO has limited revenue from RWAs, yet the RWA market is growing substantially with more institutions interested in pursuing RWAs. To accelerate this revenue stream, Aave Labs proposes a white label Aave Protocol instance for centralized and permissioned Horizon assets. How Does the Horizon RWA Instance Work? The Horizon RWA instance connects institutions to permissionless stablecoin liquidity while ensuring compliance with issuer requirements. This will allow tokenized asset issuers to enforce transfer restrictions at the token level and maintain asset-level controls, while keeping DeFi composability. Qualified users, permissioned by RWA issuers, can borrow USDC and GHO. With Aave DAO approval, a separate GHO Facilitator will enable GHO minting with RWA collateral, offering predictable borrowing rates optimized for institutions. This enhances security, scalability, and institutional adoption of RWAs in DeFi. Horizon provides a structured approach to institutional participation, expanding access to permissionless stablecoin liquidity. !|699x430 Key Design Components Permissioned RWA token supply and withdrawal mechanisms Permissionless USDC and GHO supply functionality Stablecoin borrowing by qualified users Dedicated GHO facilitator with newly minted GHO on demand Permissioned liquidation workflow Integration with RWA-allowlisted ERC-20 tokens Asset-level permission management by RWA issuers Specification Strategic Benefits for the Aave Community The Aave Protocol’s permissionless design is a core strength. However, integrating permissioned RWAs presents challenges that go beyond smart contract development, requiring an offchain legal structure, regulatory coordination, whitelisted liquidations and active supervision—functions not readily available within the Aave DAO infrastructure. To scale RWA adoption in the Aave ecosystem, Horizon’s RWA instance will launch as a licensed instance of Aave V3, maintaining strong alignment with the Aave DAO. Revenue Share Mechanism Aave Labs is proposing an on-going 50/50 revenue share with the Aave DAO from the Horizon instance’s Reserve Factor and GHO revenue, starting from the launch of the instance. In comparison, the revenue split in the RealT RWA instance is 20/80, with 80% going to RealT. Since Aave Labs is closely aligned with the Aave DAO, this proposal offers the DAO a larger share of revenue than other RWA partnerships, while covering legal, compliance, finance, operations, engineering, regulatory affairs, institutional onboarding and business development from Horizon’s share. Aave Labs will bear most of the upfront costs and risks to bootstrap Horizon, covering operational functions, with no grant request to the DAO. GHO will be listed in Horizon as a standard, non-mintable stablecoin. Liquidity may enter the market either (i) from secondary circulation (GHO minted on the Core market or acquired externally and subsequently supplied to Horizon) or (ii) through D3M-style facilitators configured by the Aave DAO. Under the first path, the Aave DAO captures 100 % of the revenue associated with the originating GHO and 50 % of the Reserve Factor specified in this ARFC. When GHO is introduced via a facilitator, the DAO accrues the full yield rate plus the same 50 % share of the Reserve Factor. These mechanics are consistent with every GHO integration across the Aave ecosystem and are not unique to Horizon. Growth Incentives Given the permissioned requirements of this instance, we would expect the instance to grow slower than permissionless markets (especially compared to those with incentives). To accelerate the growth of the Horizon RWA instance, Aave Labs will contribute $500k in incentives (paid in AAVE), with an additional proposed $500k matched by the Aave DAO. Creating a total amount of $1M in symmetric incentives, aligned with the revenue sharing structure. Aave Labs will collaborate with other existing Aave DAO service providers, such as @ACI and @TokenLogic, to organize and distribute the rewards. GHO Adoption & Revenue We are also proposing that the Aave DAO dedicates a direct minting GHO facilitator, with initially 1M GHO, that can be scaled up to 5M GHO based on the recommendations of the Liquidity Committee. If the market proves to be successful, it will be the DAO decision to grow this capacity with a separate proposal in the future. Horizon enables institutional borrowing against RWAs with GHO as a primary liquidity option, alongside USDC, which is expected to: Drive GHO adoption Enhance the liquidity and stability of GHO Strengthen GHO’s role as a settlement asset Generate revenue through GHO borrowing Operational Support for the Horizon Instance Similar to the WLF instance approach and its configuration, and considering the nature of the market and supported assets, Aave Labs proposes a dual-role setup with clear separation between “Operational” and “Executive” responsibilities for the instance. While the Operational role encompasses basic management of the instance (ownership and upgrade of the contracts, execution of governance proposals), the Executive role oversees risk management, assets listing, and general configuration. The proposed framework assigns the Operational role to the Aave DAO, enabling the community and its service providers to manage the Horizon RWA instance and ensuring that governance and basic operational administrative controls are aligned with DAO oversight. In parallel, the Executive role would be assigned to Aave Labs, providing the independence necessary to effectively configure and manage the instance. This division of responsibilities enables agile adaptation to evolving market conditions, alignment with institutional requirements, and supports strategic expansions into new networks. This structure ultimately strengthens the DAO’s institutional revenue streams, fosters ecosystem growth, and leverages Aave Labs' institutional expertise to navigate complex regulatory environments. Role application across Aave V3 and V4: Aave V3: Aave DAO will manage the instance’s operations (for example code upgrades), while Aave Labs retains permissions to enable/disable assets, collaborate with risk managers to configure risk parameters and price oracles, target specific networks for deployments, and administer supply/borrow caps. Aave V4: With Aave V4’s modular design, Aave Labs will propose the optimal configuration of the instances upon release. Permissioning Framework The Horizon instance introduces asset-level permissioning controls that align with issuer compliance requirements while maintaining open access to stablecoin liquidity. Permissioning occurs at the asset issuer level, with each RWA token issuer enforcing asset-specific restrictions directly at the ERC-20 token level. RWA Collateral Supply: Each RWA issuer enforces its own allowlist mechanism, permitting only addresses verified through its compliance framework to be issued eligible RWAs and subsequently use them as collateral Stablecoin Supply: Any user can supply USDC to the Horizon instance and earn yield, maintaining broad participation and liquidity access Liquidation and Redemption Access: RWA liquidators, typically market makers, must meet issuer-defined investor requirements to liquidate collateral or redeem RWAs This model enables issuer-level permissioning where required, while preserving the open-access principles of DeFi—bridging institutional standards with composable market infrastructure. Considerations by the Aave DAO Based on community discussion of the previous Temp Check, Aave Labs made changes to address community feedback. With the above outlined new structure, Aave Labs requests approval for the Horizon RWA instance—a white label instance based on the existing Aave DAO framework. Horizon’s RWA instance will expand the Aave ecosystem’s institutional reach while preserving its permissionless integrity. As a licensed instance, it generates new revenue streams for the Aave DAO, accelerates GHO adoption, and reinforces Aave’s leadership in the DeFi ecosystem. Additionally, as mentioned in the previous Temp Check, the Horizon RWA initiative is not meant to exclude other RWA initiatives from other Service Providers or third parties, which are encouraged to further expand the Aave Protocol’s presence in the RWA space. Next Steps 1. Engage with the community and service providers to refine the detailed proposal 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage 3. If the ARFC snapshot outcome is YAE, incorporate stakeholder feedback and move proposal to AIP stage Copyright Copyright and related rights waived via CC0.

!aave-aptos.png Title: [ARFC] Aave V3 Deployment on Aptos Mainnet Author: @AptosFoundation Date: 2025-04-16 --- ARFC updated with latest Risk Parameters by Risk Service Providers 2025-04-30 Summary This proposal aims to deploy Aave V3 on the Aptos Mainnet, expanding beyond Ethereum to tap into a next-generation blockchain that offers high throughput, ultra-low transaction fees, and enhanced security. By leveraging Aptos’s innovative features—especially its use of the Move programming language—this move seeks to make the protocol more efficient, accessible, and resilient, positioning Aave to serve a broader audience and adapt to the evolving DeFi landscape. If approved by the Aave community, Aave V3 will launch on Aptos Mainnet with a carefully chosen selection of assets, guided by community input and curated by Chaos Labs and Llama Risk. This initiative aims to extend Aave into the thriving Aptos ecosystem—unlocking innovative growth opportunities and enhancing the value for both communities. Background The Aave Protocol has been EVM-native for over 6 years, ensuring widespread cross compatibility, a robust developer ecosystem, and significant network effects over the years both in terms of user base and liquidity. However, it also brings limitations, especially considering the existence of many non-EVM blockchains that offer different advantages such as lower transaction fees, higher throughput, and more advanced consensus mechanisms. In addition to purely technical advantages, many non-EVM blockchains can allow the Aave community to expand to an entirely new ecosystem, previously inaccessible user groups, and introduce new product possibilities. Aptos is a blockchain designed for building scalable and secure dApps. Developed by former leaders of Meta’s Diem blockchain project, it aims to address some of the limitations in existing blockchain systems such as throughput, scalability, and security. With a TVL of approximately $958.64M and growing rapidly, Aptos is the 11th largest chain by TVL. Its robust infrastructure offers high transaction throughput, low, predictable fees, and advanced security through the Move programming language that make Aptos an ideal platform for DeFi applications. Motivation Deploying Aave V3 on Aptos represents a groundbreaking expansion as it marks Aave’s first deployment on a non-EVM blockchain. This strategic move is significant as it opens up new technological frontiers, diversifies Aave’s ecosystem, and underscores its commitment to innovation. By leveraging Aptos’ innovative technology and developer community, Aave can address diverse financial needs, attract new users, and drive greater innovation in the DeFi sector. This deployment aligns with the Aave community’s strategic goal to explore new technological possibilities and tap into a wider pool of talent and resources. Key benefits of deploying Aave V3 on Aptos include: 1. First Non-EVM Deployment: * This deployment is a significant milestone as Aave’s first move beyond EVM-compatible blockchains. It positions Aave to explore and integrate with new blockchain ecosystems, enhancing its resilience and broadening its reach. 2. Early Mover Advantage and Strong Brand: * Aave is a leading brand in the DeFi space, with a strong reputation and market share. By deploying on Aptos, Aave captures early mover advantages on a high-performance blockchain, similar to its strategic expansions to Avalanche and other L2s. This can attract both seasoned DeFi users and new participants exploring Aptos. 3. Aptos’ Strategic Position: * The Aptos team, with their background from Meta’s Diem project, has strong connections and expertise in finance, social and gaming sectors. Integrating Aave into Aptos complements these areas by adding a mature financial layer, essential for a complete blockchain ecosystem. 4. High Transaction Throughput: * Aptos supports up to 30,000 transactions per second (TPS) crucial for DeFi protocols like Aave that handle a high volume of transactions, including loans, repayments, and interest accruals. This high throughput can significantly enhance user experience and enable new use cases that require high-frequency transactions. 5. Enhanced Security with Move Language: * Aave v3 introduces sophisticated risk management tools and improved security protocols. The Move programming language used by Aptos has inherent security advantages, such as preventing reentrancy attacks. This alignment can lead to a more secure DeFi lending environment, leveraging Move’s safety features and formal verification. 6. Transaction Cost Efficiency: * Aave v3 focuses on gas efficiency, critical for reducing transaction costs. Aptos’ efficient processing capabilities further complement this by potentially lowering transaction fees even more. This makes Aave more accessible and attractive to a broader range of users, from retail participants to institutional players. 7. Modular and Flexible Architecture: * Aave v3’s modular and flexible architecture facilitates easier upgrades and expansions. Aptos supports upgradable smart contracts and a flexible account model, enhancing this aspect. This allows for seamless implementation of updates and improvements without significant disruptions or migrations. 8. Economic Benefits for the Aave DAO: * Market Share Growth: Access to new markets and user bases, specifically in APAC and Korea where Aptos has a strong presence. * Revenue Growth: New markets and user bases can significantly increase transaction volumes and generate additional revenue streams. * Incentives: Aptos Foundation has committed to provide up to 2M APT in liquidity mining incentives and rewards depending on performance in order to attract users and liquidity providers, increase adoption and boost the ecosystem’s growth. Aptos Foundation will work closely with Chaos Labs on determining the appropriate level of incentives relative to caps set. By deploying Aave V3 on Aptos, we will have the first non-EVM deployment through which we can reach new user bases and tap into an ecosystem primed for high-demand DeFi applications, ensuring our protocol remains at the forefront of innovation. Specification Risk Parameters ARFC has been updated by ACI to reflect latest Risk Parameters provided by Risk Service Providers 2025-04-30 We recommend using Chainlink data for each asset, with the same setup for sUSDe as on Ethereum Core. Specification | Parameter | Value | Value | Value | Value | | --- | --- | --- | --- | --- | | Asset | APT | USDC | USDT | sUSDe | | Isolation Mode | No | No | No | No | | Enable Borrow | Yes | Yes | Yes | Yes | | Enable Collateral | Yes | Yes | Yes | Yes | | Loan To Value | 58% | 75% | 75% | 65% | | Liquidation Threshold | 63% | 78% | 78% | 75% | | Liquidation Penalty | 10% | 5% | 5% | 8.5% | | Reserve Factor | 20% | 10% | 10% | 20% | | Liquidation Protocol Fee | 10% | 10% | 10% | 10% | | Supply Cap | 1,000,000 | 25,000,000 | 40,000,000 | 14,000,000 | | Borrow Cap | 500,000 | 23,000,000 | 37,000,000 | - | | Debt Ceiling | - | - | - | - | | UOptimal | 45% | 90% | 90% | - | | Base | 0% | 0% | 0% | - | | Slope1 | 7% | 6% | 6% | - | | Slope2 | 300% | 40% | 40% | - | | Stable Borrowing | No | No | No | No | | Flashloanable | Yes | Yes | Yes | Yes | | Siloed Borrowing | No | No | No | No | | Borrowable in Isolation | No | Yes | Yes | No | | E-Mode Category | N/A | sUSDe/Stablecoin | sUSDe/Stablecoin | sUSDe/Stablecoin | sUSDe/Stablecoin | Asset | sUSDe | USDC | USDT | | --- | --- | --- | --- | | Collateral | Yes | No | No | | Borrowable | No | Yes | Yes | | LTV | 90.00% | - | - | | LT | 92.00% | - | - | | Liquidation Bonus | 4.00% | - | - | Technical Adaptation of Aave V3 to Aptos Since our last update—and following the successful TEMP CHECK snapshot vote—we have made significant progress in tailoring Aave V3 for Aptos. We have been actively engaging with the community through regular development updates and rigorous testing on the Aptos testnet while involving security auditors at every step. Our extensive efforts have ensured that Aptos is now fully prepared to host Aave’s next-generation protocol. Key areas of effort included: 1. Deep Protocol Understanding: * Comprehensive study of the intricate financial models and smart contract design of Aave V3, ensuring that the full complexity of the protocol is faithfully reimagined on Aptos. 2. Mastering Move and the Aptos Ecosystem: * Immersion into the Move language, its ecosystem, and best coding practices. This included analyzing standard native libraries, thoroughly understanding the Aptos VM architecture, and evaluating reference projects to inform our design choices. 3. Architectural Innovation: * Addressing Solidity limitations by rethinking architectural decisions in Move, with careful consideration given to gas optimization, safety, and security. This process ensured we employed best practices tailored to the Aptos environment. 4. Robust Development Process: * Building an MVP to evaluate model robustness, deployability, upgradability, scalability, and security. We re-implemented end-to-end, unit, and integration tests (including backward compatibility tests) and set up comprehensive pipelines for testing, compilation, deployment, audits, and documentation. 5. Tooling and Infrastructure: * Developing a complete front-end interface, a TypeScript SDK, and a custom fuzzer to stress-test our implementation. Additionally, we prepared the monitoring services, indexers, Rust-based services, and all necessary infrastructure to support a seamless go-live, including initial configuration, tokens, and faucets. 6. Governance Considerations: * Special attention was given to designing a governance strategy that aligns with the needs of a protocol on a new chain—starting with community guardians after launch, with future plans to integrate a full governance solution if market conditions warrant. The UI is live and fully integrated with the TS SDK ensuring that developers can interact with the protocol and provide valuable feedback during the testnet phase. This level of preparation reflects our commitment to delivering a secure, efficient, and maintainable version of Aave V3 on Aptos. !Screenshot 2025-03-25 at 11.39.15.png Architectural Changes This section outlines how the modern architecture and unique benefits of Aptos were capitalized in building this while ensuring the protocol retains its core functionality and top notch security. 1. Modular Conversion: Ethereum Approach*: Aave V3 is composed of multiple interrelated Solidity contracts (e.g., LendingPool, Token Manager, Risk Engine). Aptos Adaptation*: Each contract is restructured as a separate Move module. Move’s native module system enforces clear boundaries, enabling better separation of concerns, enhanced security and simplifying future upgrades. 2. Data & State Management: Solidity*: State variables are stored in contracts and accessed via delegatable external calls, which can sometimes lead to state inconsistencies. Move*: The use of resources in Move ensures that each asset is uniquely tracked and can’t be duplicated or lost. This strict management helps maintain consistency across the protocol’s state, avoiding re-entrances, double spending and other attack vectors. Also, Aptos has a uniquely defined global storage whose resources can only be modified by the owner of the resources thus preventing the storage from being maliciously modified in a transaction. 3. Control Access: Solidity*: By design solidity allows external contracts to modify our own contract state which makes it hard to control and avoid unexpected 3rd party breaches. Move*: Move modules have full control over their apis and do not allow by design delegate-calls (callbacks) to other contracts which prevents unexpected state-changes, re-entrances and other unwanted effects. On top of that, Aptos has a very secure system of allowing external modules to be friends and only scoping them to a particular scope of methods without ever giving control over its own resources. 4. Dispatch Mechanisms: Solidity*: Supports dynamic dispatch mechanism which enables a contract to call any other contract as long as a given interface is implemented. This can be however dangerous and the underlying implementation could often be replaced with a malicious one Move*: On the contrary supports only static dispatch which introduces a high degree of security as an external call to a module can only succeed at static compilation at which point contract address and implementation are known and immutable. Security Enhancements 1. Formal Verification & Type Safety: Move’s Built-in Features:* Move was designed from the ground up to support formal verification. We have engaged with Certora to leverage its built-in verifier for mathematically proving smart contract properties, significantly reducing risks like re-entrancy attacks, integer overflows, and other vulnerabilities common in Solidity. Resource-Oriented Programming:* Resources in Move can only be created, moved, or destroyed in prescribed ways. This model ensures that token balances and collateral remain consistent and secure throughout all operations. Performance and Gas Efficiency 1. Optimized Transaction Costs: Gas Model Comparison*: Whereas Solidity requires significant manual optimization to reduce gas consumption, Move’s design inherently minimizes resource usage. This results in lower fees and more predictable transaction costs on Aptos. 2. Parallel Execution with Block-STM: Enhanced Throughput*: Aptos’s Block-STM consensus allows for parallel transaction processing. This means that high-frequency operations (like loan issuance, repayments, and interest accruals) can be handled simultaneously, reducing bottlenecks and improving overall performance. 3. Atomic Transactions: Consistency*: All operations in Move are executed as part of an atomic transaction. This guarantees that either every part of an operation completes successfully or none do, preventing partial state changes and enhancing reliability. Transactions modifying the same state are executed atomically and linearized. Developer Experience and Future-Proofing 1. Improved Modularity & Maintainability: Move’s Module System*: The modular architecture in Move not only organizes code in a logical manner but also facilitates isolated testing, easier upgrades, and reusability of code components. 2. Enhanced Tooling: Ecosystem Maturity*: The Move ecosystem is evolving rapidly, building improved IDE plugins, debugging tools, and testing frameworks. These tools will aid developers in writing, testing, and deploying smart contracts with greater confidence. 3. Future Integrations: Adaptability*: The structured approach of Move allows for easier integration of new features or protocol improvements in the future. As the Aptos ecosystem grows, Aave V3 can seamlessly evolve to incorporate emerging trends and requirements. 4. Governance Strategy: Phased Approach to Governance*: Initially, Aave Labs will retain control of the critical protocol keys while the market is in its early stages. Over the coming months—as the market matures, operates smoothly, and undergoes rigorous verification—we will gradually transition key management to trusted community guardians who will provide oversight and help manage early protocol decisions. In parallel, we will engage with relevant service providers to evaluate the feasibility of integrating the Aave Governance V3 system alongside a.DI, ensuring that future governance processes remain robust and fully aligned with community interests. Development & Testing 1. Testnet Deployment: * A fully functional testnet for Aave V3 on Aptos is already live. This environment is used for rigorous testing of Move modules, simulating real-world scenarios. 2. Audit & Security Reviews: * Comprehensive internal and external audits are done and ongoing with companies like: SpearBit/Cantina, Certora and OtterSec. These will focus on ensuring that the Move modules adhere to Aave's strict security and performance standards. * After the audits are complete, a Security Contest will go live followed by a comprehensive Bug Bounty program when we go live. This initiative, funded by Aave Labs, the Security Contest will offer a total reward pool of $150,000 paid in GHO stablecoin. The contest is designed to incentivize thorough testing and uncover any potential vulnerabilities, ensuring that our protocol meets the highest security standards prior to the mainnet launch. 3. Audit Reports: github com/aave/aptos-aave-v3/tree/main/audits 4. Developer & Community Feedback: * Continuous feedback will be solicited from our developer community to ensure that the transition to Move is smooth and that any issues are promptly addressed. Conclusion Deploying Aave V3 on Aptos presents a significant opportunity to drive Aave's growth and expansion. By leveraging Aptos’s innovative capabilities and the power of the Move programming language, we can build a protocol that not only enhances efficiency and security but also broadens our reach into new markets and developer communities. This strategic initiative positions Aave at the forefront of DeFi innovation, enabling us to tap into emerging opportunities and accelerate ecosystem-wide growth. Next Steps 1. Integrate Chaos Labs and LamaRisk suggested assets and risk parameters report once available. 2. Refine the ARFC based on community feedback and risk providers recommendations. 3. Submit the ARFC for a Snapshot vote for final approval. 4. If consensus is reached, submit an onchain AIP Vote for Aave V3 on Aptos (upon Mainnet launch)

[TEMP CHECK] Deploy Aave v3 on Tron Author: ACI Date: 2025-04-18 Simple Summary This Temp Check seeks the community’s input on the deployment of Aave V3 on Tron Mainnet. Background Tron is the second ranking EVM blockchain in terms of bridged TVL after Ethereum with circa $73bn of value bridged. Almost $69bn of this is stablecoins. We believe that it is time for Aave to deploy on Tron to access this liquidity and allow Tron users to access Aave to earn yield on their stablecoins and borrow against collateral. Motivation Aave has deployed on multiple promising new L1 and L2 EVM networks and is often one of the largest protocols on these networks. Tron stands out as a significant opportunity which Aave has previously overlooked, we believe it is time for that to change. It is time for Aave to deploy on the second largest EVM blockchain and allow Aave users the opportunity to access the $69bn of stablecoins and $73bn of bridged value on Tron. This represents a significant opportunity for Aave to grow TVL, revenue, and access a brand new market from which Aave is conspicuously absent. Proof of Liquidity (POL) and Deposit Commitments The Tron DAO has committed to deposit funds at deployment of the instance to bootstrap liquidity. More details will be shared at ARFC stage. Specification Risk Parameters will be provided by Service Providers and this section will be updated at ARFC stage if proposal moves forward, after successful TEMP CHECK Snapshot. Disclaimer This proposal is powered by Skywards. The ACI is not directly affiliated with Tron and did not receive any compensation for creating this proposal. Next Steps If consensus is reached on this [TEMP CHECK], this proposal will be escalated to the Snapshot stage. If the Snapshot outcome is YAE, this proposal will be escalated to ARFC stage. Publication of a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived under CC0

[ARFC] Onboard eUSDe to Aave v3 Core Instance Author: ACI Date: 2025-04-11 --- 2025-04-22 Risk Parameters have been updated by Risk Service Providers and ARFC has been updated accordingly. Simple Summary: The proposal aims to onboard eUSDe to Aave V3 on the Core Instance, after successful [[TEMP CHECK] Onboard eUSDe to Aave v3 Core Instance](https://governance.aave.com/t/temp-check-onboard-eusde-to-aave-v3-core-instance/21653) and TEMP CHECK Snapshot. Motivation/Background: eUSDe represents deposits in Ethereal, the upcoming Ethena backed perpetual futures exchange. eUSDe earns Ethereal points and 30x Ethena points, providing an attractive opportunity for point farming which has been a driver of considerable demand for borrow on Aave in recent times. Benefits of listing eUSDe PT tokens: Significant new opportunity, with potential for large TVL growth. There is no expected market impact caused by listing these tokens outside of increased borrow demand which should not be destabilising. Chain to be deployed/listed: eUSDe will be listed on Aave V3 Core Instance. Proof of Liquidity (POL) and Deposit Commitments: The same amount of Ethena points will be rewarded to eUSDe deposits as are rewarded to USDe deposits. Specification 2025-04-22 Risk Parameters have been updated by Risk Service Providers and ARFC has been updated accordingly. | Parameter | Value | | --- | --- | | Asset | eUSDe | | Isolation Mode | No | | Borrowable | No | | Collateral Enabled | Yes | | Supply Cap | 150,000,000 | | Borrow Cap | - | | Debt Ceiling | - | | LTV | 0.05% | | LT | 0.1% | | Liquidation Penalty | 7.50% | | Liquidation Protocol Fee | 10.00% | | E-Mode Category | eUSDe Stablecoins | eUSDe/Stablecoin E-Mode | Asset | eUSDe | USDC | USDT | USDS | | --- | --- | --- | --- | --- | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | LTV | 90% | - | - | - | | LT | 93% | - | - | - | | Liquidation Bonus | 2% | - | - | - | Useful Links: https://docs.ethereal.trade/ https://governance.aave.com/t/arfc-onboard-pendle-pt-tokens-to-aave-v3-core-instance/20541 Disclaimer: The Aave Chan Initiative is independent and has not received any form of compensation from related parties for the drafting of this proposal. Some ACI team members may hold tokens from the Ethena ecosystem. Next Steps: 1. Publication of a standard ARFC, collect community and service provider feedback before escalating the proposal to the ARFC Snapshot stage. 2. If the ARFC Snapshot outcome is positive, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright: Copyright and related rights waived under CC0.

[TEMP CHECK] Aave and ether.fi Cash: A Proposal for Real-World Utility [](https://lh7-rt.googleusercontent.com/docsz/AD4nXeeVvM7PGBrLPWDufEibh2mW0CQGQXRvFMDDGSnJ3quqnIYZ0GMpoeYLYwrVkdygwTgBQPxpDh8G2V53ewSnlCvKei9CgVHFeAt6NcyNdUdHMqPsw3BIMj9R1w-LWnjr5q6g?key=DWFRa8qY6ZniZgXRxYcBJLd8) Author: ACI & Ether.fi Date: 2025-04-15 ---- Overview This proposal outlines a partnership between Aave and ether.fi, with the goal of creating a unique Aave market on an EVM L2 to facilitate on-chain credit for everyday payments through the ether.fi Cash credit card program. This collaboration aims to benefit both platforms by continuing to expand their user bases and driving innovation in DeFi with a focus on bridging the gap between DeFi and real-world consumer applications. Summary The ether.fi market was launched on Aave back in September, with the goal of laying the groundwork for a unique instance of Aave, focused at stablecoin borrowing against interest accruing collateral. This market has since been idle, while the development of ether.fi Cash continued to take shape. As we prepare for the next phase of the rollout plan, we propose migration of this market to an optimized Layer 2 market designed specifically for consumer credit applications. Since then, it was determined that ether.fi needs a more tailored instance of the Aave market, with the focus of allowing for more flexibility in asset listings and parameters, along with less expensive transaction fees. This market will feature tailored parameters and asset listings optimized for real-world spending, supported by a competitive card program offering up to 3% cashback. Motivation The traditional credit card industry continues to charge excessive interest rates (often 20%+). By leveraging collateral assets that permit users to continuously earn interest on the positions held in their wallets, naturally offsetting borrowing costs. This market will create a virtuous cycle where a user's digital assets work to pay down their credit. With this, we can provide users with: Significantly lower borrowing costs compared to traditional credit cards Competitive rewards (up to 3% cashback) Efficient use of interest bearing asset positions as collateral, allowing users to keep their positions on chain and in their own custody Minimal transaction costs through L2 deployment This proposal continues to build on the fundamental differences that DeFi has to offer. The future of ether.fi cash will be a system that provides both retail and corporate users with a truly native on-chain solution that does not sacrifice any of the features that consumers have become accustomed to with everyday spending. Card Program The ether.fi Cash credit card is set to change everyday spending by bringing self custodied DeFi-powered credit to the world's largest payment network. With universal acceptance at over 80 million merchants globally, users can access their DeFi credit lines for daily purchases while earning cashback rewards on all expenditures. The upcoming neo-banking alternative mobile app, launching in early Q2 2025, will evolve to provide a comprehensive suite of financial tools including real-time transaction monitoring, expense categorization, budget tracking, and intelligent position management. Corporates and retail users can instantly create multiple virtual cards, manage spending limits, and track rewards - all while their collateral works for them in the background through the Aave market. The app would integrate directly with the custom Aave instance, offering automated position management, smart liquidation protection, and dynamic credit line adjustments based on collateral value. Capital efficiency in this market will be further realized with the launch of Aave V4, utilizing available stable liquidity through the hub and spoke model. By Q4, the platform plans to incorporate AI-powered trading strategies and financial insights, along with predictive budgeting tools, completing the vision of a truly on-chain banking alternative experience powered by DeFi. This will allow for a complete reimagining of on-chain credit, where the efficiency of DeFi meets the convenience of traditional payment networks, all optimized through a dedicated L2 deployment for minimal transaction costs. This vision will be coupled with the battle tested Aave market, along with risk monitoring provided by Chaos Labs. Through this vision, ether.fi would also look to collaborate with Aave to offer a unique co-branded credit card for a unique set of users. Implementation details & profit share We believe in strategic partnerships that are built for sustainable growth and fair value distribution. That's why we're proposing a straightforward revenue sharing model where 15% of the interest rate spread goes directly to the Aave DAO. This creates a win-win scenario where protocol growth directly benefits both ecosystems. For the initial 6 months, 20% of the interest rate spread allocated to Aave DAO After the initial 6 months, 15% of the interest rate spread allocated to Aave DAO Transparent revenue distribution mechanism Quarterly reporting on market performance and revenue generation This will allow for scalable infrastructure that is ready for mass adoption. Implementation Timeline 1. Q2 2025: L2 market deployment with defined assets supported 2. Early Q2 2025: Card program launch to public (currently in closed beta) 3. Q3 2025: Enhanced features rollout 4. Q4 2025: Program optimization based on usage data Disclaimer This proposal is powered by Skywards. ACI is not directly affiliated with ether.fi 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 under CC0

[ARFC] Onboard USDtb to Aave v3 Core Instance Author: ACI Date: 2025-04-09 ---- Risk Parameters have been provided on 2025-04-21 Summary We propose to onboard USDtb to the v3 Core Instance with borrow enabled, collateral disabled, after successful [[TEMP CHECK] Onboard USDtb to Aave v3 Core Instance](https://governance.aave.com/t/temp-check-onboard-usdtb-to-aave-v3-core-instance/21564) and TEMP CHECK Snapshot. Motivation USDtb is a digital dollar, otherwise known as a USD stablecoin. USDtb can be used the same way a holder would use any other dollar, whether to send and receive payments, acquire and trade assets, or to simply hold dollars. Unlike actual dollars, USDtb is a blockchain-based token, which enables faster and cheaper spending than the traditional fiat banking system. Unlike many digital assets, USDtb is fully backed by institutional-grade tokenized U.S. treasury fund products (alongside a stablecoin reserve designed to facilitate rapid redemptions) to support stability. Initially, USDtb will be backed by BlackRock’s USD Institutional Digital Liquidity Fund Token, BUIDL. By onboarding USDtb, deeper borrow liquidity will be generated to allow sUSDe leverage at an attractive borrow rate. We believe this will help revitalise and accelerate growth in sUSDe activity on the Core Instance. Backed by BUIDL issued by Blackrock, one of the largest asset managers in the world we believe this asset aligns well with Aave’s history of providing liquidity to the highest quality assets in DeFi and should attract significant deposits. Specification Onboard to Core Instance Borrow enabled Collateral disabled L1 token contract address: 0xC139190F447e929f090Edeb554D95AbB8b18aC1C Risk Parameters have been provided on 2025-04-21 | Parameter | Value | | --- | --- | | Asset | USDtb | | Isolation Mode | No | | Borrowable | Yes | | Collateral Enabled | No | | Supply Cap | 50,000,000 | | Borrow Cap | 40,000,000 | | Debt Ceiling | - | | LTV | - | | LT | - | | Liquidation Penalty | - | | Liquidation Protocol Fee | - | | Variable Base | 0 | | Variable Slope1 | 6% | | Variable Slope2 | 50% | | Uoptimal | 80% | | Reserve Factor | 10% | | Stable Borrowing | Disabled | | Flashloanable | Yes | | Siloed Borrowing | No | | Borrowable in Isolation | No | | E-Mode Category | N/A | Proof of Liquidity and Deposit Commitments Ethena will deposit a significant amount of USDtb. Useful Links: Docs: https://docs.usdtb.money/ Transparency dashboard: https://usdtb.money/transparency Disclaimer: This proposal is powered by Skywards. The Aave Chan Initiative is not directly affiliated and did not receive compensation for creation 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 under CC0

--- Title: [ARFC] ACI Phase IV – "Road to 80" Author: @marczeller – Aave Chan Initiative (ACI) Date: 2025-04-16 --- Summary This ARFC proposes renewing and expanding the Aave Chan Initiative’s (ACI) mandate as the Aave DAO’s Growth and Governance Coordination service provider. Focusing on sustained protocol growth, strategic alignment, and governance operational excellence. --- Motivation Since its inception, ACI has served as the growth engine and governance orchestrator for the Aave DAO. Through managing incentive programs, launching key protocol initiatives, building strategic partnerships, and contributing to governance frameworks, ACI has delivered consistent, high-impact results. During 2024, Aave's share of the active loan market increased from below 50% to 71.2%, significantly outperforming competitors across the DeFi landscape. To keep this proposal concise, a retrospective of ACI's past mandate has been published separately Strategic Objectives of the next mandate 1. "Road to 80" – Market Share Leadership Our core KPI: reach 80% of total active DeFi loans across all tracked platforms by expanding Aave’s competitive edge through product innovation, liquidity programs, and strategic onboarding and business development. 2. MASIv Expansion Extend the Merit-as-a-Service Incentive Vault model as the standard growth and incentives engine for partners using Aave and DeFi in general. Building on early adoption from Circle, Tether, Ava Labs, Stader and others, Phase IV will onboard new MASIv clients and create synergistic feedback loops for the Aave ecosystem. 3. CeDeFi partnership Launch Deliver a CeDeFi partnership with a top-tier centralized exchange providing CeFi access to DeFi-native yield. 4. Node Infrastructure via Frontier Continue developing Frontier, our Aave-native node infrastructure, on a larger scale. Ensure DAO readiness for Ethereum’s Pectra upgrade and expand node partnerships with Lido, EtherFi, and others. 5. Multi-Chain Capability Establish ACI’s readiness to operate across non-EVM chains, beginning with Aptos, in preparation for a multi-VM DeFi future. 6. Team Scaling & Increased Alignment Expand the ACI core team (currently 8 members) with new hires in technical, governance, and ecosystem roles. --- ACI Deliverables ACI deliverables are executed on a best-effort basis, with transparency and proactive communication regarding any limitations or delays, while aiming to exceed expectations whenever possible. A. Growth & Governance Strategy, design, and execution of growth programs in partnership with Aave DAO's service providers (Tokenlogic) CeDeFi partnerships. Coordination of incentive frameworks (MASIv, Liquidity Mining) ARFC & AIP drafting and governance operations via Skywards services B. Infrastructure Frontier node services compatible for LSTs and re-staking protocols Technical contribution to GHO, MASIv, and DAO tooling as requested and in sync with service providers relevant leads Partnership integrations. C. Community & Coordination Management of Snapshot and Discourse (via Dolce Vita) Delegate onboarding & incentive structuring (Orbit) Proposal escalation and support (Skywards) Aave Protocol Embassy (APE) coordination and expansion (delegation-aware aTokens) --- Limitation Of Scope ACI is not a core developer or maintainer of the Aave protocol codebase. We rely on technical service providers' tooling and infrastructure. While we have provided support in the past, ACI will not develop protocol infrastructure tools during this mandate. For non-EVM ecosystems and Aave V4 (whose codebase is currently unknown to ACI), we will fully depend on technical service providers like @aavelabs to provide the necessary tooling and documentation to fulfill our responsibilities. --- Out of Scope The ACI clearly defines the following activities as out of scope, based on either our internal capabilities or to respect the roles of other Aave DAO service providers: Direct smart contract development (except for AIP payloads within our scope), auditing, or formal verification (delegated to technical and audit service providers) Protocol-level parameter tuning (delegated to technical and Risk Service Providers) DAO Treasury or financial operations not governed by ACI mandates (leadership delegated to TokenLogic) --- Specifications Proposal Duration: 12 months (365 days) Budget Requested: 3M aEthLidoGHO Stream Method: Yearly linear stream, replacing any previous funding streams --- Next Steps 1. Collect community feedback on this ARFC 2. If feedback is positive, escalate to Snapshot for signaling 3. Upon Snapshot approval, submit onchain AIP to renew ACI mandate --- Disclaimer This ARFC is submitted by the Aave Chan Initiative (ACI) independently and without third-party compensation or sponsorship. --- Copyright This proposal is published under a CC0 license. All rights waived.!ACI renewal.jpg

Simple Summary As a continuation of the engagement that finished on 1st April 2025, present to the Aave DAO a proposal for BGD to continue as a development and security coordinator services provider during the next 6 months. --- Motivation In our role as technical services providers of an ecosystem like the Aave DAO, the context before we request renewal ideally is very simple: Aave has remained secure and competitive in the number one spot in DeFi, while little by little improving on all aspects in which we (BGD) have been involved. From that perspective, compared with 6 months ago: We think Aave v3 is more technically sound, even considering a very high starting point. v3.3 has improved the protocol, and the upcoming v3.4 will do it even more. The whole Aave ecosystem kept expanding to the networks. New types of assets have been onboarded, and procedures on this have only improved. A lot of groundwork has been done for an even brighter future, from all angles. Testimony of that is, for example, the activation of SVR to recapture liquidations value, or Umbrella being ready for integration with all other Aave systems. Service providers’ coordination has continuously improved, and the DAO is now a very efficient decentralised organisation, not sacrificing quality. Same time, the DAO is going into very new directions, like the upcoming v4 by AaveLabs, Umbrella having a core role in the ecosystem, or the new Aavenomics, amongst others. Given that our objective has always been giving value to Aave in those places where we believe it is worth it, our new scope presented here naturally has evolved due to that. --- Specification Aave <> BGD Phase V scope Our proposed scope of services includes the following: Activation of v3.4 plus improvements on top. As commented on the v3.4 upgrade thread, we think that high-level everything included there is a net improvement of the protocol, even considering the final refinement of the features we are now performing post-ARFC approval. In addition, we believe Aave v3 has big room for improvement in multiple directions that, to reduce the size of v3.4, have not been included, so we will propose those to the community in the shape of a v3.5 or more upgrades if fragmentation is required. It is important to highlight that these improvements don’t involve any full re-architecture of the system, as we agree with the upcoming v4 in the picture, that would not be too reasonable. Same time, considering the feedback on upgradeability procedures, we will lead an effort to make them stricter and formalised, procedures that the DAO can then potentially use for any of its production/upcoming infrastructure. Improvement of Umbrella post-activation. The Umbrella system activation is imminent, and even though it is a very complete system, it will require improvements over time on the overall infrastructure: smart contracts, Aave DAO user interface, or better integration of it with other DAO infrastructure (e.g., compatibility with the future v4 if applicable). We will work on all these aspects to maximise the value Umbrella brings to Aave. More Aave expansions to new networks. Similar to the previous years, the demand to host Aave on different networks is constant. In the same line as on our previous scopes, we will participate in the technical and quality procedures for the Aave governance to activate v3 instances on those networks. This includes a process of continuous improvements on all layers: better/deeper network evaluations or better setup pre-activation. Better off-boarding procedures for assets and networks. Historically, the Aave DAO has been focused on establishing solid procedures for the onboarding direction of new assets to be listed and new networks to be present on. However, no matter if these procedures are exercised or not, currently there is an important lack of precise technical steps to off-board assets and networks whenever the expected KPIs by the DAO are not fulfilled. Our role will be to better define these steps and collaborate with other contributors to move them forward by any mechanism decided. Technical analysis of assets to be listed on Aave. As we commented in our Phase 4 recap, one of the values we think the Aave DAO gives to the whole DeFi industry is helping to step up architectural and security standards on the assets (tokens) level, via the quality procedures they need to pass in order to get listed on Aave v3. Also, this is a very important flow for the DAO in the future, as it is totally scalable/applicable for other upcoming systems like v4, still sharing similar principles asset-wise as v3. Our role will remain the same as in the previous Phase 4. Streamlining risk management flows on the technical side. During the previous phase, the DAO has already been running in production more automated systems like the AGRS (Aave Generalised Risk Stewards), infrastructure to make the Aave on-chain ecosystem more efficient and less maintenance-heavy, which indirectly improves all other aspects of the DAO. Our role in that has been developing the majority of that infrastructure, but also advising other contributors (e.g., treasury or risk itself) on how to better and safely expand in this direction. We will keep doing the same, with the objective during these 6 months of having all possible systems following the constraint stewards-model, this way reducing governance proposals to only critical aspects. Governance proposals reviews. High-level, aside from decentralisation principles, we see governance proposals as a very strong mechanism of the DAO to achieve base security without requiring complex developments. This means that by having access control configured to the Aave Governance in new systems, that new system has very strong security by default, which later on can be made more granular, but without delaying go-to-market. That base security is a consequence of multiple aspects, but the most important in what regards our past and proposed scope are: - We review what, in practice, are all proposals by other contributors before they are created on-chain. This gives a very high assurance that everything being voted on is secure and of quality. - Our pre-onchain role helps the on-chain proposal reviewers (Certora) to have a way simpler job, as there has already been very important groundwork prior. - We have a very important presence also advising other contributors on how to better organise proposals, not only pure code review. For example, how to batch aspects to propose, or high-level advice on good practices. Support for the implementation steps of the AAVEnomics. During the following months, other contributors (e.g. growth and treasury) will require technical support from our side to execute different steps on the implementation of the newly approved AAVE tokenomics. Our role here will be producing the required helper contracts and defining/reviewing procedures on each sub-step. Continuously improve DAO’s tooling. Since the beginning of our Phase 1, we have been developing off-chain tooling for the DAO, benefiting integrators, service providers, or users themselves. For example, this is the case of the Aave Proposals repository, Aave Address Book, Aave Seatbelt, or even the DAO-owned Governance v3 interface. We will continue to do the same, both improving the existing infrastructure and creating new ones when deemed appropriate. Additionally, we will make an effort to move all the tooling to the Aave DAO organisation, always trying not to disturb the operations of the DAO in the process. Iterate on the SVR direction. Aave <> Chainlink SVR has just been introduced, but we think it has a lot of potential for refinement from here, aside from expanding it to more assets on Ethereum or more networks. Until now, we have supported Chainlink as the Aave tech expert party, and we will continue in this role. Additionally, once SVR is in production with more assets, there could be different synergies with other systems of Aave, and we will contribute with any smart contract required. Aave protocol security coordinator. Same as in our previous engagements, this involves: - Continuously evaluate technical risks for Aave. - Address events involving any vulnerability affecting Aave. This also includes creating governance proposals if required. - Act as technical support for the Aave Protocol and Governance Guardians: define and document plans of action, communicate with both of them whenever a reaction is needed, and also properly disclose to the community activity on the Guardian. - Manage the bug bounty program (currently Aave <> Immunefi). Both operationally (as reviewers of submissions), but also structurally, if we consider, for example, a platform change could be worth it. Contribute to the final steps of v2 off-boarding. Similar to what happened with v1, v2 has entered into its final deprecation stage, with its market size being approximately $300m. We will participate in the final steps of its deprecation, which usually include changes on oracles, interest rate strategies, or even further measures like the ones applied on the v1 off-boarding Phases. Participate in the planning of any potential v3 off-boarding strategy. It is not clear at the moment, and we think that definitely is not a good idea during the next 6 months, but if the DAO would approve any off-boarding plan of v3 in favour of v4 in the future, we can can support the party leading v4 advising on what in our opinion is a responsible way of doing it, without disturbing operations of the DAO. --- DURATION: same as with Phases II, III, and IV, 6 months: starting from the moment the previous engagement ended (1st April 2025) and lasting until 1st October 2025. BUDGET: 2’300’000 in stablecoins and 4’000 AAVE, 50% paid up-front and 50% streamed during the 6-month engagement. This is a slight reduction from our previous scope, as we think the community approving Aave v4 implies that changes on Aave v3 will be lighter than before, focusing on security and basic UX improvements, but without very deep re-architecturing. At the same time, Umbrella will enter into an improvement/maintenance phase, which adds to the scope. --- What is NOT part of the scope Similar to Phases 3 and 4, we want to be explicit on what is not included in our line of contribution: We are a technical provider of the community, we don’t do any type of business development/or growth, which should be the responsibility of other parties. We don’t do formal security reviews on major developments of other contributors. We offer our security advisory for projects solely benefiting the Aave DAO, but on bigger scopes (e.g., Aave v4), that is up to parties engaged specifically on security, like Certora or other external third parties. We will provide feedback on the design of projects that we don’t lead only whenever the project is 1) of technical nature and 2) the final design is flagged as “ready” by the contributor. Given our expertise, we have a pretty strong stand on architecture and design decisions, which can create conflicts if no framework is defined. More explicitly, we are not the developers of Aave v4 and other ad-hoc initiatives like Aave v3 on Aptos, so aside from best-effort giving high-level advice (e.g., similar as we did with GHO or cross-chain GHO) to other contributors like Aave Labs, our scope doesn’t include any involvement/obligation on those. We only work on projects with a TEMP CHECK Snapshot passed (e.g., reviews). With the activity on the DAO increasing day by day, unless a filtering of projects is applied, it is not manageable for us to support any project in the pre-TEMP CHECK stage, unless we identify a clear need from our side. This scope includes EVM-only contributions. Any non-EVM ad-hoc requirement would need to be evaluated aside, as it is not our core expertise and would affect the delivery of all items in scope. We are not running services on behalf of the DAO, we design them to be run in a decentralised manner, or by parties with the proper role to do so. Any tool we decide to run on our infrastructure (e.g., hosting of one instance of the Aave Governance v3 interface or Umbrella’s) is our own decision, outside of the scope of engagement. We don’t produce centralised backend services for the DAO. We prepare the existing technical infrastructure (e.g, Aave v3 instances) for a system fully controlled by the Aave DAO, or if following a friendly fork framework, whenever the configuration is not totally custom (e.g. main pool dynamics heavily changed, major custom code components and flows). We only build user interfaces for the DAO on those projects that we believe are simply not complete without that part of the infrastructure. For example, we think a project like Umbrella requires the DAO to own a UI, no matter who then runs it. Similar applies for the Aave Governance v3 UI. But for any additional cases, we reserve the right to decide if any interface infrastructure is produced for the DAO or is exclusive property of BGD Labs, both those using Aave smart contracts or not. --- Terms of Service A formal Terms and Conditions document for the engagement for services between the Aave DAO and BGD Labs can be found HERE. However, we would like to highlight again the same high-level points as on Phases 3 and 4, which we think are very important for the ethos of the DAO: Major projects’ IP and licensing belong to the Aave DAO. As a service provider to a DAO like Aave, we should defend the interests of our customer. For that reason, the core software (e.g. all on-chain smart contracts to be used by the DAO in production after governance proposals) we create during our engagement are licensed to the Aave DAO governance smart contracts, both using the BUSL approach as on Aave v3 Origin, or more open source licenses if we think expanding the usage of Aave peripheral technology only helps the DAO. To insist on the previous fundamental implication: - The Aave DAO is the sole owner of the intellectual property and licensing of those projects. - It is entirely up to the DAO to decide how to use and/or commercialise them, not BGD Labs. - Our benefit from those projects is the fee we receive from the DAO for developing the software. BGD doesn’t decide what gets activated/applied in Aave. We create the software and the technical proposals to activate said software, but it is and will always be up to the DAO governance to decide if that software should be enabled in production. No software is flawless, but we pursue it. Historically, no major problem has been detected in the developments we did for the DAO, but it is impossible to assure from our side that all software will be flawless. However, we have a firm commitment to always following solid security standards and procedures, to minimise any potential impact. We compromise to not work with competitors of Aave on any core business that could hurt the DAO. We are an independent company with potentially our own projects outside of this scope, but given our involvement on especially in the core Aave v3 protocol, we agree not to work with any direct competitor of Aave (other DeFi lending protocols) in core smart contracts development or security during these 6 months in scope. --- Disclosures BGD Labs has no meaningful commercial relation with entities that could create any type conflict of interest on the scopes of this proposal. --- Next steps If/once this ARFC vote gets approved, we will proceed with an on-chain AIP, which will act as a binding formal agreement between the Aave DAO and BGD Labs. During this period (since 1st April) where we technically have no engagement, we will simply continue doing the same work as before, without stopping any of the on-going projects/developments.

!|904x509 Summary Horizon, an Aave Labs tokenization initiative, creates RWA products tailored to institutions, where regulatory compliance requires some centralization for permissionless DeFi integrations. This Temp Check proposes a friendly fork for Horizon to create a white label instance of the Aave Protocol, enabling the Aave DAO to capture new revenue from the Horizon RWA instance, one that is currently uncaptured. Motivation Aave Labs is launching an initiative that works in the RWA space, providing support for existing tokenized assets in the market and tokenizing assets such as Money Market Funds, Credit, Equities and Real Estate. Eligible users can subscribe and redeem these assets onchain. This initiative is also meant to facilitate the flow of value into Aave Protocol through collateralization of these tokenized assets. Currently, the Aave DAO has limited revenue from RWAs, yet the RWA market is growing substantially with more institutions interested in pursuing RWAs. To accelerate this revenue stream, Aave Labs proposes a white label Aave Protocol instance for centralized and permissioned Horizon assets. How Does the Horizon RWA Instance Work? The Horizon RWA instance connects institutions to permissionless stablecoin liquidity while ensuring compliance with issuer requirements. This will allow tokenized asset issuers to enforce transfer restrictions at the token level and maintain asset-level controls, while keeping DeFi composability. Qualified users, permissioned by RWA issuers, can borrow USDC and GHO. With Aave DAO approval, a separate GHO Facilitator will enable GHO minting with RWA collateral, offering predictable borrowing rates optimized for institutions. This enhances security, scalability, and institutional adoption of RWAs in DeFi. Horizon provides a structured approach to institutional participation, expanding access to permissionless stablecoin liquidity. !|699x430 Key Design Components Permissioned RWA token supply and withdrawal mechanisms Permissionless USDC and GHO supply functionality Stablecoin borrowing by qualified users Dedicated GHO facilitator with newly minted GHO on demand Permissioned liquidation workflow Integration with RWA-allowlisted ERC-20 tokens Asset-level permission management by RWA issuers Specification Strategic Benefits for the Aave Community The Aave Protocol’s permissionless design is a core strength. However, integrating permissioned RWAs presents challenges that go beyond smart contract development, requiring an offchain legal structure, regulatory coordination, whitelisted liquidations and active supervision—functions not readily available within the Aave DAO infrastructure. To scale RWA adoption in the Aave ecosystem, Horizon’s RWA instance will launch as a licensed instance of Aave V3, maintaining strong alignment with the Aave DAO. Revenue Share Mechanism Aave Labs is proposing a 50/50 revenue share with the Aave DAO from the Horizon instance’s Reserve Factor and GHO revenue. In comparison, the revenue split in the RealT RWA instance is 20/80, with 80% going to RealT. Since Aave Labs is closely aligned with the Aave DAO, this proposal offers the DAO a larger share of revenue than other RWA partnerships, while covering legal, compliance, finance, operations, engineering, regulatory affairs, institutional onboarding and business development from Horizon’s share. Aave Labs will bear most of the upfront costs and risks to bootstrap Horizon, covering operational functions, with no grant request to the DAO. Growth Incentives Given the permissioned requirements of this instance, we would expect the instance to grow slower than permissionless markets (especially compared to those with incentives). To accelerate the growth of the Horizon RWA instance, Aave Labs will contribute $500k in incentives (paid in AAVE), with an additional proposed $500k matched by the Aave DAO. Creating a total amount of $1M in symmetric incentives, aligned with the revenue sharing structure. GHO Adoption & Revenue We are also proposing that the Aave DAO dedicates a direct minting GHO facilitator, with initially 1M GHO, that can be scaled up to 5M GHO based on the recommendations of the Liquidity Committee. Horizon enables institutional borrowing against RWAs with GHO as a primary liquidity option, alongside USDC, which is expected to: Drive GHO adoption Enhance the liquidity and stability of GHO Strengthen GHO’s role as a settlement asset Generate revenue through GHO borrowing Operational Support for the Horizon Instance Similar to the WLF instance approach and its configuration, and considering the nature of the market and supported assets, Aave Labs proposes a dual-role setup with clear separation between “Operational” and “Executive” responsibilities for the instance. While the Operational role encompasses basic management of the instance (ownership and upgrade of the contracts, execution of governance proposals), the Executive role oversees risk management, assets listing, and general configuration. The proposed framework assigns the Operational role to the Aave DAO, enabling the community and its service providers to manage the Horizon RWA instance and ensuring that governance and basic operational administrative controls are aligned with DAO oversight. In parallel, the Executive role would be assigned to Aave Labs, providing the independence necessary to effectively configure and manage the instance. This division of responsibilities enables agile adaptation to evolving market conditions, alignment with institutional requirements, and supports strategic expansions into new networks. This structure ultimately strengthens the DAO’s institutional revenue streams, fosters ecosystem growth, and leverages Aave Labs' institutional expertise to navigate complex regulatory environments. Role application across Aave V3 and V4: Aave V3: Aave DAO will manage the instance’s operations (for example code upgrades), while Aave Labs retains permissions to enable/disable assets, collaborate with risk managers to configure risk parameters and price oracles, target specific networks for deployments, and administer supply/borrow caps. Aave V4: With Aave V4’s modular design, Aave Labs will propose the optimal configuration of the instances upon release. Considerations by the Aave DAO Based on community discussion of the previous Temp Check, Aave Labs made changes to address community feedback. With the above outlined new structure, Aave Labs requests approval for the Horizon RWA instance—a white label instance based on the existing Aave DAO framework. Horizon’s RWA instance will expand the Aave ecosystem’s institutional reach while preserving its permissionless integrity. As a licensed instance, it generates new revenue streams for the Aave DAO, accelerates GHO adoption, and reinforces Aave’s leadership in the DeFi ecosystem. Additionally, as mentioned in the previous Temp Check, the Horizon RWA initiative is not meant to exclude other RWA initiatives from other Service Providers or third parties, which are encouraged to further expand the Aave Protocol’s presence in the RWA space. Next Steps 1. Engage with the community and service providers to refine the detailed proposal 2. If consensus is reached on this TEMP, escalate this proposal to the Snapshot stage 3. If the TEMP snapshot outcome is YAE, incorporate stakeholder feedback and move proposal to ARFC stage Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] Onboard tETH to Aave v3 Prime Instance Author: ACI ( Aave Chan Initiative) Date: 2025-03-25 --- Summary This proposal aims to onboard tETH to Aave V3 Prime Instance. ETH is a liquid staking token (LST) from Treehouse that converges the fragmented on-chain ETH interest rates market. Holders of tETH earn real yield in excess of Ethereum’s Proof-of-Stake (PoS) rewards through interest rate arbitrage while still being able to use tETH for DeFi activities. tETH is also foundational to supporting the implementation of Decentralized Offered Rates (DOR). Motivation Assets like tETH are designed to unify fragmented interest rate markets and optimize yield generation. Users contribute ETH and receive tETH, redeemable for their initial ETH plus additional yield. This yield comes from a dynamic strategy that balances staking rewards and interest rate arbitrage on lending protocols. For tETH, this ensures baseline yields equivalent to native ETH staking while capturing additional returns from rate inefficiencies. These assets are composable across DeFi, enabling broader usability. By onboarding tETH to Aave V3 Prime Instance, we can: Enhance capital efficiency: Users can borrow against tETH, unlocking liquidity while continuing to earn restaking rewards. Increase protocol revenue: More borrowing activity leads to higher interest income for Aave. Expand Aave’s influence in restaking finance: Positioning Aave as a central lending hub for LRTs. Specification Risk Parameters will be updated by Risk Service Providers at ARFC stage, and ARFC will be updated accordingly. Useful links https://www.treehouse.finance/ https://docs.treehouse.finance/protocol/teth/introduction Disclaimer This proposal is directly powered by ACI (Aave Chan Initiative). ACI did not received compensation for 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, 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.

Summary This publication presents a comprehensive overview of proposed LRT and LST risk parameters updates across Ethereum, Base and Arbitrum instances of Aave v3. Motivation This publication incorporates the feedback and recent discussion into a single holistic publication. For ease of reference, those publications are referenced below: [[ARFC] wstETH and weETH E-Modes and LT/LTV Adjustments on Ethereum, Arbitrum, Base - 03.12.25](https://governance.aave.com/t/arfc-wsteth-and-weeth-e-modes-and-lt-ltv-adjustments-on-ethereum-arbitrum-base-03-12-25/21370) [[ARFC] rsETH LTV & LT Update](https://governance.aave.com/t/arfc-rseth-ltv-lt-update/21305/1) [[ARFC] Core Instance - Add ezETH and update rsETH eMode Parameters](https://governance.aave.com/t/arfc-core-instance-add-ezeth-and-update-rseth-emode-parameters/21505) [[Risk Stewards]wstETH/wETH eMode Update - Ethereum, Arbitrum & Base Instances](https://governance.aave.com/t/risk-stewards-wsteth-weth-emode-update-ethereum-arbitrum-base-instances/21333) Each of the following sub-section presents insights into how each parameter is to be adjusted. Prime Instance - wstETH and WETH eMode The Prime instance, previously Lido instance, presents a tailored wstETH eMode configuration that offers enhanced capital efficiency relative to other instances of Aave v3. With a Liquidation Threshold (LT) of 96.50% for wstETH on Prime relative to 95.00% elsewhere, a position with a Health Factor of 1.01 can support a leverage ratio of 22.44 on Prime relative to 16.83 on other instances of Aave Protocol. With all other variables held constant, a small difference in the wstETH deposit yield on Prime relative to the Core instance, has a meaningful impact on the overall return of the wstETH/WETH yield strategy. With a strong focus on sustaining a wstETH deposit yield derived from LRT/wstETH leverage, the wstETH/WETH yield strategy is expected to outperform on Prime relative to other venues supporting the same wstETH/WETH strategy. Provided suitable ETH liquidity is available, implementing favourable eMode terms on Prime relative to other instances of Aave is expected to lead to significant growth in wstETH deposits. A LT of 96.50% exceeds the previous forum discussion supportive of implementing a 96.00% LT, whilst also isolating the LT increase specifically to the Prime instance that reflects a clear focus to progress Prime into a sustainable ETH correlated instance of Aave v3. Reference: [[Risk Stewards]wstETH/wETH eMode Update - Ethereum, Arbitrum & Base Instances](https://governance.aave.com/t/risk-stewards-wsteth-weth-emode-update-ethereum-arbitrum-base-instances/21333) wstETH/wETH Legacy eMode Update | Parameter | Value | | --------------------- |:---------------:| | Asset | wstETH, WETH | | Max LTV | 93.5 | | Liquidation Threshold | 95.5 | | Liquidation Penalty | 1.00% | New wstETH/wETH v3.2 liquid eMode | Parameter | Value | Value | | --------------------- | :------: | :------: | | Asset | wstETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 95.00% | - | | Liquidation Threshold | 96.50% | - | | Liquidation Penalty | 1.00% | - | Complimenting the abundance of USDS liquidity provided by the Sky Ecosystem via D3M, this publication proposes increasing the LTV and LT on Prime to improve the capital efficiency of WETH and wstETH relative to other instances of Aave v3. With the support of Sky via D3M and Gho Stewards via Direct Gho Minter Facilitator providing liquidity on demand, the Prime instance is able to offer consistent stablecoin supply and less volatile borrow rates to users. The combination of improved capital efficiency and less volatile borrow rates elevates the competitive positioning of the Prime instances within the broader ecosystem. WETH LTV/LT Update | Parameter | Current | Proposed | | :-------------------- | :------: | :------: | | LTV | 82.00% | 84.00% | | LT | 83.00% | 85.00% | wstETH LTV/LT Update | Parameter | Current | Proposed | | :-------------------- | :------: | :------: | | LTV | 80.00% | 82.00% | | LT | 81.00% | 83.00% | rsETH LTV & LT Update To promote a level playing field between LRTs, a proposal was submitted and approved by Risk Service Providers to align the LTV and LT parameters of rsETH with other LRTs, ezETH and weETH. The following is proposed for rsETH Core, Prime and Base instances: Update rsETH/wstETH eMode: LTV 93%, LT 95% and Liquidation Penalty 1%. A previous forum post details favourable feedback from Risk Service providers supporting amending the LTV and LT to align with other LRTs. Reference: [[ARFC] rsETH LTV & LT Update](https://governance.aave.com/t/arfc-rseth-ltv-lt-update/21305/1) rsETH/wstETH eMode Update (Prime, Core, Arbitrum and Base) | Parameter | Value | Value | | --------------------- | :------: | :------: | | Asset | rsETH | wstETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Penalty | 1.00% | - | Enable rsETH to access stablecoin liquidity on Prime, Arbitrum and Base instances. Create new v3.2 liquid eMode (Prime) | Parameter | Value | Value | Value | Value | | ---------------------- | :--------: | :--------: | :--------: | :--------: | | Asset | rsETH | USDS | USDC | GHO | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | Max LTV | 72.00% | - | - | - | | Liquidation Threshold | 75.00% | - | - | - | | Liquidation Penalty | 7.50% | - | - | - | Create new v3.2 liquid eMode (Arbitrum) | Parameter | Value | Value | Value | | ---------------------- | :--------: | :--------: | :---------: | | Asset | rsETH | USDC | USDT | | Collateral | Yes | No | No | | Borrowable | No | Yes | Yes | | Max LTV | 72.00% | - | - | | Liquidation Threshold | 75.00% | - | - | | Liquidation Penalty | 7.50% | - | - | Create new v3.2 liquid eMode (Base) | Parameter | Value | Value | | ---------------------- | :--------: | :--------: | | Asset | rsETH | USDC | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 72.00% | - | | Liquidation Threshold | 75.00% | - | | Liquidation Penalty | 7.50% | - | weETH LTV & LT Update Based upon improving liquidity conditions on both Arbitrum and Base for weETH, this publication proposes increasing the weETH LTV and LTV as recommended by the Chaos Labs and Llama Risk in the reference linked below. weETH LTV/LT Update (Arb and Base) | Parameter | Current | Proposed | | :-------------------- | :------: | :------: | | LTV | 72.5% | 75% | | LT | 75% | 77% | Reference: [[ARFC] wstETH and weETH E-Modes and LT/LTV Adjustments on Ethereum, Arbitrum, Base - 03.12.25](https://governance.aave.com/t/arfc-wsteth-and-weeth-e-modes-and-lt-ltv-adjustments-on-ethereum-arbitrum-base-03-12-25/21370) Base Instance - Liquid eMode v3.2 The introduction of Liquid eModes in Aave v3.2 enables more granular and targeted risk configurations between correlated assets such as LSTs and LRTs. Creating isolated eModes for each pair enhances capital efficiency relative to the current ETH-correlated eModes on the Base instance. Currently, Aave Protocol supports a single ETH Correlated eMode on Base. | Parameter | Value | | --------------------- |:--------------------------:| | Asset | weETH, wstETH, cbETH, WETH | | Max LTV | 90.00% | | Liquidation Threshold | 93.00% | | Liquidation Penalty | 2.00% | To align the asset parameter configuration on Base instance with other instances of Aave, new v3.2 Liquid eModes are to be deployed with the following parameters. Each new eMode reflects the LTV and LT in use on the Core instance on Ethereum and in doing so unifies the parameters across Core, Arb and Base. Furthermore, by pausing the exisiting ETH correlated eMode and transitioning to more capital efficient v3.2 eModes, it prevents same-asset looping that undermines liquidity incentives from unintended utilisation. weETH/WETH eMode Update | Parameter | Value | Value | | --------------------- | :------: | :------: | | Asset | weETH | wETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Penalty | 1.00% | - | wstETH/WETH eMode Update | Parameter | Value | Value | | --------------------- | :------: | :------: | | Asset | wstETH | wETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Penalty | 1.00% | - | cbETH/WETH eMode Update | Parameter | Value | Value | | --------------------- | :------: | :------: | | Asset | cbETH | wETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Penalty | 2.00% | - | The above new weETH eModes incorporates the feedback from the forum discussion linked below. Reference: [[ARFC] wstETH and weETH E-Modes and LT/LTV Adjustments on Ethereum, Arbitrum, Base - 03.12.25](https://governance.aave.com/t/arfc-wsteth-and-weeth-e-modes-and-lt-ltv-adjustments-on-ethereum-arbitrum-base-03-12-25/21370) Specification The following adjustments are to be implemented on all instances within the same AIP. Prime - Ethereum The Prime instance has the highest LTV/LT for ETH correlated assets. Pause the current wstETH/wETH Legacy eMode Update | Parameter | Value | | --------------------- |:---------------:| | Asset | wstETH, WETH | | Max LTV | 93.5 | | Liquidation Threshold | 95.5 | | Liquidation Penalty | 1.00% | Update WETH LTV and LT Parameters | Parameter | Current | Proposed | | :-------------------- | :------: | :------: | | LTV | 82.00% | 84.00% | | LT | 83.00% | 85.00% | Update wstETH LTV and LT Parameters | Parameter | Current | Proposed | | :-------------------- | :------: | :------: | | LTV | 80.00% | 82.00% | | LT | 81.00% | 83.00% | Create new v3.2 liquid eMode | Parameter | Value | Value | | ---------------------- | :--------: | :--------: | | Asset | wstETH | WETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 95.00% | - | | Liquidation Threshold | 96.50% | - | | Liquidation Penalty | 1.00% | - | Create new v3.2 liquid eMode | Parameter | Value | Value | Value | Value | | ---------------------- | :--------: | :--------: | :--------: | :--------: | | Asset | rsETH | USDS | USDC | GHO | | Collateral | Yes | No | No | No | | Borrowable | No | Yes | Yes | Yes | | Max LTV | 72.00% | - | - | - | | Liquidation Threshold | 75.00% | - | - | - | | Liquidation Penalty | 7.50% | - | - | - | Core - Ethereum rsETH/wstETH liquid eMode update. | Parameter | Value | Value | | --------------------- | :-------------: |:-----:| | Asset | rsETH |wstETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | ~~92.5~~ 93.00% | - | | Liquidation Threshold | ~~94.5~~ 95.00% | - | | Liquidation Penalty | 1.00% | - | Arbitrum rsETH/wstETH liquid eMode update. | Parameter | Value | Value | | --------------------- | :-------------: |:-----:| | Asset | rsETH |wstETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | ~~92.5~~ 93.00% | - | | Liquidation Threshold | ~~94.5~~ 95.00% | - | | Liquidation Penalty | 1.00% | - | Create new v3.2 liquid eMode | Parameter | Value | Value | Value | | ---------------------- | :--------: | :--------: | :--------: | | Asset | rsETH | USDC | USDT | | Collateral | Yes | No | No | | Borrowable | No | Yes | Yes | | Max LTV | 72.00% | - | - | | Liquidation Threshold | 75.00% | - | - | | Liquidation Penalty | 7.50% | - | - | weETH LTV/LT Update. | Parameter | Current | Proposed | | :-------------------- | :------: | :------: | | LTV | 72.5% | 75% | | LT | 75% | 77% | Base ezETH/wstETH liquid eMode, no change. | Parameter | Value | Value | | --------------------- | :-------------: |:-----:| | Asset | ezETH |wstETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Penalty | 1.00% | - | rsETH/wstETH liquid eMode, no change. | Parameter | Value | Value | | --------------------- | :-------------: |:-----:| | Asset | rsETH |wstETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | ~~92.5~~ 93.00% | - | | Liquidation Threshold | ~~94.5~~ 95.00% | - | | Liquidation Penalty | 1.00% | - | Create new v3.2 liquid eMode | Parameter | Value | Value | | ---------------------- | :--------: | :--------: | | Asset | rsETH | USDC | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 72.00% | - | | Liquidation Threshold | 75.00% | - | | Liquidation Penalty | 7.50% | - | Create weETH/wETH liquid eMode. | Parameter | Value | Value | | --------------------- | :------: | :------: | | Asset | weETH | wETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Penalty | 1.00% | - | Create wstETH/WETH eMode Update | Parameter | Value | Value | | --------------------- | :------: | :------: | | Asset | wstETH | wETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Penalty | 1.00% | - | Create cbETH/WETH eMode Update | Parameter | Value | Value | | --------------------- | :------: | :------: | | Asset | cbETH | wETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Penalty | 2.00% | - | Pause the existing eMode by disabling wETH Borrowing within existing eMode. Users will no be able to borrow wETH debt within the legacy eMode upon implementation. weETH LTV/LT Update. | Parameter | Current | Proposed | | :-------------------- | :------: | :------: | | LTV | 72.5% | 75% | | LT | 75% | 77% | Disclosure TokenLogic does not receive any payment for this proposal. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, an AIP will implement this proposal. Copyright Copyright and related rights waived via CC0.

[ARFC] GHO Savings Upgrade Author: @kpk, @tokenlogic and @aci Date: March 26th, 2025 --- Summary This ARFC seeks governance feedback and consensus to define sGHO technical design and the Aave Savings Rate (ASR). It will authorise starting with the final development and security procedures before the final on-chain AIP activation vote. It takes kpk’s technical proposal (Develop sGHO: A Yield-Bearing GHO Vault for Multi-Chain Integration) and incorporates features defined in the previous sGHO’s TEMP CHECK 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. The DeFi ecosystem has seen significant adoption of yield-bearing stablecoin vaults, which offer users a simple and efficient way to earn yield on their idle assets. These vaults have become a cornerstone of liquidity provision and protocol integration, setting a benchmark for user expectations. GHO, as Aave’s native stablecoin, has the potential to build on this trend by introducing sGHO, a yield-bearing version of GHO that combines ease of use, cross-chain functionality, and robust risk management. Key Motivations: 1. Simplified Integration: sGHO will make it easier for external DeFi protocols to integrate GHO, reducing friction and increasing adoption. 2. Competitive Edge: By offering a yield-bearing alternative to existing solutions, sGHO can attract liquidity providers and idle depositors who prioritise predictable returns and ease of use. 3. Multi-Chain Yield Harmonization: sGHO will operate across multiple chains, ensuring consistent yields and reducing fragmentation in the GHO ecosystem. This will make GHO more attractive to users and protocols on different chains. 4. Customer Acquisition: sGHO will serve as a tool to onboard risk-averse users who prioritise yield-bearing assets with low volatility and predictable returns. Specification sGHO vault sGHO will function as a multi-chain solution, enabling yield harmonisation across chains and serving as a customer acquisition tool for risk-averse users and liquidity providers. By creating sGHO, we aim to enhance GHO’s utility, attract new users, and strengthen its position as a leading DeFi stablecoin. The system consists of two independent, interoperable smart contracts: 1. sGHO ERC-4626 Vault: An auto-compounding vault, offering atomic convertibility with no cooldowns or slashing. 2. YieldMaestro: An independent contract that manages GHO allocated to be distributed, in order to achieve a predictable and stable yield rate. !|779x317 Integration Between sGHO and YieldMaestro The sGHO vault and YieldMaestro work together to provide depositors with a seamless and optimized yield-bearing experience: * The sGHO vault handles deposits, withdrawals, and the sGHO balance. * YieldMaestro manages the yield, ensuring it remains predictable and aligned with the target rate. The operational flow will be like this: The AAVE DAO will periodically fund the sGHO yield as a GHO transfer from the Collector to the YieldMaestro. Then the YieldMaestro will manage the rate at which funds can be claimed by the sGHO vault. From the user perspective, 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. Aave Savings Rate (ASR) We recommend reading TEMP CHECK for better context on the definitions used in this section. 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 various instances of 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 volatility relative to USDT, both are favourable qualities 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. !|804x564 When specifically comparing USDT to USDC, the chart below provides a clear visual reflecting USDCs smoother Native yield profile relative to USDT. !|808x567 The Core instance of Aave v3 on Ethereum offers the deepest USDC liquidity and for this reason, the Aave Savings Rate incorporates the USDC Native Yield Rate from the Core instance on Ethereum 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 to encourage adoption whilst being insufficient to promote arbitrage. As the current ARFC defines the sGHO vault /ASR concepts, the specific ASR for each chain will be set in the subsequent sGHO launch ARFCs. 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 --- Copyright Copyright and related rights waived via CC0.

Summary This publication presents the Aave Liquidity Committee (ALC) Phase VI Funding request. Phase V Update GHO Supply Over the course of the last quarter, the market dynamics surrounding GHO experienced a notable shift. As yield opportunities in the broader DeFi landscape became less attractive due to declining funding rates, users began redirecting their capital in search of alternative sources of return. GHO, particularly through its liquidity provision use cases, emerged as a compelling destination. This resurgence in interest was further reinforced by the reactivation and full replenishment of the GSMs, which had previously been nearly emptied. These modules went from holding negligible balances to over $28M in total during the period. !Screenshot 2025-04-03 at 20.01.51 Ethereum DEX Liquidity On Ethereum, GHO's peg has been resilient and consistent during Q1 of 2025 and the deeper DEX liquidity has enabled larger swap sizes to be processed with minimal price impact. With perp funding rates and broader DeFi liquidity costs trending lower, Liquidity Provider (LPs) deposits across GHO DEX pools experienced significant growth, surpassing $85M. !Screenshot 2025-04-03 at 19.28.53 In addition, USDT volatility helped grow GSM TVL to over $28M, ensuring continuous, on-demand support for GHO's peg. !Screenshot 2025-04-03 at 19.37.44 Balancer v3 GHO became the centrepiece asset within the new generation of Balancer pools, reflecting its growing systemic importance. On Ethereum, the primary GHO 3pool successfully migrated to the v3 boosted model, is approaching $30M in TVL. The new Aave Boosted 3pool has exceeded the previous v2 pool’s performance, whilst also delivering superior capital efficiency and deeper liquidity provisioning. On Arbitrum liquidity was migrated from v2 to v3 liquidity and new v3 pools created on Base. On Arbitrum and Base, these pools incorporated the new “surge” pricing mechanism, which dynamically increases swap fees as the pool diverges from the peg. This mechanism adds an additional layer of price defense, reinforcing the GHO's peg on L2s. !Screenshot 2025-04-03 at 19.43.34 Prime Instance Another major milestone during Phase V was the introduction of the GHO and the Gho Mint facilitator on the Prime instance. This new market brought new multifaceted utility to GHO. Created a structure in which GHO could be pre-minted and held by the DAO, providing operational flexibility and improving responsiveness to market demand. Enables GHO to earn yield directly through variable-rate borrow mechanisms, enabling more capital-efficient stablecoin management. Unlocked additional yield opportunities for Balancer v3 pools to deposit into, incentivizing further liquidity provisioning. Lastly, the Prime instance permitted a portion of the GHO allowances allocated to service providers and ecosystem initiatives to be deposited into yield-bearing positions, improving overal capital efficiency of the assets held in the DAO's treasury. !Screenshot 2025-04-03 at 19.46.58 Fluid and Rings Integration Fluid has been whitelisted to be the home of GHO from the backing of scUSD. It has grown to over 6M without incentive on Fluid directly with a very low acquisition cost due to a deposit campaign featuring Bungee to encourage GHO deposits in Rings. Over the coming weeks, Rings is expected to onboard Gearbox by Veda. As GHO deposits continue to grow, GHO liquidity is expected to be distributed across Fluid and Gearbox. Reference: https://x.com/Token_Logic/status/1905352281027166589 PYUSD/GHO Liquidity 7.5M liquidity was sourced for the PYUSD/GHO Balancer v3 liquidity pool. Resolv Collaboration One of the most innovative integrations of the quarter was GHO’s entry into the Resolv ecosystem. In collaboration with Resolv, the ALC deployed a campaign centred on the Curve GHO/USR LP token, and worked with both Pendle and Spectra to create yield markets enabling the ALC to receive a higher ROI on bribe spend, ~x2.2-2.4 multiplier compared to x1.1-1.3 directly on DEXs. This was a great success knowing that no other asset of its kind had previously gained such traction in structured yield products. The campaign was enhanced by a one-month point-boost from Resolv, supplemented by strategic incentives from the ALC. The result was unprecedented: the initiative led to the formation of the largest GHO and USR liquidity pools, reaching up to $35 million in TVL. !Screenshot 2025-04-03 at 19.48.37 Arbitrum Despite the broader success seen on Ethereum and Base, GHO’s growth on Arbitrum remains modest. The lack of meaningful traction can be attributed to delays in strategic integrations, most notably the anticipated collaboration with Synthetix, which ultimately opted to shift its primary focus and development efforts to the Base network. As a result, the GHO ecosystem on Arbitrum has yet to reach critical mass, although foundational infrastructure remains in place for future expansion. Base Phase V also saw the deployment of GHO on Base, a move that has already begun to bear fruit. GHO’s main liquidity pool on Base, the Balancer v3 GHO/USDC pool, has surpassed $13.5 million in TVL within a relatively short period. This rapid growth reflects strong initial interest and suggests high potential for deeper integrations. One such opportunity lies in the upcoming collaboration with Synthetix, which is now in advanced planning stages with Odos soon to integrate the stataToken factory enabling the waBasGHO integration to advance with Synthetix. Phase VI Lookahead Ethereum GHO has already secured a strong presence on Ethereum, with integrations across a wide range of protocols. It is now actively used within lending protocols such as Gearbox and Fluid, offering users capital-efficient strategies centred on GHO. In the DEX landscape, GHO is supported across Balancer, Curve, Maverick, and Fluid, demonstrating its growing utility and liquidity footprint across various AMMs. GHO will remain at the front stage of Ethereum's DeFi, ALC members are actively looking for collaboration with promising projects at early stage to give access to interesting opportunities for GHO holders. The latest best example was the Resolv collaboration. This will continue during Phase VI as well. L2s and Multichain Strategies A core priority for Phase VI will be the continued development of GHO’s multichain strategy, centered around the use of one facilitator on Ethereum, the use of the CCIP bridge, and the implementation of GSMs on destination chains. These Stability Modules will be pre-filled by the Ethereum facilitator, enabling native swaps into GHO on arrival chains and eliminating the need for inefficient bridging. This architecture significantly enhances capital efficiency by allowing users to mint or swap GHO directly on their preferred chain. It also addresses one of the key friction points observed in Phase V, as bridging has proven to be a major brake on growth. By enabling native, trust-minimized GHO access across chains, the stataGSMs will remove barriers to adoption and improve user experience across ecosystems. The modified stataGSM is currently in the last stages of review with @TokenLogic and @AaveLabs. Sonic, Avalanche and Gnosis Three key chains are being targeted for GHO deployment in the near future: Sonic, Avalanche, and Gnosis. Each of these networks offers a unique opportunity to tailor GHO’s integration to the strengths of the local ecosystem. On Sonic with @TokenLogic leading the deployment, the ALC plans to position GHO at the heart of one of the most innovative DeFi environments currently emerging. The goal is to create strong synergies with leading protocols such as Pendle, Rings, Beets, and Silo. Sonic offers a highly composable, fast-moving landscape where GHO can fit perfectly. On Avalanche, with @AaveLabs leading the deployment, GHO will benefit from the support of the Avalanche Foundation, which is preparing to launch new incentive programs at the chain level. The ALC is working to ensure that GHO is a key participant in these initiatives. The playbook established with Balancer v3 on Ethereum may be replicated here, with additional attention to exploring synergies with Avalanche’s native stablecoin AUSD. This deployment will be focused on ecosystem-wide coordination. On Gnosis, with @AaveLabs leading the deployment, the vision is centred on integrating GHO into the Gnosis Card ecosystem. The objective is to streamline both on- and off-ramping processes. The ALC will work closely with KPK and the Gnosis Foundation to facilitate this integration, creating a seamless user experience for payments, transfers, and financial access via GHO on Gnosis. Performance Metrics The below details some high-level GHO metrics: | Description | Ethereum | Arbitrum |Avalanche | Base | | -------- | :--------: | :--------: | :--------: | :--------: | | TVL DEX Liquidity Pools | 85M | 10M | 10M | 20M | | TVL Utility Liquidity Pools (Excl. stkGHO) | 15M | 5M | 5M | 5M| | DEX Liquidity Composition | < 50% GHO (< 33% for 3pools) | < 50% GHO (< 33% for 3pools) | < 50% GHO (< 33% for 3pools) | < 50% GHO (< 33% for 3pools) | | Swap Price Impact $5M Swap (GHO to USDC) | < 0.10% | < 0.25% | < 0.25% | < 0.25% | | Annualised Peg Volatility | < 5.00% | < 5.00% |< 5.00% |< 5.00% | | Price level for >90% time | $0.995 | $0.995 | $0.995 | $0.995 | Please note, each of the above targets has external dependencies beyond the control of the ALC. The above table serves as a North Star for the ALC to strive towards over the next three months. Having measurable targets provides a clear direction and goal to achieve. Specification Create an Allowance enabling the ALC to withdraw GHO from the Prime instance for a total of 3,500,000 GHO. ALC Ethereum SAFE: 0xA1c93D2687f7014Aaf588c764E3Ce80aF016229b Disclosure TokenLogic receives no payment for this proposal. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, an AIP will implement this proposal. Copyright Copyright and related rights waived via CC0.

Summary This publication proposes reducing AAVE emissions to the stkABPT Safety Module category. Motivation During 2025, AAVE liquidity is expected to transition away from stkABPT to a more diversified liquidity base. The below outlines an overview of what to expect during 2025: Reduction stkABPT emissions, eventually to 0; Support AAVE liquidity across several networks; Improved liquidity distribution amongst LPs; and, Introduce Aave DAO liquidity provisions. Thanks to a coordinated effort between Service Providers, AAVE token holders and Aerodrome, there is now AAVE liquidity on the Base network. The liquidity on Aerodrome was key to supporting the onboarding of AAVE to Aave Protocol on Base. This publication focuses on implementing the first significant AAVE emission reduction to stkABPT holders. !Screenshot 2025-04-03 at 21.55.51 Source: https://aave.tokenlogic.xyz/stkbpt stkABPT Category Performance Yield The chart below shows the value of the Balancer Protocol Token (BPT) staked in the stkABPT category of the Safety Module (SM) and the historical yield received by Liquidity Providers (LP) over the last 30 days. !Screenshot 2025-04-03 at 21.57.57 Source: https://aave.tokenlogic.xyz/stkbpt The chart above shows the resulting yield from Swap Fees, wstETH and AAVE emissions. The high swap fee is due to this pooling being the primary source of DEX liquidity and the resulting arbitrage derived volumes. AAVE/wstETH Impermanent Loss The image below compares the investment performance of depositing $100k into the AAVE/wstETH pool at launch on 2023/07/10 until 2025/04/02 versus passively holding each of the underlying assets. !Screenshot 2025-04-03 at 21.59.35 Holding AAVE and wstETH outside of the liquidity pool generates a return of $147,355 versus $141,781 by holding the BPT. This means the impermanent loss incurred by LPs exceeds the yield from wstETH and swap fee volume by 5,574 USD. AAVE Emissions Since the pool was deployed, on average, stkABPT holders have received 12.24% in AAVE yield, 0.61% wstETH native yield and 2.74% swap fees for a Total yield of 15.51%. !Screenshot 2025-04-03 at 22.01.26 Our analysis has shown depending on the compounding frequency of AAVE emission, the overall investment returns can vary widely. As a result, the affects of compounding has been omitted. In return for holding stkABPT, users receive a premium relative to holding the underlying assets. The premium, 18.21% yield, compensates users for being exposed to the risk of impermanent loss, slashing and to Balancer v2. Do note this premium varies over time, it reduces when AAVE's price nominated in ETH increases and vice versa. The below compares three different investment scenarios: Hold AAVE and wstETH, $147,355 (47.35%); Hold BPT with no AAVE Emissions, $141,781 (41.78%); and, Hold stkABPT and retain AAVE Emissions, $165,561 (65.56%). !Screenshot 2025-04-03 at 22.04.13 Liquidity Distribution Within the stkBPT SM category, 5 addresses are responsible for over 71.84% of the liquidity. Whilst these addresses are long term LPs, having a more diversified LP distribution reduces the reliance on select few addresses. !Screenshot 2025-04-03 at 22.07.24 By supporting DEX liquidity on Arbitrum, Base and Ethereum, we hope to reduce the concentration amongst LPs and support creating broader utility for the AAVE token beyond Ethereum. By providing direct liquidity provisions, the Aave DAO can provide a certain minimum amount of liquidity as a means of reducing overall liquidity derived expenses. Several centralised exchanges are also in touch with tapping into "AAVE staking" yield that will be possible when the Umbrella and Aavenomic upgrades are live. This is expected to support greater adoption of AAVE across centralised exchanges. In the near future, we are exploring deploying AAVE liquidity into a new Balancer v3 pool type well suited for volatile asset pairs. Pending having access to suitable data, this new pool could emerge as the preferred liquidity pool for AAVE liquidity on Balancer. Swap Distribution An in depth analysis of the AAVE swap volume routing via the liquidity pool shows that 95.71% of all swaps are users acquiring 400 AAVE or less. | !Screenshot 2025-04-03 at 21.09.36 | !Screenshot 2025-04-03 at 21.14.09 | :-------------------------:|:-------------------------:| The number of swaps per 10 AAVE bin size shows a distribution heavily skewed towards smaller swap sizes with key round numbers, 100, 200, 300 and 400 AAVE swap sizes featuring heavily amongst the data. | !Screenshot 2025-04-03 at 21.26.51 | !Screenshot 2025-04-03 at 21.26.13| |:-------------------------:|:-------------------------:| When comparing swap volume to the TVL in the pool, the largest daily swap volume as a % of the pool was 11.61% on the 20th Jan 2025 totalling $43.27M USD in value. The table below shows the largest swaps routed via the pool and indicates a very long tail up to 2.1M USD in swap size distribution. !Screenshot 2025-04-03 at 21.46.37 stkABPT Emissions The Aave DAO currently emitting 360 AAVE per day to stkBPT holders. Assuming a spot price of $150/AAVE, this is equivalent to $19.71M a year. The yield from holding stkABPT relative to the underlying, 18.21%, compares favourable to holding stkAAVE at 4.72%. Given the slashing risk is 30% for both stkAAVE and stkBPT, the delta of 13.49% represents compensation for the additional Balancer exposure. This publication proposes reducing AAVE emissions by one-third, to 240 AAVE/day. The resulting AAVE yield on stkBPT is estimated to reduce by 4.67%, to 11.96% at current rates whilst still comparing favourably to stkAAVE at a time when swap fees and the Lido Index rate is below historical averages. Based upon the swap size distribution routing through the pool, an overall reduction in TVL would not adversely affect users seeking to acquire AAVE. However, earning near 12% for providing liquidity in the current market is also an attractive investment option for LPs to consider. Specification This proposal when implemented via AIP will reduce the AAVE emission rate. | SM Category | Current | Proposed | | :---------- | :-----: | :------: | | stkABPT | 360/day | 240/day | Disclosure TokenLogic receives no payment for this proposal. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this [ARFC], escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

[ARFC] Add stS to Aave v3 Sonic Instance --- title: [ARFC] Add stS to Aave v3 Sonic Instance author: @ACI created: 2025-03-15 ARFC updated with Risk Parameters 2025-03-25 --- 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 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. 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: Beets also runs a DEX on Sonic, resulting in it being the 2nd largest source of TVL across all protocols on Sonic: 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. 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. Specification Risk Parameters have been provided by Risk Services Providers and ARFC has been updated accordingly. 2025-03-25 | Parameter | Value | | --- | --- | | Asset | stS | | Isolation Mode | No | | Borrowable | No | | Collateral Enabled | Yes | | Supply Cap | 30,000,000 | | Borrow Cap | - | | Debt Ceiling | - | | LTV | 66% | | LT | 68% | | Liquidation Penalty | 10% | | 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 | stS/wS | stS/wS Liquid E-mode Configuration | Parameter | Value | Value | | --- | --- | --- | | Asset | stS | wS | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 87% | - | | Liquidation Threshold | 90% | - | | Liquidation Bonus | 1% | - | CAPO | maxYearlyRatioGrowthPercent | ratioReferenceTime | MINIMUMSNAPSHOTDELAY | | --- | --- | --- | | 11.04% | monthly | 7 | Useful links Beets Website Beets Staked Sonic stS Analytics Docs Github Beets Staked Sonic Contract Spearbit Audit Trail Of Bits Audit Disclosure The ACI is not directly affiliated with Beets and did not receive compensation for creation this proposal. Next Steps 1. Publish a standard ARFC, collect community & service providers feedback before escalating proposal to ARFC snapshot stage. 2. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal Copyright Copyright and related rights waived via CC0.

Title: [ARFC] Renew LlamaRisk as Risk Service Provider - epoch 3 Author: @LlamaRisk Date: 2025-04-02 Summary LlamaRisk submits this proposal to renew our role as an Aave Service Provider. Over the past year, we have delivered consistent value to the DAO through independent risk analysis and proactive contributions to Aave's security and strategic decision-making. We cherish the opportunity to work for an organization that encourages public debate and believe that retaining the services of two risk providers is part of Aave's moat. For this next epoch, we propose a service fee of $1m for one year, a 25% increase from the previous term. This adjustment reflects our expanded engagement, the need to retain specialized talent dedicated to Aave's risk management, and our commitment to upholding the highest service standards. Our contributions are fully transparent and verifiable through our daily engagement on the forum, monthly community updates, and research publications. Below, we review our key achievements in Epoch 2 and outline our vision for this renewal. Epoch 2 retrospective Consistency & responsiveness: - Supported 90 ARFCs, opined on 9 new chains deployments, and served as a reliable signer for the Aave Guardian. - Responded to over 100 forum posts with technical analysis and risk recommendations. - Maintained an average of 91h response time for ARFCs, generally complying with the established 5-day windows. !image (1).png Legal & regulatory content: Published relevant and informing legal research, including: - Coinbase's MiCA-Driven Stablecoin Restrictions - Regulatory Pressure on USDT and Legal Features of USDT0 - Tether's Regulatory Status in El Salvador - wBTC BitGo Custody Update - Community Update - sGHO Legal Implications - Borrowing/Lending tokenized RWAs (Horizon) Uncompromising independence: - Advised halting sUSDe cap increases and raising liquidation penalties. Although we serve on the Ethena risk committee, which can pose potential conflicts of interest, we prioritize Aave's solvency and users' safety above all. Research & tooling: Balancing Act: LST Pricing Mechanisms for DeFi Lending Ethereum Staking Penalty Simulator Aave 3.2 Liquid E-mode short explainer Ethena Reserve Fund Drawdown Methodology V2 MPCs in Protocol Treasury and Operational Context Research on Smart Value Recapture (SVR) Elevating security standards: - Actively advocated for and succeeded in establishing several critical bug bounty programs for protocols seeking Aave integration (Stakestone, bCSPX, Botanix Labs, rsETH, Origin Sonic, Resolv, Rings, and many others in progress) - Championed Operation Spring Cleaning, an initiative to address qualitative risks (e.g., rsETH vulnerability in legacy function, stS access controls oversight) and raise the standards. Presented at EthDenver (Beyond Numbers: Qualitative Risk Analysis in DeFi). - Released the first version of our risk metrics dashboard: score.llamarisk.com Community engagement: - Launched This Week In Aave, a weekly X thread summarizing protocol developments. Scope Building on Epoch 2's foundation, we will continue centering our services to Aave DAO around producing in-depth and actionable risk assessments in recommendations for all current and prospective assets on Aave instances. We will continue working closely with other service providers, especially @ChaosLabs, ensuring comprehensive risk coverage and prioritize the following strategic initiatives: Umbrella parametrization: Provide dedicated support as members of the newly established Aave Finance Committee, applying our data-driven capitalization methodology developed through months of research. This approach uses rigorous analysis of market-wide price shocks to determine optimal insurance caps Smart Value Recapture (SVR): Support and monitor SVR implementation. RWA collaboration: Work with @AaveLabs on the Horizon program, leveraging our domain expertise in RWA risk assessment. Aptos Deployment: Support Aave's expansion to Aptos with a comprehensive risk analysis of the ecosystem. sGHO: Continue supporting the GHO Savings rollout, building on our GSM fee methodology work. We'll provide risk parametrization and supply target estimations to support @TokenLogic and @kpk's integration plans. We propose a 1-year term to underscore our long-term commitment to Aave DAO—performance will dictate continuity. Specification Create a payment stream of 1m GHO to the address 0x9eE16dBDE572886342fc1e2Db8525DEFB007b27c, a LlamaRisk controlled multisig for 1 year starting from the end of the previous engagement (April 28th, 2025 / Unix time 1745822843). Next Steps 1. Gather community feedback on this ARFC. 2. If consensus is reached, escalate this proposal to ARFC snapshot stage. 3. If ARFC snapshot outcome is YAE, escalate to AIP stage. Disclaimer LlamaRisk is presenting this ARFC independently and is not compensated by any third party for creating this ARFC. Copyright Copyright and related rights waived via CC0.

[TEMP CHECK] onboard frxUSD and sfrxUSD to Aave v3 on Sonic Instance Author: ACI & Frax Core Team Date: 2025-04-01 Simple Summary This proposal seeks to onboard Frax USD (frxUSD) and Staked Frax USD (sfrxUSD) as new assets to the Aave v3 protocol on Sonic. frxUSD is a fiat-redeemable stablecoin backed by tokenized U.S. Treasuries, while sfrxUSD is an ERC4626 vault token offering benchmark-driven yields. Motivation/Background Asset Overview frxUSD frxUSD is a fiat-redeemable stablecoin issued by the Frax Protocol, fully backed 1:1 by tokenized U.S. Treasury funds managed by institutional custodians like BlackRock and Superstate. Its bankruptcy-remote structure ensures unparalleled stability, and it is mintable/redeemable directly through licensed partners and soon directly on the frax.com interface itself to any user in the world (fiat wires will require KYC/AML). frxUSD is mintable/redeemable 1:1 for cash, USDC, and USDT directly from the issuer, Frax Protocol. Additionally, frxUSD offers a unique revenue-sharing mechanism, allowing up to 100% of its underlying T-Bill yield (currently 4.1%) on unborrowed frxUSD assets in Aave pools to be shared with Aave DAO. This revenue can be utilized as protocol income or distributed as incentives for depositors, providing flexibility for governance decisions. sfrxUSD sfrxUSD is a yield-bearing stablecoin implemented as an ERC4626 token, designed to maximize returns through a dynamic "benchmark yield" strategy. It automatically allocates capital across three governance-approved strategies: carry trades, Algorithmic Market Operations (AMOs), and the base T-Bill rate. This design consistently delivers higher APYs compared to competitors like sUSDS and sUSDe. Benefits of Listing frxUSD and sfrxUSD frxUSD Stable Collateral Base: Institutional-grade reserves reduce protocol risk. Revenue-Sharing Option: Aave DAO can capture up to 100% of T-Bill yield (4.1% APY) from unborrowed frxUSD assets deposited in Aave pools, offering new revenue streams or user incentives. Sonic Ecosystem Points: This token will earn points as part of backing asset for scUSD Regulatory Compliance: Positioned as a payment stablecoin under the proposed GENIUS Act. sfrxUSD Yield Dominance: Benchmark-driven APY historically exceeds competitors. Strategy Flexibility: Automatic rebalancing ensures optimal returns across market cycles. 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 frxUSD Official Documentation: https://docs.frax.com/protocol/assets/frxusd/frxusd sfrxUSD Official Documentation: https://docs.frax.com/protocol/assets/frxusd/sfrxusd frxUSD and sfrxUSD Official Website: https://frax.com/frxUSD frxUSD Contract Address: Sonic:0x80Eede496655FB9047dd39d9f418d5483ED600df sfrxUSD Contract Address: Sonic:0x5Bff88cA1442c2496f7E475E9e7786383Bc070c0 Frax App: https://frax.com Discord: https://discord.com/invite/fraxfinance Twitter: https://twitter.com/fraxfinance Github: https://github.com/FraxFinance Audit Reports: https://docs.frax.com/protocol/security/audit Disclaimer The current proposal has been powered by Skywards. The Aave Chan Initiative is independent and has not received any form of compensation from related parties for the drafting of this proposal. The Frax Core Team has a direct relationship with frxUSD/sfrxUSD as protocol developers. Next Steps 1. If consensus is reached on this [TEMP CHECK], this proposal will be escalated 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 will follow, collecting community & service providers feedback before escalating proposal to ARFC snapshot stage. 4. If the ARFC snapshot outcome is YAE, an AIP vote will be published for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived under CC0.

[TEMP CHECK] Onboard eUSDe PT Tokens to Aave v3 Core Instance Author: ACI Date: 2025-04-01 --- Simple Summary: The proposal aims to onboard eUSDe PT tokens to Aave V3 on Core Instance. Motivation/Background: eUSDe represents deposits in Ethereal, the upcoming Ethena backed perpetual futures exchange. These can be deposited into Pendle where the yield token (YT), and the principal token (PT) are separated from the underlying. This proposal seeks to onboard the PT portion of eUSDe tokens. We anticipate significant demand for borrowing against these PT tokens, in the low single digit billions of dollars of value and would like to take advantage of this significant opportunity. At ARFC stage the specific PT tokens will be outlined. In future, new expiries will be listed through an expedited process using the direct to AIP path. Benefits of listing eUSDe PT tokens: Significant new opportunity, with potential for large TVL growth. As a first PT token to be deployed on Aave this opens up multiple other opportunities given process and infra development to accomodate this onboarding. Market Impact: There may be increased demand for stablecoin borrows given the size of the PT market, however we believe that this will balance out and result in net new deposits into Aave. Chain to be deployed/listed: The intention is to list the eUSDe PT tokens on Core Instance. Proof of Liquidity (POL) and Deposit Commitments: Users will accrue 2x Ethena points for Ethereal eUSDe PT token deposits on Aave. Useful Links: https://docs.pendle.finance/ProtocolMechanics/YieldTokenization/PT https://docs.ethereal.trade/ Disclaimer: The Aave Chan Initiative is independent and has not received any form of compensation from related parties for the drafting of this proposal. Some ACI team members may hold tokens from the Ethena ecosystem. Next Steps: 1. If consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is positive, this proposal will be escalated to the Aave Request for Comment [ARFC] stage. 3. Publication of a standard ARFC, collect community and service provider feedback before escalating the proposal to the ARFC Snapshot stage. 4. If the ARFC Snapshot outcome is positive, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright: Copyright and related rights waived under CC0.

[TEMP CHECK] Onboard eUSDe to Aave v3 Core Instance Author: ACI Date: 2025-04-01 --- Simple Summary: The proposal aims to onboard eUSDe to Aave V3 on the Core Instance. Motivation/Background: eUSDe represents deposits in Ethereal, the upcoming Ethena backed perpetual futures exchange. eUSDe earns Ethereal points and 30x Ethena points, providing an attractive opportunity for point farming which has been a driver of considerable demand for borrow on Aave in recent times. Benefits of listing eUSDe PT tokens: Significant new opportunity, with potential for large TVL growth. There is no expected market impact caused by listing these tokens outside of increased borrow demand which should not be destabilising. Chain to be deployed/listed: eUSDe will be listed on Aave V3 Core Instance. Proof of Liquidity (POL) and Deposit Commitments: The same amount of Ethena points will be rewarded to eUSDe deposits as are rewarded to USDe deposits. More information on POL and Deposit Commitments will be discussed at ARFC stage. Useful Links: https://docs.ethereal.trade/ https://governance.aave.com/t/arfc-onboard-pendle-pt-tokens-to-aave-v3-core-instance/20541 Disclaimer: The Aave Chan Initiative is independent and has not received any form of compensation from related parties for the drafting of this proposal. Some ACI team members may hold tokens from the Ethena ecosystem. Next Steps: 1. If consensus is reached on this [TEMP CHECK], escalate this proposal to the Snapshot stage. 2. If the Snapshot outcome is positive, this proposal will be escalated to the Aave Request for Comment [ARFC] stage. 3. Publication of a standard ARFC, collect community and service provider feedback before escalating the proposal to the ARFC Snapshot stage. 4. If the ARFC Snapshot outcome is positive, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright: Copyright and related rights waived under CC0.

[ARFC] Onboard Pendle PT tokens to Aave V3 Core Instance Author: ACI Date: 2025-01-07 Summary This ARFC proposes to onboard Pendle PT tokens to Aave V3 Core Instance. Motivation Pendle allows users to split yield bearing tokens into principal (PT) and yield (YT) components. This opens the door to trading yield for the growing number of yield bearing tokens, and gives users additional options for yield farming strategies. A notable feature of the PT tokens is that at the maturity date, the value of the PT equals the value of the underlying asset and can be redeemed for the underlying. This means PT tokens, which can be bought at a discount within Pendle pools, represent the fixed rate part of a Pendle asset pair. Pendle has seen extremely high growth this year, with current TVL of circa $4.5 billion. Along with this growth has come the desire for yield traders to borrow against their Pendle PT tokens. This represents a multi-billion dollar growth opportunity for Aave, without a large increase in risk if PT tokens are onboarded for already listed assets such as sUSDe. We propose listing an initial PT token as a test use case to see user demand and work through the full integration of a PT token: PT-sUSDE-29MAY2025 In future we propose listing sUSDe and USDe PT tokens for new maturities as required. Specification PT-sUSDE-29MAY2025: 0xb7de5dfcb74d25c2f21841fbd6230355c50d9308 Risk Parameters Risk parameters will be provided by Risk Service Providers in the ARFC and will be updated accordingly. Useful Links https://docs.pendle.finance/ProtocolMechanics/YieldTokenization/PT [[TEMP CHECK] Onboard Pendle PT tokens to Aave V3 Core Instance](https://governance.aave.com/t/temp-check-onboard-pendle-pt-tokens-to-aave-v3-core-instance/20131) [[TEMP CHECK Snapshot] Onboard Pendle PT tokens to Aave V3 Core Instance](https://snapshot.box/#/s:aave.eth/proposal/0x857fea8a5adadd066965f3107f1578a3cce94ec59bf45f46565fa22cfaac9d67) Disclaimer ACI is not directly affiliated with Pendle and did not receive compensation for creation this proposal. Some ACI employees may hold Pendle tokens. Next Steps 1. Publish ARFC to gather community and Service Providers feedback. 2. Escalate the proposal to ARFC snapshot stage if feedback is positive. 3. If the ARFC snapshot outcome is YAE, publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived under CCO

Summary Proposal for the pre-approval of Aave v3.4, to authorise starting with the final development and security procedures before the final on-chain AIP activation vote. As extra clarification, this approval only confirms a candidate set of features and changes, whose scope can only be reduced in AIP stage, not increased unless for bug fixing on production problems. The candidate changes are the following: Migration of the custom GHO on v3 Core to a standard a/v Token, with no migration required by users. Addition of Multi-call support on the Aave pool. Introduction of a new Position Manager role, to a limited subset of actions, optionally configurable by every user. Multiple code-size, gas, math precision, and miscellaneous optimisations. Removal of the direct flash loan fee injection to suppliers to reduce liquidity index increase complexity, and overall, the security model of the protocol. Opening for the DAO to re-distribute the fees in an async manner with suppliers and/or Umbrella stakers protecting the asset. Upgrading the core protocol smart contracts to Solidity 0.8.27. Context The development cycle of upgrades on a protocol like Aave is, by itself, full of nuances and strategic decisions. Sometimes, the upgrades are oriented to optimisation of the smart contracts infrastructure, and sometimes more oriented to enabling new features and improving in user/developer experience of the protocol. Historically, the major “sub-versions” of Aave v3 focused on the following: Aave v3.1. Infrastructural, very oriented to security improvements, with the introduction of virtual accounting and the deprecation of stable rate borrowing. Aave v3.2. Feature-rich, focusing on the introduction of Liquid eModes, which radically changed the usage and configuration of assets listed on Aave pools. Aave v3.3. Again, infrastructural, but this time focused on optimising liquidations and starting to account for bad debt accrued on the protocol (deficit). v3.4 is a bit of an exception, as it has a pretty good balance between UX/DevEx-oriented changes and infrastructure. The rationale is that given the criticality of the liquidations component touched on in v3.3, we decided not to include certain features and optimisations we had in a very advanced stage of development and pack them together in v3.4. Aave v3.4 candidate features 1. Standardisation of a/v GHO tokens on v3 Core Since the listing of GHO on Aave v3 Ethereum as a directly mintable asset via a facilitator, we didn’t feel too comfortable with the approach, as it added certain complexity to the protocol. This feeling got confirmed on the different upgrades of v3, as GHO became the permanent exception case that usually needed to be handled ad-hoc. Here is a quick summary on how GHO on Aave v3 Core Ethereum looks at the moment: GHO aToken (aGHO). It is a special implementation that has very little in common with other aTokens, more oriented to trigger various hooks on actions, instead of being an accounting/transferability layer. These inconsistencies materialise in a different utilisation model in the pool, the inability to flashloan GHO natively on Aave, and multiple other minor quirks. GHO vToken (vGHO). While superficially working similarly to standard vTokens, vGHO also has some special mechanics that lead to complexity and potential bug surface. In contrast to other vTokens, the debt does not accrue as yield on the aToken (as aToken totalSupply is always 0), but instead accrues only on the vToken and is collected by the Aave Collector on repayment. This behaviour is required in order to support the discount model, but adds again very important complexity, which, for example we noticed in practice when improving liquidations on the v3.3 release. Additionally, this adds overhead on the treasury management and peg control, as it creates the concepts of realised and non-realised GHO fees. GHO on v3 Core is the only exception for an asset not using the virtual accounting introduced on v3.1, with no plans for this to change anytime in the future. GHO post-v3.4 On this v3.4 proposal, GHO on v3 Core changes the following way: The minting model will follow that of the Aave v3 Prime Ethereum with the GhoDirectMinter: a smart contract that can supply liquidity of GHO to the pool by minting it, but technically outside of Aave v3. Different from currently on v3 Prime, and to not change the behaviour of GHO on Core, only the GhoDirectMinter will be able to supply liquidity of GHO on Aave. This will be achieved by having a 0 supply cap on GHO, which is skipped by the GhoDirectMinter exclusively. It opens to aGHO transfer scenarios (e.g., if the Collector could decide to transfer aGHO), but that should not create any issue. The interest rate remains as it is, totally static (not based on utilisation), and changeable via governance and stewards. aGHO yield accrual will work exactly as with any other aToken, continuously, and not only on repayment. The native discount model is removed, as it can be achieved in the same way by having GHO rewards to specific vGHO/stkAAVE holders on top, with only very small differences on debt accrual dynamics, which in practice make no difference historically on GHO borrowing positions on Core. The most natural option is following the anti-GHO approach approved on the new Aavenomics, for stkAAVE holders to get anti-GHO, which can be used to repay the GHO debt, factually being a discount. Important to clarify that this will not be in sync with v3.4, with anti-gho potentially being released before or after. No users’ migration of any type is required. On the v3.4 upgrade, the GHO model of v3 Core will change under the hood, but all user positions will not be affected. The benefits of these changes on the technical/security side are very important: All reserves will have virtual accounting enabled, with no exception. Related to v3.3 deficit management, burning bad debt no longer relies on special logic for GHO that discounts the protocol fee in some special cases. GHO flashloans are enabled, eliminating the need for custom adapters, and in most cases making the flash-mint facilitator obsolete (but can be kept if the community wants). Even if only affecting the GhoDirectMinter and the Collector in the average case, now for vGHO balanceOf(user) (similar to aGHO) will act as any other reserve, high-level being scaledBalanceOf(user) / normalizedDebt. Umbrella will not need special handling of the GHO case. Further changes on v3 will become way simpler. --- 2. Multicall support on the Aave Pool Multi-call support is the ability of a contract to allow native usage of multiple of its functions in one single transaction, one after the other. For example, being able to do supply + borrow, without requiring another contract on top doing under the hood the Pool.supply and then the Pool.borrow. This has been a frequently requested feature on the Aave protocol; however, in previous iterations, we discarded it because we perceived extra complexity that we were not comfortable with. With the type of non-invasive approach to multi-call we introduce on v3.4, we now think it really can bring all the value without compromising the security model of Aave v3 anyhow. Additionally, this will exponentially improve the experience post-v3.2 Liquid Emodes, opening to a myriad of new flows and use cases. --- 3. Aave Position Manager role When analysing the needs of different integrators after the release of Aave v3.2, it became clear that it could be important to allow a user to authorise a third-party to the following actions on its behalf: Enable/disable an asset as collateral in the user position. Enter an eMode (or switching from one to another). Aave v3.4 introduces the concept of Position Manager, which has the following characteristics: Any user can optionally configure one or multiple Position Manager addresses by calling the approvePositionManager() on the Aave v3 Pool. Same for removing authorisation. These addresses will have the capability to do the previously commented actions on behalf of the user, with all protocol validations still applying as usual. The Position Manager becomes especially interesting when combined with multi-call in the pool, opening ever more use-cases and flows. --- 4. Misc improvements and optimizations 4.1. Removal of the “unbacked” concept Unbacked supply was part of a feature called Portals on the original Aave v3.0. Eventually, even if potentially useful, the feature was never used, but it occupies an important amount of contract size while also costing gas on most of the pool transactions. Therefore, in this version of the protocol, we decided to drop all the related logic to make room for other improvements. The feature might be added back in a future iteration if a use-case emerges and/or code-size becomes less of a concern(e.g. via Fusaka/EOF). 4.2. Multiple configurations changed from variable to immutable On the current v3.3 iteration of the protocol, there are multiple configurations defined as variables, but that historically have a “constant” nature. To simplify the gas and reasoning models around them, v3.4 changes the following configurations from variable to immutable. Interest rate strategy address. While all reserves already share the same interest rate strategy smart contract, in Aave v3.3, the strategy is still defined per reserve, which leads to one unnecessary storage read per touched reserve on user actions. Given that there is no realistic need any time soon to change the interest rate strategy for only one asset but not for others, in Aave v3.4, one immutable variable RESERVEINTERESTRATE_STRATEGY was added to the Pool contract. Incentives controller address on a/v Tokens. While all reserves already share the same Incentives Controlled address (the contract handling supply/borrow incentives), in Aave v3.3, the Incentives Controller was defined in state per token, which leads to unnecessary storage reads per touched reserve(s). This had some historical reasoning of being able to customise rewards accounting contracts per asset, but it is a behaviour totally deprecated with no plans to appear any anytime soon. Therefore, in Aave v3.4, one immutable variable REWARDS_CONTROLLER was introduced on the IncentivizedERC20 base class. Pool address on ProtocolDataProvider. Up until now, the ProtocolDataProvider was doing a call AddressesProvider.getPool() to fetch any data, but given that the addresses provider and pool proxy pair will never change, it is way more optimal to simply make the pool reference on the data provider immutable, and this way adding extra gas savings across the board. Treasury address on aToken. Currently, the treasury on each aToken is stored in storage, although it is the same for each aToken, even across pools in the same networks. This causes unnecessary storage reads on liquidations and mintToTreasury, with the first having high gas sensitivity. Therefore, in Aave 3.4, the treasury was moved to an immutable. 4.3. Migration to Errors Aave has historically used string error codes as opposed to Error signatures, because there was a preference for require(cond, error), which did not support signatures in previous compiler versions. As on Aave v3.4 the codebase was upgraded to solc 8.27, require(cond, Error()) is now supported. This greatly improves UX, as explorers and simulations now show helpful errors opposed to cryptic numeric Error codes. At the same time, the change results in minor gas & codesize savings across the board. While this change could be breaking for anyone relying on exact error codes, it is important to note that: Every single Aave release since v3.0 has had breaking changes in regards to error emission (either due to new Errors or the order of Errors) We checked all the major integrations and did not find examples of people relying on exact error codes. 4.4. Refinement of rounding/precision on user actions Similar to the majority of protocols dealing with any type of mathematical operations on-chain, Aave v3 has certain inherent imprecision, generally affecting the order of magnitude of +/- 1 wei (last decimal). Considering the extensive list of security procedures applied to Aave v3 over the years, we are confident this imprecision doesn’t pose any important problem. However, on v3.4 we are improving the rounding logic on user operations to follow the design approach of the protocol (and industry in general) of being more explicit rounding on the side of the protocol, as on the 4626 standard. 4.5. Flash loan fees model simplification On the Aave Pool and, more specifically, the flash loan feature, there is a fee which currently has 2 components: The flash loan fee to the protocol _flashLoanPremiumToProtocol. The percentage of the total flash loan fee that goes as fees to the protocol Collector itself. The flash loan fees to aToken holders (flashLoanPremiumTotal - flashLoanPremiumToProtocol). The percentage of the flash loan fee that gets automatically accrued into the liquidity index, so factually “spread” as yield amongst all suppliers. From a technical and security perspective, the model is sound and functional. However, the component of the flash loan fee going to suppliers creates a highly important consequence on the Aave system when looking from a fundamental point of view. In Aave, yield/debt growth happens in practise by the so-called “indexes” (liquidity index, variable borrow index) increasing. Being a yield-oriented architecture, what is expected is that as debt gets accrued on the borrow side, the debt index increases, and this reflects on the liquidity index also increasing, to “forward” the yield from borrowers to aToken holders. High-level, this feels like it should be the only gateway for the liquidity index to increase, however, there is one single exception on Aave v3: the flash loan fee going to suppliers. Aside from being the only exception, the mechanism of “injecting” the flash loan fee into the liquidity index of the aTokens is very different morphologically to yield accrual: It is “fast”. It happens immediately during a flash loan, and there can be multiple “injections” of flash loan fees during the same block. In comparison, the increase of the index based on yield is “slow”, as it depends on the time passed and the interest rate. For example, if an asset has a yearly 5% supply rate, the rate per Ethereum block is approximately 0.001%. However, one single flash loan of the whole liquidity available would be 0.05%, 50 times more, and that could potentially be repeated multiple times in the same block. It is quasi-unbounded. Meaning that the higher the flashed amount, the higher the flash loan fee, and is only bound to available liquidity on the pool, which technically can be increased by supplying just before the flash loan. These characteristics of the flash loan fee, and even considering countless other protections like virtual accounting, make the security profile of the flash loan feature more dangerous by default than yield accrual limited by time. Because of the previous, on v3.4 we remove completely the component of flash loan fee going directly to suppliers, with the total flash loan premium becoming equal to the flash loan premium to the protocol. The consequences of this are: Yield accrual becomes the only “entry point” for liquidity index increase. This is extremely valuable from both a security and a technical perspective. High-level assumptions don’t change significantly. The DAO can still spread to suppliers flash loan fees if required, just via other methods like on-chain rewards, Merit, or anything else. The DAO can choose on top to spread rewards as incentives to the users that will carry the risk of the aTokens: Umbrella stakers. Alternatively, the DAO can simply choose to completely zero the fee, but this would just be a separate configuration, not having any consequence on the codebase. 4.6. Misc Solc version used on the Aave protocol upgraded to 0.8.27. Gas usage of executeUseReserveAsCollateral was greatly reduced by optimizing storage access. Gas usage improved by shuffling virtualUnderlyingBalance into the position of pre-3.4 unbacked. Minor code style improvements on executeRepay. Usage of imported events from the interface contracts instead of re-declarations. Skip unnecessary calculations on a subset of transfers. Self-liquidation is now forbidden (BREAKING). While this is a breaking change, it's unlikely to affect anyone, as there are essentially no on-chain traces of people relying on this functionality. The rationale is that even if a user has monitoring capabilities/tooling to avoid liquidation, the optimal path is repaying with collateral (or just repaying), not self-liquidating. SafeCast was upgraded from Open Zeppelin v4 to v5. The main difference is the usage of Error signatures, reducing the code size of various contracts. VersionedInitializable now bricks the initializer on the implementation, so implementations no longer have to be initialized in order to prevent malicious initialization. ScaledBalanceTokenBase changed the .balance storage from 128 to 120 bits. This was done to align storage across all tokens (currently on aAave on Ethereum mainnet uses 120 bits of storage), as 120 bits is more than enough. Improved the accuracy and gas consumption of the calculateCompoundedInterest function without changing the formula. Credit to @Certora on this simplification.

Risk Parameters have been updated by Risk Service Providers and ARFC has been updated accordingly 2025-04-01 --- Summary This publication presents the community an opportunity to expand AAVE governance token integration on the AAVE platform by adding AAVE collateral option to Base. AAVE token has wide integrations into all other major AAVE instances including ETH Mainnet, Arbitrum, Optimism, Polygon, and Avalanche. Adding AAVE to the Base instance is the next logical step in AAVE token integration within the AAVE lending platform. Motivation AAVE token is a versatile governance token which is already accepted collateral on all major AAVE instances. -The Base Market is growing in TVL, the addition of collateral options already found on other AAVE instances will increase Base Market growth. -There is deep liquidity on Base chain for the AAVE token already. Price impact of just 0.77% for $1m ETH/AAVE trades using jumper.exchange on Base. -Aerodrome (Base DEX) has $10m TVL in WETH/AAVE concentrated liquidity. !34039cc1bf8502f76660a4128e8162cb.png !eaadd7e857120a1d552e4270081c9d3f.png Base has seen expansion in its TVL now surpassing Arbitrum by ~15%. Base chain is a small but significant part of total Defi TVL (all chains) of 3%. Source: https://defillama.com/chains Specification Ticker: AAVE AAVE L2 (Base) contract address: [0x63706e401c06ac8513145b7687A14804d17f814b] (https://basescan.org/address/0x63706e401c06ac8513145b7687a14804d17f814b) Risk Parameters have been updated and ARFC has been updated accordingly 2025-04-01 | Parameter | Value | | --- | --- | | Asset | AAVE | | Isolation Mode | No | | Borrowable | No | | Collateral Enabled | Yes | | Supply Cap | 30,000 | | Borrow Cap | - | | Debt Ceiling | - | | LTV | 60% | | LT | 65% | | Liquidation Penalty | 10% | | Liquidation Protocol Fee | 10% | | Variable Base | - | | Variable Slope1 | - | | Variable Slope2 | - | | Uoptimal | - | | Reserve Factor | - | | Stable Borrowing | Disabled | | Flashloanable | Yes | | Siloed Borrowing | No | | Borrowable in Isolation | No | | E-Mode Category | N/A | Useful Links https://aave.com/docs/primitives/aave Disclaimer Edit: The original author does not hold AAVE token and has not been compensated for the writing of this proposal. Next Steps 1. Publish an ARFC, collect community & service provider feedback before moving forward with governance. 2. if feedback is positive, escalate to ARFC snapshot vote stage 3. if ARFC snapshot outcome is YAE, Publish an AIP vote for final confirmation and enforcement of the proposal. Copyright Copyright and related rights waived under CC0.

[TEMP CHECK] Onboard USDtb to Aave v3 Core Instance Author: ACI Date: 2025-03-25 Summary The current proposal is set to onboard USDtb to the v3 Core Instance with borrow enabled, collateral disabled. Motivation USDtb is a digital dollar, otherwise known as a USD stablecoin. USDtb can be used the same way a holder would use any other dollar, whether to send and receive payments, acquire and trade assets, or to simply hold dollars. Unlike actual dollars, USDtb is a blockchain-based token, which enables faster and cheaper spending than the traditional fiat banking system. Unlike many digital assets, USDtb is fully backed by institutional-grade tokenized U.S. treasury fund products (alongside a stablecoin reserve designed to facilitate rapid redemptions) to support stability. Initially, USDtb will be backed by BlackRock’s USD Institutional Digital Liquidity Fund Token, BUIDL. By onboarding USDtb, deeper borrow liquidity will be generated to allow sUSDe leverage at an attractive borrow rate. We believe this will help revitalise and accelerate growth in sUSDe activity on the Core Instance. Backed by BUIDL issued by Blackrock, one of the largest asset managers in the world we believe this asset aligns well with Aave’s history of providing liquidity to the highest quality assets in DeFi and should attract significant deposits. Specification Onboard to Core Instance Borrow enabled Collateral disabled L1 token contract address: 0xC139190F447e929f090Edeb554D95AbB8b18aC1C More details will be shared on ARFC. Proof of Liquidity and Deposit Commitments Ethena will deposit a significant amount of USDtb. Useful Links: Docs: https://docs.usdtb.money/ Transparency dashboard: https://usdtb.money/transparency Disclaimer: This proposal is powered by Skywards. The Aave Chan Initiative is not directly affiliated with USDtb 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 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 under CC0

Title: Aave Permissionless Acqui-Hire Framework. Author: DAO Merger. Date: 2025-03-17 Summary: In a Darwinian world with (too) many tokens, there should be a way to conduct "acqui-hire" mergers, where the best-performing project (Aave) attracts talent. Hence we need a permissionless acqui-hire framework. Motivation: Incentivize Proven Value : Teams earn AAVE tokens only after demonstrating measurable contributions to Aave’s ecosystem. Meanwhile, they have to give up their hard-earned treasury and their inflated market caps dreams. Aave Token Holder Benefit : The acqui-hired team’s treasury is repurposed to purchase AAVE tokens and reward their community with it, aligning incentives with Aave DAO. Permissionless Efficiency : Minimize overhead using governance and pre-existing framework while maintaining Aave’s decentralized ethos. Specification: No change are required to the code. 1. Criteria for entry The framework relies on a single vote after eligibility is confirmed. Eligibility : Team must prove control of a token with at least $50K in liquidity in AAVE tokens. Team submits wallet addresses and a treasury address holding their funds. Team makes a proposal outling the earn out terms and objectives 2. Execution : Provided vote is positive : Converts the treasury (e.g., ETH, stablecoins, or their native token) into AAVE via a DEX (e.g., Uniswap). Distributes the resulting AAVE tokens to the team’s existing holders proportionally based on their token holdings (e.g., 1 OLD_TOKEN = X AAVE, determined by a fair market rate at conversion time) via a claim contract. Burns or locks the old tokens to phase them out, ensuring a clean transition. 3. Earn-Out Condition Contract : Defines the 3-month performance conditions for the team to earn AAVE. (e.g., TVL, Volumes, Features, BD, Research work ...) Defines the number of AAVE tokens the team would earn, only if the Earn-Out Condition is reached. If conditions aren’t met, tokens are re-allocated to the Aave treasury 4. Tokenomics Impact Assessment : Earn-Out Pool : Aave DAO allocates a fixed pool for acqui-hires, capped to prevent dilution. Only allocated if value is provided. Demand Boost : Converted treasuries add to Aave’s demand. Holder Increase: New holders gain exposure to AAVE, a more established token, increasing Aave’s community and staker base. 5. Challenges : Holder Backlash : holders might resist the swap. Mitigation: they can always take their AAVE and sell immediately. Scalability : Too many teams could strain the earn-out pool. Mitigation: Prioritize teams by treasury size. 6. Strategic Benefits for Aave DAO : Talent Acquisition : Attracts skilled teams without upfront cost, only rewarding proven value. Liquidity Growth : Converts small treasuries into AAVE, deepening market depth and staking power. Ecosystem Expansion : Absorbs niche projects, in some cases even broadening Aave’s feature set (e.g., RWA). Community Buy-In : Gives acqui-hired token holders a stake in Aave, fostering loyalty. Next Steps: If approved, this framework makes Aave DAO a permissionless talent and treasury aggregator. Teams earn AAVE only after hitting clear, Aave-aligned goals within 3 months, while their treasuries are swapped into AAVE for their holders—boosting Aave’s liquidity depth and reach. After 3 months, team can feel part of Aave DAO and make new proposals to bring more value. Or leave to create new things. Disclaimer: DAO Merger as an investor in many other projects and in AAVE token could benefit if this happens. Copyright: Copyright and related rights waived under Creative Commons Zero (CC0).

Author: FREDY Date: 2005-03-14 Category: Governance, Branding Summary: This proposal suggests renaming Aave’s native stablecoin, GHO, to USDA, aiming to align its branding with traditional stablecoin naming conventions, improve user understanding, and boost adoption across DeFi ecosystems. Motivation: Since its introduction in July 2022, GHO has been a pioneering addition to the Aave ecosystem, offering a decentralized, overcollateralized stablecoin that enhances the protocol’s utility and resilience. The Aave community and developers deserve immense credit for its innovative design and successful deployment on Ethereum, Arbitrum and Base with plans for further expansion. However, as GHO grows, its name presents a potential barrier to broader recognition and adoption. Traditional stablecoins like USDC (USD Coin), USDT (Tether USD), and USDe (Ethena USD) incorporate "USD" or similar terms in their names, clearly signaling their peg to the U.S. dollar and their purpose as stable stores of value. In contrast, "GHO" lacks an immediately recognizable meaning tied to its function. While its uniqueness reflects Aave’s creative spirit, it may confuse new users or fail to convey its role as a dollar-pegged asset. The letters "GHO" don’t inherently suggest stability, Aave’s involvement, or its USD peg, which could hinder its appeal in competitive DeFi markets where clarity drives trust and usage. Renaming GHO to USDA—standing for "United Stable Dollar Aave"—would address these concerns while honoring Aave’s legacy. "USD" ties it explicitly to its dollar peg, aligning with user expectations, while "A" nods to Aave’s role as its creator and steward, preserving brand identity. This change could enhance GHO’s visibility, make it more intuitive for onboarding new users, and strengthen its position as a go-to stablecoin in DeFi platforms like Uniswap, Pendle, Curve and others. Benefits: Clarity: "USDA" instantly communicates a USD-pegged stablecoin, reducing confusion for users unfamiliar with GHO’s origins. Adoption: A familiar name could attract more liquidity providers, traders, and integrators on DeFi platforms. Brand Continuity: Retains Aave’s identity with the "A" while aligning with industry norms. Risks and Considerations: Transition Costs: Updating contracts, bridges, and UIs may require technical and financial resources, though these could be minimized with careful planning. Community Sentiment: Some may feel attached to "GHO" as a unique identifier; this TEMP CHECK seeks to balance tradition with growth. Legal/Trademark: "USDA" should be checked to avoid conflicts with existing trademarks (e.g., U.S. Department of Agriculture), though in DeFi contexts, this seems unlikely to overlap. Disclaimer The author is not presenting this TEMP CHECK on behalf of any third party and is not compensated for creating it. Proposal and Next Steps : I propose that the Aave DAO consider renaming GHO to USDA through the following steps: 1. Community Discussion: Gather feedback on this TEMP CHECK to assess sentiment and refine the suggestion. 2. Branding Evaluation: Commission a lightweight analysis (via governance or a working group) to explore the feasibility, costs, and benefits of rebranding, including smart contract updates, bridge adjustments (e.g., Chainlink CCIP), and ecosystem partner coordination. 3. Snapshot Vote: If supported, escalate to a non-binding Snapshot vote to gauge broader community consensus and move to an ARFC. 4. AIP Implementation: Draft an Aave Improvement Proposal (AIP) to execute the rename, updating token contracts, documentation, and UI across Aave’s supported networks (Ethereum, Arbitrum, Base, etc.). Conclusion: GHO is a testament to Aave’s innovation, and this proposal isn’t a critique of its success but a suggestion to unlock its full potential. Renaming it to USDA could bridge the gap between Aave’s vision and the broader DeFi audience, making it a household name among stablecoins. I welcome feedback, alternative name ideas or counterarguments from the community to refine this idea collaboratively. Thank you for considering this proposal. Let’s discuss how we can make Aave’s stablecoin not just technically robust but also universally recognizable! Copyright Copyright and related rights waived under CC0.