Aave Governance

!image [ARFC] Upgrade PT Risk Oracle to Protocol-Owned Infrastructure on CRE Summary LlamaRisk proposes upgrading the Pendle PT risk oracle stack to an automated pipeline that enhances Aave's protocol-owned risk infrastructure: Aave Governance owns every contract, the risk manager only proposes, and every parameter and tuning decision is recorded onchain. The proven linear discount-rate model and the Risk Agents middleware carry over unchanged; what changes is the offchain sender and the path each update takes onchain. Three Chainlink Runtime Environment (CRE) workflows will compute the smoothed implied rate, the discount rate, and the per-E-Mode LT, LTV, and LB parameters, each publishing a signed report that a new router validates and writes onchain. The methodology parameters that drive them live in an onchain ParameterRegistry. The pipeline executes atomically: a single signed report writes to the oracle and triggers execution via the existing AgentHub in a single onchain transaction. The same architecture is built to bring the next oracle families (slope2, CAPO, the supply/borrow-cap oracle, and the automated freeze guardian) onto the same router, oracle, and registry, consolidating Aave's risk surfaces on one protocol-owned stack with no change to the integration, transparency, or access-control surface. Motivation When Chaos Labs stepped down from risk management for Aave, the PT risk oracle stack was effectively deprecated. Since then, LlamaRisk has ensured continuity by monitoring the in-scope markets and pushing just-in-time parameter changes through the Risk Stewards path, running its own methodology manually. This transitional path was never meant to be permanent: it carries ongoing manual overhead and key-person risk, and like the system it replaced, it asks the DAO to trust an offchain process it cannot directly verify. That opacity is the core problem this proposal addresses. The prior Chaos Labs setup gave the DAO no visibility into the offchain system that computed its risk parameters, and LlamaRisk observed cases in which the parameters deployed onchain diverged from the published methodology. This proposal moves PT risk onto transparent, protocol-owned infrastructure where the methodology parameters, every input, and every resulting change are recorded onchain and independently verifiable. Computation runs in battle-tested Chainlink CRE workflows, the parameters they read live in an onchain registry, and execution flows through the Risk Agents middleware that Aave Governance already owns. Every published value is signed by a registered CRE workflow and gated by the AgentHub's generic safety checks before it reaches a pool. The linear discount-rate model and the Risk Agents architecture are unchanged; the same risk assumptions hold, now with predictable behavior, clear thresholds, and a public onchain audit trail of every parameter change. Integration Path This proposal leaves the onchain surface Aave Governance owns intact and replaces only the offchain sender. Computation runs in three independent CRE workflows: a single new router, a new middleware layer in front of the Risk Oracle, receives each signed report and, in a single onchain transaction, writes to the Risk Oracle and triggers the existing Risk Agents middleware. Aave Governance still owns every contract; the risk manager only proposes. Overall Flow !image A parameter update moves through four layers: 1. Offchain CRE. Gathers Pendle market state, reads the onchain ParameterRegistry and LlamaguardRiskOracle, runs the methodology rule, and emits one signed report. 2. Router. Validates the report's source tuple, then publishes it and triggers execution in a single atomic step. 3. Oracle and AgentHub. Stores the typed update and re-runs the existing generic safety checks for delay, expiration, replay, and range. 4. Aave-side execution. The typed agent mutates the state on the PendlePriceCapAdapter or the PoolConfigurator. The defining property is one signed report, one atomic onchain transaction. The router decodes the report, publishes to the oracle, calls AgentHub.check, and, if actions are returned, calls AgentHub.execute, all in the same transaction. This collapses a publish step, an offchain keeper poll, and a separate performUpkeep call into a single router call. CRE never holds direct write authority over Aave pool configuration: every mutation goes through a typed agent under the existing AgentHub permission model, and the AgentHub re-runs its full safety checks at execute time regardless of the caller. Chainlink CRE Workflows !image Three CRE workflows share a common library that handles Pendle AMM reads, registry reads, risk-oracle reads, and CRE report signing. Each owns its own publish-and-execute cycle and runs on its own cadence. Two are primary: the discount-rate and risk-parameters workflows, which produce the parameters that reach Aave. The third, the EMA workflow, is peripheral: it supplies a smoothed implied rate that the two primary workflows read. Discount-rate workflow. Consumes the latest r_ema as a single number, applies the rule from the Dynamic Discount Rate section below, and publishes the result as PendleDiscountRateUpdate to the existing RiskOracle for the existing AaveDiscountRateAgent to inject into the PendlePriceCapAdapter. Risk-parameters workflow. Applies the rule from the Dynamic Risk Parameters section below and publishes (LT, LTV, LB) per (PT, E-Mode category) reserve as EModeCategoryUpdate to the existing RiskOracle for the existing AaveEModeAgent. One workflow run can emit multiple records, one per reserve the PT is listed in. The EMA workflow computes a one-step EMA of Pendle's lastLnImpliedRate per PT and publishes it as EmaImpliedRateUpdate, the r_ema that the two primary workflows consume. It has no Aave-side agent and does not directly drive any parameters. All three workflows are deterministic by construction. Reads are taken at finalized confidence; randomness and wall-clock times are taken from the CRE runtime rather than process-local sources; and workflow IDs are pinned per environment and validated by the router on every report. Rotating a workflow requires a coordinated multisig action on the router; it cannot land silently. Smart Contract Stack !image This proposal reuses all contracts on the existing Risk Agents path and adds three new contracts upstream of AgentHub. Reused contracts (AaveOracle, PendlePriceCapAdapter, AgentHub, RangeValidationModule, AaveDiscountRateAgent, AaveEModeAgent) are pulled from aave-address-book per network. The PT price surface and the typed agents that inject discount-rate and E-Mode updates are exactly the same code that Aave Governance already owns. Three new contracts sit upstream of the AgentHub: LlamaguardRiskOracle is a variant of the standard RiskOracle that accepts writes only from the router. It stores the Price EMA and Pool Proportion EMA, keyed by (updateType, market), and exposes the IRiskOracle surface, which the two primary CRE workflows use to obtain the smoothed implied rate and proportion. The router writes it from the pendleemaoracle workflow's signed report. LlamaguardRiskOracleRouter is the onchain atomic actor for every published update. It receives signed CRE reports through the Chainlink Forwarder, validates the source tuple (forwarder, author, workflowName, workflowId) against the workflow registered for that update type, publishes to the RiskOracle, and triggers AgentHub.check / AgentHub.execute in the same transaction. It is designed to route across multiple risk oracles, such as slope2, CAPO, and future workstreams, as they come online. ParameterRegistry is the onchain home for the per-asset risk methodology parameters that the workflows read on every evaluation. It is the same registry shape as audited for LlamaGuard NAV, extended to cover PT and future Oracle families under the same contract. Router authority is not load-bearing for execution safety. The publish call is the load-bearing step: if it reverts, the whole router call reverts, and the workflow retries on the next trigger. The subsequent AgentHub.check / AgentHub.execute calls are best-effort. A revert in either is caught and logged, leaving the oracle record in place for the next router call (or for a permissionless automation call to check and execute) to pick back up. The oracle is the source of truth; injection is a separate concern. !image Note: Due to the character count limitations of Snapshot, the remainder of the forum post cannot be shown, and can be found on the governance forum linked below.

Summary This ARFC operationalises two changes surfaced after the active incident response management over the past months. First, the Risk Steward minDelay is reduced from 72 hours to 36 hours on six cap and IRM parameters where the conservative cap posture meaningfully constrains response speed. Second, the pause role on Aave Umbrella stkTokens is reassigned to the Aave Protocol Guardian, the standing Aave-wide emergency multisig that already holds pause and freeze authority across Aave deployments, with all other Umbrella governance action permissions remaining with the Aave Governance Executor. The cooldown change addresses a friction surfaced over the past month as LlamaRisk has tightened supply and borrow caps on listed assets closer to their current utilisation. This conservative cap posture is the principal lever Aave has used to bound exposure. It has, however, a structural side effect: when caps sit close to organic demand, the 72-hour Risk Steward cooldown becomes a binding constraint on the next cap raise after the demand suddenly increases, turning the defensive posture into a blocker on healthy growth. Reducing minDelay to 36 hours on the seven cap and IRM parameters relieves this constraint without weakening any maxPercentChange bound. In parallel, Umbrella pause reassignment addresses the operational friction observed when stkwaWETH had to be paused during the rsETH incident response. The PAUSEGUARDIANROLE on Umbrella (which governs both pause and unpause) currently sits behind the Aave Governance Executor rather than behind Aave's standing emergency body, which meant the action had to be routed through a full AIP cycle. Reassigning PAUSEGUARDIANROLE to the Aave Protocol Guardian, the multisig that already holds emergency pause authority across the rest of the protocol, restores the role assignment originally specified at Umbrella's activation and ensures that future stkToken pauses can be executed at incident response speed. Configuration authority on Umbrella (token creation, parameter changes, role management under DEFAULTADMINROLE) remains solely with the Aave Governance Executor. Motivation On the Risk Stewards, the more conservative cap posture taken over the past month limits the operational levers available to balance the protocol's needs and safety. When caps are sized closer to current utilisation, legitimate organic growth on a healthy asset more frequently bumps into the 72-hour Risk Steward cooldown. The defensive posture, intended to keep collateral exposure under control, turns into a cap on legitimate organic flow. On Umbrella, the [[Direct-to-AIP] Pause stkwaWETH Umbrella Staked Token on Ethereum V3](https://governance.aave.com/t/direct-to-aip-pause-stkwaweth-umbrella-staked-token-on-ethereum-v3/24595) had to be proposed through a full governance vote because pause authority on Umbrella currently sits behind the Aave Governance Executor, rather than Aave's standing emergency pause body. This is a direct departure from the role assignment specified in the [[ARFC] Aave Umbrella - activation](https://governance.aave.com/t/arfc-aave-umbrella-activation/21521) proposal, which explicitly stated that emergency pause and unpause authority would belong to the Aave Protocol Guardian. Part 1: Risk Stewards Cooldown Reduction Background The current Risk Steward RiskConfig enforces per-parameter constraints, where: minDelay is the minimum time between consecutive changes to the same parameter on the same reserve. maxPercentChange is the largest single-step change accepted, with semantics that vary by parameter: collateral and rate parameters use absolute difference bounds, cap parameters use relative difference of the current cap. The proposed change reduces minDelay from 72 hours to 36 hours on the seven cap and IRM parameters where the defensive cap posture meaningfully constrains response speed. The higher-impact collateral and E-Mode parameters (base LTV, LT, LB and their E-Mode equivalents, both price caps) stay at the 72-hour minimum because changes there have a larger downstream effect on existing positions. The Pendle discount rate stays at its existing 48-hour minimum, already tighter than the cap and IRM cadence proposed here. maxPercentChange bounds are unchanged across every parameter under this proposal. The intent is symmetric with the previewed Cap Oracle defensive automation: a faster downward path on caps through the oracle automatization, and a faster upward path on caps and rates through tighter manual cadence, so that the defensive cap posture does not turn into a soft cap on legitimate organic growth. Proposed Configuration Change | Parameter | Current minDelay | Current maxPercentChange | Proposed minDelay | | :--- | :--- | :--- | :--- | | ltv | 72h | 50 bps (0.50% absolute) | - | | liquidationThreshold | 72h | 50 bps (0.50% absolute) | - | | liquidationBonus | 72h | 50 bps (0.50% absolute) | - | | eMode ltv | 72h | 50 bps (0.50% absolute) | - | | eMode liquidationThreshold | 72h | 10 bps (0.10% absolute) | - | | eMode liquidationBonus | 72h | 50 bps (0.50% absolute) | - | | baseVariableBorrowRate | 72h | 100 bps (1.00% absolute) | 36h | | variableRateSlope1 | 72h | 100 bps (1.00% absolute) | 36h | | variableRateSlope2 | 72h | 2000 bps (20.00% absolute) | 36h | | optimalUsageRatio | 72h | 300 bps (3.00% absolute) | 36h | | supplyCap | 72h | 10000 bps (100% relative) | 36h | | borrowCap | 72h | 10000 bps (100% relative) | 36h | | priceCapLst | 72h | 500 bps (5.00% relative) | - | | priceCapStable | 72h | 50 bps (0.50% relative) | - | | discountRatePendle | 48h | 2.50% absolute | - | Part 2: Umbrella Pause Guardian Reassignment Background Umbrella was deployed with pause and configuration changes routed through the UmbrellaEthereum PERMISSIONEDPAYLOADSCONTROLLER (0xF86F77F7531B3374274E3f725E0A81D60bC4bB67) and its executor (0x2759de67aD133C747C9f41d56F1b8A343cE679a1). In practice this means any pause action on an Umbrella stkToken requires a full AIP cycle, which is what happened during the rsETH response when stkwaWETH had to be paused. The original role specification in the [[ARFC] Aave Umbrella - activation](https://governance.aave.com/t/arfc-aave-umbrella-activation/21521) proposal assigned StakeToken pause to the Aave Protocol Guardian, listing under "Permissioned actions & roles" the explicit line "Emergency pause and unpause: Aave Protocol Guardian." The current Umbrella deployment does not reflect that assignment. The Aave Protocol Guardian on Ethereum Core is Aave's standing emergency multisig. It is a community-elected 4-of-7 multisig, and it already holds emergency authority on Aave's other safety surfaces, including market pause and reserve freeze across Aave deployments and emergency-mode actions on cross-chain messaging. Reassigning Umbrella pause to this multisig consolidates Aave's emergency authority under the body that exists for exactly this purpose, restores the role assignment originally specified at Umbrella's activation, and removes the AIP-cycle bottleneck observed during the rsETH response. Proposed Reassignment The role separation in this proposal runs along the emergency vs. configuration axis rather than along pause vs. unpause. The Umbrella contract uses OpenZeppelin AccessControl, and pauseStk and unpauseStk on UmbrellaStkManager are both protected by a single PAUSEGUARDIANROLE that cannot be split between two holders. Pause and unpause therefore move together, and the question is which body should hold that combined emergency role. PAUSEGUARDIANROLE is assigned to the Aave Protocol Guardian, the standing 4-of-7 Aave-wide emergency multisig described above. This adheres the assignment specified in the activation ARFC, removes the AIP-cycle bottleneck on pause action, and aligns Umbrella with the body that already holds emergency authority on Aave's other safety surfaces. Because pause and unpause are bound to the same role, the Protocol Guardian also holds unpause: reversing an precautious pause does not require a governance vote, which is consistent with how emergency pause and unpause work on other Aave surfaces today. DEFAULTADMINROLE and the remaining configuration roles on Umbrella stay with the Aave Governance Executor. This covers token creation, parameter changes, asset onboarding to Umbrella, modification of coverage scope, role grants and revocations, and any other deliberate configuration action. These remain on the AIP cadence, where they belong. Stake Tokens in Scope PAUSEGUARDIANROLE is held on the Umbrella controller and is used to pause and unpause individual stkTokens via the pauseStk(address) and unpauseStk(address) entry points. Granting the role at the controller is sufficient to cover all current and future stkTokens managed by the controller. The currently deployed Ethereum stkTokens are: !Screenshot 2026-06-22 at 18.52.21.png

Overview Umbrella was introduced to provide protocol level protection against insolvency events by maintaining dedicated liquidity reserves across key markets. The initial configuration of Target Liquidity and emission levels (maxEmissionPerSecond) was set based on the risk profile, market conditions, and borrowing activity observed at launch. Since then, several aspects of the protocol and broader market environment have evolved. Active loan volumes across Umbrella covered markets have declined materially; the composition of collateral backing these loans has shifted toward higher quality assets, protocol protections have strengthened, and yield conditions across DeFi have changed significantly. These developments may impact both the amount of liquidity required for Umbrella and the level of incentives necessary to attract and retain coverage providers. This publication reviews the current configuration of the USDC, USDT, GHO, and ETH Umbrella markets to determine whether existing Target Liquidity levels, emission budgets, and associated APY ranges remain aligned with current protocol risks and market conditions. Upon evaluating changes in borrowing activity, collateral composition, coverage capacity, and competitive yield opportunities, this publication presents clear recommendations for each Umbrella market that balance the need to maintain effective protection with improvements in capital efficiency and incentive utilisation. Framework for Umbrella Liquidity Requirements The primary objective of Umbrella is to maintain sufficient liquidity to absorb protocol deficits while minimizing the cost of providing that protection. As a result, both Target Liquidity and emission levels should reflect the protocol's underlying risk exposure and evolve with changing market conditions. At a high level, protocol deficits arise when collateral securing outstanding debt cannot be liquidated for sufficient value to fully repay the borrower's obligations. The likelihood and severity of such losses depend on a combination of factors, including the size of the active loan book, the quality and composition of collateral backing those loans, the leverage employed by borrowers, and the market's ability to absorb liquidation activity during periods of stress. The size of the active loan book serves as the starting point for evaluating coverage requirements. Declining loan balances reduce the amount of debt that can ultimately contribute to deficit creation. However, the amount of outstanding debt alone does not determine risk. The characteristics of the collateral securing that debt are equally important. Assets with deeper liquidity, lower volatility, and stronger market adoption generally exhibit greater resilience during periods of market stress than more volatile or less liquid assets. In addition, collateral risk is influenced by how assets are configured within the lending market, including parameters such as LT, LB and other controls that determine borrower leverage and liquidation behaviour. Borrower equity provides an additional layer of protection by representing the excess value of collateral relative to outstanding debt. This equity acts as a loss absorbing buffer that must be exhausted before protocol deficits can occur. As a result, larger equity buffers increase the magnitude of adverse market movements required to impair borrower positions and reduce the protocol's exposure to insolvency events. Potential liquidation demand during adverse market conditions is another key consideration. The protocol's exposure is influenced by the market's capacity to absorb liquidation volume without a significant price impact. Markets supported by deep on-chain and off-chain liquidity are better equipped to process liquidations efficiently and reduce the likelihood of losses being realised. In addition to market driven factors, protocol level protections influence the amount of liquidity that must ultimately be maintained within Umbrella. Mechanisms such as reserve specific Deficit Offsets provide a first layer of protection against losses and reduce the amount of exposure that must be covered by Umbrella liquidity providers. Together, these factors determine the amount of liquidity required to support a given market. While risk conditions influence the quantity of coverage needed, the incentives paid to attract that coverage are largely determined by the opportunity cost faced by underwriters. As yield opportunities across DeFi and broader markets change, the compensation required to attract and retain Umbrella stakers may also change. Consequently, the assessment of Target Liquidity and emissions should consider both the evolution of protocol risk and changes in the opportunity cost of providing coverage. The following sections evaluate how these drivers have evolved since Umbrella's launch and assess whether the current Target Liquidity, emission budgets, and APY configurations remain aligned with prevailing protocol risks and market conditions. Recommendation Based on the analysis presented above, we recommend updating Umbrella Target Liquidity and emission configurations for the USDC, USDT, and WETH markets, while sunsetting the GHO Umbrella market and transitioning responsibility for any future deficits to the DAO Treasury. The primary drivers behind these recommendations are the material reduction in active borrowing activity, improvements in collateral quality across the stablecoin markets, and the substantial increase in reserve specific Deficit Offsets since Umbrella's launch. Aggregate active loans across covered markets declined by approximately 43%, reducing the amount of debt that ultimately requires protection. At the same time, collateral quality improved across the stablecoin markets, with a larger share of borrowing now backed by highly liquid ETH, BTC, and stablecoin collateral. In addition, Deficit Offsets increased substantially, particularly for the USDC and USDT markets, providing a significantly larger DAO funded first loss buffer before Umbrella liquidity is exposed to realized losses. Taken together, these developments support lower Target Liquidity requirements across the Umbrella ecosystem. The magnitude of the proposed adjustments varies by market. Larger reductions are proposed for the USDC and USDT markets, where collateral quality improved materially, and Deficit Offsets increased significantly since launch. A more conservative adjustment is proposed for the WETH market. Although active borrowing declined materially, the composition of collateral backing WETH borrowing shifted toward liquid restaking assets. The recommended emission updates are designed to align with the revised Target Liquidity levels while maintaining competitive yields for Umbrella participants. For the USDC and USDT markets, only modest reductions to the target Umbrella APY are proposed. The recommended yields remain competitive relative to alternative stablecoin lending and yield generating opportunities while reflecting the improved risk profile of these markets. For WETH, the target Umbrella APY is increased despite the reduction in Target Liquidity. This adjustment is intended to attract additional coverage to a market that has historically been underserved. For GHO, borrowing has declined to $100 million. Given the relatively small size of the market, maintaining a dedicated Umbrella reserve and ongoing emissions is no longer the most efficient mechanism for providing protection. As a result, we recommend sunsetting GHO within Umbrella by reducing Target Liquidity and emissions to zero. To facilitate an orderly wind down of the market, we also recommend increasing the GHO Deficit Offset to 3 million GHO. The purpose of this increase is to protect existing stakers during the transition period. Since GHO stakers will no longer receive emissions after the proposed changes are implemented, the higher Deficit Offset ensures that deficits are absorbed by the DAO before any slashing can occur while stakers unwind their positions and withdraw from the market. Once emissions and Target Liquidity for the GHO Umbrella market are reduced to zero, any future deficits generated by the GHO reserve would be covered by the Treasury. From an emissions perspective, the proposed configuration reduces annual incentive expenditure from $8.19 million to $3.35 million, representing annual savings of $4.84 million, or approximately 59%. The largest reductions are achieved within the USDT, GHO, and USDC markets, which together account for more than 97% of the total savings. !Image.png Overall, the proposed configuration reduces annual emission expenditure while preserving meaningful coverage, maintaining competitive yields for underwriters, and aligning Umbrella parameters more closely with current protocol risk and market conditions. Specification !Specification 1.png !Specification 2.png Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission.

[ARFC] Onboard stcUSD to Aave V3 MegaETH Author: Aave Labs Date: 2026-06-19 Summary This ARFC proposes onboarding stcUSD to the Aave V3 MegaETH instance. This listing would initially enable users to deposit stcUSD to earn yield and borrow stable assets to earn leveraged yield on their yield-bearing asset. Motivation stcUSD is the staked, yield-bearing component of Cap Protocol. Users mint stcUSD by staking cUSD, with yield generated from the underlying cUSD collateral and protocol-level yield mechanisms. Supplying stcUSD as collateral lets holders keep earning stcUSD yield while borrowing stablecoins against their position. This adds incremental stablecoin borrow demand on the MegaETH instance, making it more attractive for stablecoin suppliers over time. LlamaRisk has already provided the risk assessment for stcUSD. Specification This ARFC proposes to onboard stcUSD as a collateral asset to the Aave V3 MegaETH market. Market: Aave V3 MegaETH Asset: stcUSD Token Address: 0x88887bE419578051FF9F4eb6C858A951921D8888 Reference Asset: cUSD cUSD Token Address: 0xcCcc62962d17b8914c62D74FfB843d73B2a3cccC Risk Parameters Risk Parameters provided by Risk Service Providers. Asset Configuration | Parameter | Value | |-----------|---------| | Asset | stcUSD | | E-Mode | Stablecoin | | Borrowable | No | | Collateral Enabled | No | | Supply Cap | 10,000,000 | | Borrow Cap | - | | Debt Ceiling | - | | LTV | - | | LT | - | | Liquidation Bonus | - | | Liquidation Protocol Fee | 10% | | Reserve Factor | - | | Base Variable Borrow Rate | - | | Variable Rate Slope 1 | - | | Variable Rate Slope 2 | - | | Uoptimal | - | stcUSD Stablecoin E-Mode | Parameter | Value | |-----------|-------| | Isolated | True | | LTV | 88% | | LT | 90% | | Liquidation Bonus | 4% | | Asset | stcUSD | USDT0 | USDM | |--------|--------|--------|--------| | Collateral | Yes | No | No | | Borrowable | No | Yes | Yes | Next Steps 1. If the ARFC Snapshot passes, proceed to AIP for final DAO approval and execution. Disclaimer Aave Labs is presenting this proposal as a service provider to the Aave DAO. Aave Labs is contributing this proposal as part of its approved scope of work in support of DAO operations. Copyright Copyright and related rights waived via CC0.

Author Certora Date April 2026 We would like to share this proposal with the Aave community to gather early feedback on a new security initiative being developed in collaboration with leading protocols and the Ethereum Foundation. Note: We are aware of the ongoing efforts around recent ecosystem events and do not expect immediate feedback. This ARFC is shared now for early visibility and initial thoughts, and we are happy to engage in deeper discussion once things stabilize. Summary We propose that the Aave DAO participate as a founding sponsor in the development of Certora Concord, an open-source equivalence-checking framework designed to formally verify that smart contract upgrades — including compiler upgrades, optimizations, and refactors — preserve protocol behavior. Aave would contribute $50,000 USD as part of a co-funded ecosystem initiative, alongside other leading protocols, unlocking matching funding from the Ethereum Foundation. This initiative introduces a new security primitive for Aave: Formal, machine-checked guarantees that upgrades do not introduce unintended behavioral changes. Motivation Aave is a long-lived, continuously evolving protocol with: Frequent upgrades and governance proposals Increasing complexity (v4 and multi-chain deployments) Strong reliance on safe execution of changes However, today: Even small changes (compiler upgrades, optimizations, refactors) can introduce subtle bugs These issues are difficult or impossible to detect via testing alone Post-audit changes often require expensive re-audits This creates: Upgrade risk Operational overhead Slower innovation cycles Proposed Solution: Certora Concord Certora Concord is an equivalence-checking framework that: Compares two smart contracts at the bytecode level Proves whether they are behaviorally equivalent across all possible executions Produces counterexamples when differences exist Unlike testing or fuzzing: Concord is exhaustive, not probabilistic Covers all inputs and execution paths Verifies externally observable behavior (state, calls, events) In practice Compile the same contract with two compiler versions → prove equivalence Compare pre/post upgrade contracts → ensure no unintended behavior changes This directly addresses core risks in Aave’s lifecycle. Why This Matters for Aave 1. Safer Upgrades Guarantee that: Compiler upgrades Gas optimizations Refactors Do not change protocol behavior 2. Reduced Audit Overhead Avoid full re-audits for non-functional changes Focus audits only where behavior actually changes 3. Governance Confidence Provide stronger guarantees for AIPs Reduce the risk of introducing bugs through governance 4. Ecosystem Leadership Aave becomes: A founding sponsor of a new verification primitive A leader in advancing formal security standards in DeFi Scope of Work Certora will: 1. Develop Concord, integrated with the Certora Prover 2. Provide: - CLI tooling - GUI interface for equivalence analysis 3. Open-source the tool and documentation 4. Maintain and extend Concord for at least 18 months 5. Deliver: - Real-world equivalence analyses - Documentation and best practices - Ecosystem-facing education and content Funding Structure This is a co-funded ecosystem initiative: 4 sponsors (including Aave): $50,000 each Total ecosystem funding: $200,000 Ethereum Foundation match: $200,000 Total project funding: $400,000 Aave’s contribution unlocks: Additional funding from the Ethereum Foundation Shared development costs across leading protocols Timeline Initial production-ready version: 3 months Ongoing development & maintenance: 15+ months Deliverables include: Tooling Documentation Case studies Continuous improvements Benefits to Aave Technical Benefits Early access to Concord tooling Ability to apply it directly to Aave upgrades Reduced upgrade risk and audit overhead Strategic Benefits Recognition as a Concord Ecosystem Sponsor Visibility in: - Technical publications - Case studies - Ecosystem initiatives Financial Efficiency Leverages Ethereum Foundation matching → amplified impact per dollar Specification The proposal requests: A one-time payment of $50,000 USD Paid to Certora for Concord development Subject to standard DAO execution process Next Steps 1. Gather community feedback on this ARFC 2. If consensus is reached: - Move to Snapshot vote 3. If Snapshot passes: - Submit AIP for execution Disclaimer Certora is presenting this proposal independently and is not compensated by any third party for creating this ARFC. Copyright Copyright and related rights waived via CC0.

!image Summary This ARFC proposes deploying Aave Protocol v3.7 on the Monad Network. Motivation Monad’s pipelined EVM architecture delivers fast, high-throughput performance while remaining fully compatible with Ethereum, making it ideal for real-time financial applications. This directly supports the needs of neobanks and fintech platforms, which rely on quick transaction finality, scalability, and predictable costs. By deploying Aave v3 on Monad, the ecosystem gains a proven liquidity layer that enables lending, borrowing, yield generation, and stablecoin infrastructure. Because of Monad's full EVM compatibility, Aave can be integrated quickly with minimal changes, making it easier for existing Ethereum builders to adopt. Together, these positions Aave as the core liquidity engine within Monad, helping attract early users and capital while supporting the next generation of scalable, on-chain financial products. Incentives Package Monad Foundation will provide the following within the first twelve months of the Aave Protocol activation proposal being executed: $15M USD in incentives measured at the block when ACI distributes rewards via MASIv infrastructure 10M units of GHO will be acquired and retained for more than 6-months whilst respecting considerations for managing operating capital The Aave DAO will provide the following within the first twelve months of the Aave Protocol activation proposal being executed: 0.50M units of GHO incentives to be distributed to support the growth and adoption of GHO on the Monad network The Monad Foundation reserves the right to determine whether and when to migrate to Aave v4. Specification The below will be updated upon receiving feedback from various stakeholders in the lead-up to the deployment. General Configuration | Parameters | Value | Value | Value | Value | Value | Value | Value | Value | Value | Value | Value | Value | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | Asset | USDT0 | USDC | GHO | USDe | mUSD | AUSD | wETH | cbBTC | wstETH | weETH | syrupUSDC | sUSDe | | Isolation mode | No | No | No | No | No | No | No | No | No | No | No | No | | Borrowable | Yes | Yes | Yes | Yes | Yes | Yes | No | No | No | No | No | No | | Collateral enabled | Yes | Yes | Yes | No | No | No | Yes | Yes | No | No | No | No | | Supply Cap | 100,000,000 | 75,000,000 | 20,000,000 | 60,000,000 | 100,000,000 | 20,000,000 | 40,000 | 1,000 | 35,000 | 30,000 | 40,000,000 | 60,000,000 | | Borrow Cap | 100,000,000 | 50,000,000 | 18,000,000 | 50,000,000 | 50,000,000 | 18,000,000 | 36,000 | - | - | - | - | - | | Debt Ceiling | - | - | - | - | - | - | - | - | - | - | - | - | | LTV | 75.00% | 75.00% | 75.00% | - | - | - | 80.50% | 73.0% | - | - | - | - | | LT | 78.00% | 78.00% | 78.00% | - | - | - | 84.00% | 78.00% | - | - | - | - | | Liquidation Bonus | 7.50% | 7.50% | 7.50% | - | - | - | 5.50% | 7% | - | - | - | - | | Liquidation Protocol Fee | 5% | 5% | 5% | - | - | - | 5.5% | 5.5% | - | - | - | - | | Variable Base | 0.0% | 0.0% | 0.0% | 0.0% | 0.0% | 0.0% | 0.00% | - | - | - | - | | | Variable Slope1 | 4.0% | 4.0% | 4.0% | 4.0% | 4.0% | 4.0% | 2.20% | - | - | - | - | - | | Variable Slope2 | 40.0% | 40.0% | 40.0% | 40.0% | 40.0% | 40.0% | 20.0% | - | - | - | - | - | | Uoptimal | 90.0% | 90.0% | 90.0% | 90.0% | 80.0% | 80.0% | 90.0% | - | - | - | - | - | | Reserve Factor | 10.0% | 10.0% | 10.0% | 25.0% | 10.0% | 10.0% | 15.0% | 7.0% | 5.0% | 45.0% | 10.0% | 10.0% | | Stable Borrowing | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | Disabled | | Flashloanable | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | Yes | | Siloed Borrowing | No | No | No | No | No | No | No | No | No | No | No | No | | Borrowed in Isolation | No | No | No | No | No | No | No | No | No | No | No | No | | E-Modes | 1, 2, | 1, 2 | 1, 2 | 1, 2 | 1 | 1, 2 | 3, 4 | | 3 | 4 | 1 | 2 | eMode #1 - Maple syrupUSDC | Parameter | Value | Value | Value | Value | Value | Value | | --- | --- | --- | --- | --- | --- | --- | | Asset | syrupUSDC | USDT0 | USDC | GHO | mUSD | AUSD | | Collateral | Yes | No | No | No | No | No | | Borrowable | No | Yes | Yes | Yes | Yes | Yes | | Max LTV | 90.00% | - | - | - | - | - | | Liquidation Threshold | 92.00% | - | - | - | - | - | | Liquidation Bonus | 4.00% | - | - | - | - | - | eMode #2 - Liquid Leverage | Parameter | Value | Value | Value | Value | Value | Value | | --- | --- | --- | --- | --- | --- | --- | | Asset | sUSDe | USDe | USDT0 | USDC | GHO | AUSD | | Collateral | Yes | Yes | No | No | No | No | | Borrowable | No | No | Yes | Yes | Yes | Yes | | Max LTV | 90.00% | 90.00% | - | - | - | - | | Liquidation Threshold | 92.00% | 92.00% | - | - | - | - | | Liquidation Bonus | 4.00% | 4.00% | - | - | - | - | eMode #3 - Lido Yield Maximiser | Parameter | Value | Value | | --- | --- | --- | | Asset | wstETH | wETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 94.00% | - | | Liquidation Threshold | 96.00% | - | | Liquidation Bonus | 1.00% | - | eMode #4 - EtherFi Yield Maximiser | Parameter | Value | Value | | --- | --- | --- | | Asset | weETH | wETH | | Collateral | Yes | No | | Borrowable | No | Yes | | Max LTV | 93.00% | - | | Liquidation Threshold | 95.00% | - | | Liquidation Bonus | 1.00% | - | Aave DAO’s Contribution Create an allowance for 0.5M aEthLidoGHO from Aave V3 Prime on Ethereum: Asset: aEthLidoGHO: 0x18eFE565A5373f430e2F809b97De30335B3ad96A Amount: 0.5M Spender: AFC 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa Method: approve() aEthLidoGHO on the Aave Collector contract to the Aave Finance Committee (AFC) address. GHO Stablecoin Activate GHO Lane Currently, the CCIP Bridge to Monad Network is v1.5 and requires upgrading to v1.6 before GHO lanes are established. TokenLogic will work with Chainlink to sync upgrade timelines and extend the new GHO lanes to/from the Monad Network Current CCIP Bridge Configuration, which may change prior to implementation. The Gho Lane Activation uses the parameters in effect when the AIP is submitted. Bucket Capacity: 100M GHO Inbound Capacity: 1.5M GHO Outbound Capacity: 1.5M GHO Refill Rate: 300 GHO/sec Deploy GHO Stewards GhoAaveSteward updateGhoBorrowCap: ±100% updateGhoBorrowRate: ±5% on optimal usage ratio, base variable rates, slopes updateGhoSupplyCap: Up to +100% GhoGsmSteward updateGsmExposureCap: ±100% updateGsmBuySellFees: ±0.5% per side (FixedFeeStrategy) Both stewards remain callable only by the GHO steward protocol. GhoCcipSteward updateBridgeLimit : ±100% updateRateLimit: ±100% GhoBucketSteward updateFacilitatorBucketCapacity : ±100% Deploy stataUSDT0 remoteGSM | Parameter | Value | | --- | --- | | GHO Bucket Cap | 50M GHO | | stataUSDT0 Exposure Cap | 40M | | Freeze Lower Bound | $0.990 | | Freeze Upper Bound | $1.010 | | Unfreeze Lower Bound | $0.995 | | Unfreeze Upper Bound | $1.005 | | Mint GHO Fee | 0% | | Burn GHO Fee | 0.10% | USDT0 deposits into stataUSDT0 trigger GHO transfers using Ethereum-held inventory via GSM. 3. Mint and bridge 50,000,000 GHO Mint 50M GHO from the GhoDirectFacilitator and bridge to Monad via CCIP to Monad’s Collector. | Parameter | Value | | --- | --- | | Facilitator | 0x2bd010Ab5393AB51b601B99C4B33ba148d9466e9 | | GhoReserve (Ethereum) | 0x54C58157DeF387A880AE62332D1445f03adbE7E9 | | Mint Amount | 50,000,000 GHO | | New Facilitator Bucket Level | 150,000,000 GHO (100% of capacity) | 4. Fund GhoReserve from Collector From Collector, transfer to GhoReserve deployed on Monad for use by GSM. | Parameter | Value | | --- | --- | | Source Chain | Ethereum | | Destination Chain | Monad (CCIP selector: ) | | GHO CCIP Token Pool (Ethereum) | 0x06179f7C1be40863405f374E7f5F8806c728660A | | GHO CCIP Token Pool (Monad) | 0x360d8aa8F6b09B7BC57aF34db2Eb84dD87bf4d12 | | Destination (Monad GSM) | 0x6aC541605b0317dE076C9FeC2842902c844dEa74 | | Amount | 50,000,000 GHO | Additionally, after a trial period with a maximum bridge amount of 1.5M across any network and a refill rate of 300 GHO per second, we are increasing the maximum bridge amount to 5.0M and the refill rate to 1,000 GHO per second. Disclosure TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. 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 In preparation for launching sGHO on the Arbitrum network, this publication proposes deploying a new instance of remoteGSM, allowing users to exchange stataUSDC <> GHO. Motivation The GSM has proven to be a capital-efficient way to seed and defend GHO's peg, with demand that materialises organically. The remoteGSM deployed on Plasma is filled to its full 40M exposure cap and now represents more than 13% of the circulating supply of GHO, clear evidence that users will mint GHO directly on the chain they want to use it and drive local demand. !top image.png This proposal replicates that playbook on Arbitrum using USDC. Alongside the upcoming sGHO launch, the remoteGSM gives GHO a deep, local peg anchor on one of DeFi's largest stablecoin markets from day one. It launches with a conservative 20M exposure cap as a starting point, which the GhoGsmSteward can scale up as demand fills it, the same path Plasma walked to 40M. Specification The sections below provide the necessary technical details and some high-level context guiding the flow of funds and steward controls. 1. Update CCIP Bridge Limit Configuration As GHO has grown and matured, we see a need to increase the rate-limits imposed by CCIP. The table below shows the current configuration and the new configuration for all lanes (ie: across all networks) after the upgrade. !Fifth bottom Image.png Additionally, the Ethereum ↔ Arbitrum rate limits will be temporarily increased to 155M, allowing a single transaction to bridge 50M of GHO. After the bridge succeeds, the limits will be restored to the newly proposed 5M and 1,500 and the Bucket Capacity to 100M as shown above. This was the same approach that was taken when bridging 50M GHO to Plasma. 2. Deploy GhoReserve When Minting and bridging unbacked GHO to new networks, the GhoReserve is deployed as the final destination for receiving those funds. This allows the GHO to be held in isolation until being assigned to an intended use case, such as funding remoteGSM or depositing into the Aave Protocol. The ability to Mint → Bridge → Fund the GhoReserve is only possible via AIP, and for avoidance of doubt, not possible via the Gho Steward admin role. The Gho Steward can set a limit on how much GHO an entity, such as each remoteGSM, can draw. !fourth Bottom Image.png 3. Deploy stataUSDC remoteGSM With GHO held in the GhoReserve, the remoteGSM enables users to exchange stataUSDC to GHO, equivalent to the exchange rate minus any fee when GHO enters/exits the circulating supply. With the exception of the Exposure Cap, all other parameters are to match those of the other stataUSDC GSM. Any changes between this forum comment and the AIP's submission for a vote will be reflected in the AIP itself to ensure consistency with the USDC GSM on Ethereum. !Third Bottom Image.png USDC deposits into stataUSDC trigger GHO transfers using Arbitrum-held inventory via GSM. When deploying and funding GhoReserve and remoteGSM on Arbitrum, the current parameters of Ethereum and Plasma GSM will remain unchanged, ensuring that the GHO system configuration matches the configuration used throughout the testing phase prior to deployment. 4. Deploy GHO GSM Steward The Gho Steward admin role is extended with new functionality for updating and maintaining the remoteGSM parameters. GhoGsmSteward updateGsmExposureCap: ±100% updateGsmBuySellFees: ±0.5% per side (FixedFeeStrategy) The steward is callable only by the GHO steward SAFE (Risk Council). Additionally, the Gho Steward admin will be granted the LIMITMANAGERROLE on the Arbitrum GhoReserve in order to be able to update the draw limit of the remoteGSM. 5. Mint and bridge 50,000,000 GHO Mint 50M GHO from a newly deployed GhoDirectFacilitator and bridge to Arbitrum via CCIP to Aave DAO’s Collector Contract (Treasury). !Second Bottom Image.png To receive the 50M GHO on Arbitrum, a new instance of the AaveGhoCCIPBridge will be deployed and configured to forward all received tokens to the Collector. The same approach was used for the Plasma deployment. 6. Fund GhoReserve from Collector From the Collector Contract on Arbitrum, transfer 50M GHO to the GhoReserve deployed on Arbitrum for use by the GSM. !Bottom Image.png Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If the snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

Summary This proposal follows the March 2026 signer update and achieves two key goals. Refreshes the signer composition across the seven budget / asset-holding SAFEs as the Aave service provider roster consolidates. Strengthens the configuration of these SAFEs so that each is controlled by a 2-of-3 signer set in which every signer is an independent, organisation-controlled Nested SAFE. Motivation With the number of Aave service providers consolidating, this publication proposes consolidating the SAFE signers among the remaining active service providers to govern the movements of the Aave DAO’s funds. In addition to updating the signers, this proposal aligns the budget/asset-holding SAFEs with the structure that utilises Nest Safes, introducing a model in which the entities holding signing power are themselves multi-signature accounts, rather than a flat list of individual keys. Adopting this now, while the roster is being refreshed, avoids a second disruptive change later and brings the budget / asset-holding SAFEs in line with current best practice. The emphasis of this update is the security architecture rather than the composition of any individual signer group. In line with established treasury security practice, individual signer identities have been omitted. Security Architecture Overview Treasury operations managed through these SAFEs follow a two-layer model. Layer 1, the budget / asset-holding SAFEs (anchors). These SAFEs receive funds from the Aave Collector. They are the security anchors of the structure and are each configured as a 2-of-3 signer set, where each of the three signers is an independent, organisation-controlled Nested SAFE. Funds at this layer are protected by the combination of an organisation-level quorum and each organisation's own internal signing controls. Layer 2, the Operations SAFEs. The Operations SAFEs do not hold idle treasury. Each draws only the funds it needs, when it needs them, by pulling capped amounts from its associated budget SAFE through on-chain spending-limit allowances. This keeps the value held in working wallets to a minimum at all times. !Signer Image.png The configuration rests on the following principles, drawn from established security frameworks: Hot and cold separation, defence in depth. Value concentrates at a single, well-protected anchor, while day-to-day operations run through tightly scoped wallets that hold little or nothing at rest. Organisation-controlled Nested SAFEs. Each signer on a budget SAFE is a multi-signature account operated by one organisation. This decouples the organisation-level quorum (2-of-3) from each organisation's internal key management. An organisation can rotate its internal signers locally without requiring a DAO-level signer change, and no single individual can act on behalf of the organisation. Separation of proposal and signing. Transaction creation is delegated to proposer addresses, held on personal cold wallets, that can queue transactions but carry no signing authority. This keeps day-to-day transaction preparation simple and low-friction, while approval and execution remain exclusively with the organisation-controlled Nested SAFEs. Preparing a transaction and authorising it are deliberately kept as separate privileges. OpSec by construction. Because signing power sits at the organisational level, individual signers are not exposed on-chain or in governance documentation, reducing the personal targeting surface for those involved. Just-in-time, capped funding. On-chain spending-limit allowances govern how much each Operations SAFE can draw and how often, so the amounts moved are bounded and auditable, and the treasury is never left idle in operational wallets. Redundancy and continuity. The 2-of-3 threshold preserves execution reliability if any single organisation is temporarily unavailable, without lowering the bar for unilateral action. Specification Signing Organisations Each budget / asset-holding SAFE is signed by the same three independent organisations, each operating its own Nested SAFE: | Name | Address | |----|----| | Signer 1 | 0xa2DCdD6e0b5e0d118E2Fa8922552AC0Fe26EFe58 | | Signer 2 | 0xb291232F480F41c75802C4a60F1D2AC03404Afef | | Signer 3 | 0x4b752551fC6345A7de82F76fd7a5015CA16d1a74 | Consistent with the security objectives above, the individual signer address and name within each organisation's Nested SAFE have been omitted, whilst the signing addresses across the Operational SAFEs have been included in this proposal. | Name | Address | |----|----| | Signer 1 | 0x25044f197127209b397987f387A5680A485F15eF | | Signer 2 | 0x8f28a95CDded08C36883477D96d751412915DCD4 | | Signer 3 | 0xCAC616Fffb687cBDDD250b2aE6F672449462985C | | Signer 4 | 0xb647055A9915bF9c8021a684E175A353525b9890 | | Signer 5 | 0x45d11217458aEE68A4D976A8f17e2E24Fc5898A1 | | Signer 6 | 0x009d13E9bEC94Bf16791098CE4E5C168D27A9f07 | | Signer 7 | 0x606dC57cd166643760E049609bfd1D8a698D3bAc | Budget / Asset-Holding SAFEs Each of the seven active budget / asset-holding SAFEs is configured as 2-of-3, with each signer being one of the three organisation-controlled Nested SAFEs listed above: | Name | Address | |----|----| | Aave Protocol Embassy (APE) | 0xAA43203167317DeeF8288095C44b84a686918d2E | | Aave Liquidity Committee (ALC) | 0xA1c93D2687f7014Aaf588c764E3Ce80aF016229b | | Aave Helper Asset Budget (AHAB) | 0xAA2461f0f0A3dE5fEAF3273eAe16DEF861cf594e | | Aave Finance Committee (AFC) | 0x22740deBa78d5a0c24C58C740e3715ec29de1bFa | | Aave Rewards | 0x66Ac7223048037826e12cef9a848199e31AEFabE | | CEX Earn | 0xAA12BAd4a501d45A5b771e49C2Fd415BA8BFc79d | | Aave v4 Security | 0xAAf400e4Bbc38B5E2136C1a36946Bf841A357307 | | Aave Liquidity SAFE | 0xAAA973Fe8A6202947e21D0a3a43d8E83ABE35C23 | | Frontier | 0xCDb4fA6ba08bF1FB7Aa9fDf6002E78EDc431a642 | | Merit Program | 0xdeadD8aB03075b7FBA81864202a2f59EE25B312b | Note: The Frontier SAFE (winding down) and the Merit Assets SAFE (sunsetting) are to be updated where practicable. Operations SAFEs The Operations SAFEs continue to be funded by drawing on their associated budget/asset-holding SAFEs via on-chain spending-limit allowances, with each SAFE maintaining the configuration appropriate to its function. Signing authority across the Operations SAFEs is provided by the same three organisations, ensuring a consistent and accountable signing layer across the structure. | Name | Signer | Address | |----|----|----| | APE Vote | 2 of 5 | 0xa9e777D56C0Ad861f6a03967E080e767ad8D39b6 | | ALC Vote | 2 of 5 | 0xAA484Ba6a7f51f00A3f82a11e73b741AE1dEAB58 | | ALC Incentives | 3 of 5 | 0xAAB6f926DCDaE536F54ce58478Dbc1a0d0f98871 | | Rewards Incentive | 3 of 5 | 0x89587ebe7cFF64c6527fE2Deccc3521D75763E8D | | Merit Incentive | 3 of 5 | 0xAA870e4B82deaDa3727235f34183Ec9B728714C8 | | Ahab Incentives | 3 of 5 | 0xAAd742dd9111373ec3C1E53b005e870d4CfF3be2 | | CEX Earn Incentives | 3 of 5 | 0xaa7A1910BA79B6A2E385ebA26185aA2dCB9B8eAd | Toward Standardised Fund-Movement Frameworks With standardised frameworks and policies governing how funds are moved and processed across the protocol's SAFEs. Clear, repeatable processes for proposing, verifying, and executing treasury transactions make operations more consistent, more auditable, and less reliant on any single participant. The architecture outlined in this proposal is designed to fit comfortably within these frameworks. Organisation-level signing, capped just-in-time funding, and a clearly defined hierarchy provide a foundation on which transaction runbooks, verification checklists, and reporting standards can be layered over time. TokenLogic is aligning with this approach and is glad to support the DAO in refining these frameworks. Execution Note Each SAFE update should be executed as a single batched transaction (swapOwner, addOwnerWithThreshold, removeOwner) so that the SAFE does not transit through a state with insufficient signers relative to its threshold. Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If the Snapshot outcome is YAE, this proposal will be implemented. Copyright Copyright and related rights waived via CC0.

Title: Deploy Aave v4 on Arc Author: Aave Labs Ltd. Simple Summary This Temp Check seeks community feedback on deploying Aave V4 on Arc alongside supporting an initial set of high-quality assets. Arc is an institutional-grade public layer-1 blockchain, built by Circle and designed to be the Economic Operating System (OS) of the internet for digital dollar liquidity and real-world assets. Launching Aave V4 on Arc would position Aave as foundational financial infrastructure on a network optimized for capital-efficient liquidity flows from regulated institutions. This Temp Check is intended to gauge community sentiment on: Deploying Aave V4 on Arc at or near mainnet launch Supporting the proposed initial asset scope Advancing the proposal to the ARFC stage If there is sufficient support, the proposal will proceed to ARFC with full technical specifications, risk framework, incentive design, and parameter recommendations from relevant Aave DAO service providers. Motivation Arc is preparing for mainnet launch. The permissionless blockchain is purpose built for stablecoins, tokenized real world assets, and global onchain finance. Arc, built by Circle, is focused on bringing DeFi innovation into traditional financial workflows to unlock new capital formation and expand the market for onchain credit and liquidity. As the Economic OS for the internet, Arc is designed to coordinate onchain credit and financial primitives with treasury backed instruments, tokenized assets, and compliance aligned infrastructure in a single onchain capital environment. Deploying Aave V4 on Arc would: Establish Aave as one of the primary lending protocols at network launch Grow Aave’s available markets for Circle-issued assets Expand Aave’s presence into new institutional and fintech liquidity flows Drive incremental TVL and revenue opportunities for the Aave ecosystem Arc’s design concentrates regulated stablecoin liquidity and tokenized products into a programmable settlement layer. Integrating Aave into the Economic OS positions it to serve as one of the primary lending protocols for capital forming on the network. A core objective of this deployment is to support meaningful stablecoin and tokenized asset liquidity at scale, subject to risk provider recommendations. Specification If there is sufficient support, the proposal will proceed to ARFC with full technical specifications, risk framework, incentive design/liquidity commitments, and parameter recommendations from relevant Aave DAO service providers. Full technical specifications, risk framework, incentive design, and parameter recommendations from relevant Aave DAO service providers will be presented during ARFC. Asset Scope The initial asset set proposed includes: USDC EURC cirBTC The intent is to consolidate assets into a single formal governance process where possible to reduce fragmentation and minimize proposal overhead. Final asset inclusion and parameters will be subject to Aave DAO service provider feedback. Revenue Support In connection with the deployment, Aave DAO is expected to receive a minimum of $2m per year in protocol revenue from the Aave V4 deployment on Arc, with any shortfalls covered by certain Arc ecosystem participants for the first five years following deployment. This structure provides protection for Aave DAO during the bootstrap phase. Useful Links Website: https://www.arc.network/ Litepaper: https://www.arc.network/litepaper Disclaimer Aave Labs is presenting this proposal as a service provider to the Aave DAO under the budget approved by the Aave Will Win framework. Aave Labs is not directly affiliated with Arc and did not receive compensation for this proposal. Next Steps If this Temp Check indicates sufficient community support, the proposal will proceed as follows: Phase 1: Snapshot vote on Temp Check Phase 2: ARFC (Aave Request for Final Comments) Phase 3: AIP (Onchain Vote) Following Snapshot approval, the final AIP payload will be submitted on Ethereum mainnet for onchain execution. Deployment preparation would begin after ARFC passage, with activation following successful AIP approval. Requested Feedback The community is invited to provide feedback on: Deploying Aave V4 on Arc Supporting the proposed initial asset scope Advancing this proposal to the ARFC stage If there is sufficient positive sentiment, the authors will proceed with a detailed ARFC submission. Copyright Copyright and related rights waived via CC0.

Author: Babylon Labs Date: 25-5-26 Simple Summary This Temperature Check seeks community input on the deployment of two new Aave V4 Spokes (Babylon Core Lending Spoke and BTC Vault Swap Spoke) to onboard native BTC as collateral, via the Trustless Bitcoin Vaults protocol. In TBV, a depositor locks BTC in a Taproot UTXO on Bitcoin. Redemption is governed by on-chain rules (e.g., the depositor repaid their loan) and settles directly to a Bitcoin UTXO controlled by the redeeming party. No wrapping, no bridging, no custodians. Background Babylon Babylon was started in 2022 by Professor David Tse (Stanford) and Dr. Fisher Yu, with a vision of a Bitcoin-backed crypto economy built on trustless protocols that unlock Bitcoin’s productivity without bridges, wrappers, or custodians. The project is best known for its trustless Bitcoin staking protocol, which lets BTC holders stake their BTC to secure other chains and rollups and earn staking rewards. The protocol is fully self-custodial: BTC never leaves Bitcoin and is not held by a bridge, wrapper, or signer set. Since launch in August 2024, the protocol has activated over 100,000 BTC cumulatively, reached a peak TVL of 72,000 BTC, and currently holds ~51,000 BTC (approximately $4B) staked. The success of Bitcoin staking demonstrated that BTC holders seek trustless and native ways to put their Bitcoin to work. This motivated the development of Trustless Bitcoin Vaults (TBV), which extends the same trustless and self-custodial principles to general DeFi participation, and is the subject of this proposal. Babylon developments are backed by approximately $100M+ to date from a16z, Paradigm, Polychain, Hack VC and others. Trustless Bitcoin Vaults (TBV) Trustless Bitcoin Vaults (TBV) allows anyone to use their native Bitcoin as collateral in supported on-chain applications, without transferring custody to any trusted third party. TBV achieves this by locking BTC on Bitcoin inside a Taproot script. The conditions under which it can be moved are enforced cryptographically: redemption requires a valid zero-knowledge proof of an event on host chain (e.g. Ethereum Mainnet), and any attempt to claim BTC without a valid proof can be challenged and stopped by an eligible challenger during a fraud-proof window. The depositor is always eligible to act as a challenger themselves, so they need not trust any third party to secure their BTC. The protocol introduces no third-party custodian, signer consortium, or threshold-signature group with discretionary control over the underlying BTC. Spending conditions are encoded in the Taproot script and governed by zero-knowledge proof verification through a challenge-based procedure redemption is native to Bitcoin. The locked BTC moves to a recipient designated by the vault’s spending conditions, which reference events on the host chain. TBV can be integrated with any application on any supported host chain. When BTC is locked in a Taproot script, a corresponding BTC vault record is created on the host chain (e.g. Ethereum). Each application integration builds on the BTC vault record, optionally via an adapter layer that exposes it through the application’s interface. For the Aave V4 integration, since Aave V4 only accepts ERC-20 tokens as collateral, the adapter contracts represent BTC vault records 1:1 as a transfer-restricted ERC-20 token called vaultBTC. The full component set is detailed in Specification. TBV is built on BaBe (eprint 2026/065), peer-reviewed cryptographic research (to appear in CCS 2026, the top security conference) developed jointly by Babylon Labs and UC Berkeley. BaBe makes SNARK proof verification on Bitcoin approximately 1000x cheaper than prior approaches, making trustless Bitcoin DeFi practical at scale. Why Aave V4 Aave V4’s Hub-and-Spoke architecture provides an isolated environment in which integrations can deploy both standard and custom Spokes without affecting other assets on the Hub. This is what makes V4 the right venue for the integration. Two Spokes will be deployed: a lending Spoke (Babylon Core Lending Spoke) in which allowed loan assets are borrowed against native BTC collateral, and a custom BTC Vault Swap Spoke built to swap seized BTC collateral to WBTC and support permissionless liquidations. Both are detailed in Specification. Aave DAO retains full control over all parameters and caps on both Spokes. V4’s programmability is what makes this kind of integration possible while preserving that governance oversight. Motivation The Aave V4 integration with Babylon Trustless Bitcoin Vaults protocol enables onboarding of non-custodial native BTC collateral on Aave. Depositors can borrow allowed loan assets against this collateral, with no third-party custodian, signer consortium, or threshold-signature group holding the underlying BTC. The BTC Vault Swap Spoke ensures liquidation on Aave remains permissionless despite the underlying collateral settling natively on Bitcoin. Any liquidator can settle the position by receiving WBTC for a small premium, while arbitrageurs purchase the escrowed vaults and handle the BTC-side redemption. This adds borrowing demand for WBTC on Aave, the largest BTC reserve on the platform (~$5B supplied) and presently underutilized on the borrow side. Mechanism described in Specification. Native BTC as collateral on Aave V4 also serves as a composable primitive for the broader BTC DeFi ecosystem. Other projects can build new BTC-collateralized products on top, extending Aave’s reach into BTC-native DeFi. Specification diagram1 diagram1 1448×1037 107 KB This Temp Check is scoped to integration architecture. Risk parameters, oracle configuration, supply and borrow caps, interest rate strategy, and full trust-assumption and challenger-economics details will be presented in the follow-up ARFC. Audits are being performed by Coinspect, Sherlock, Zellic, ABDK, and ZK Security across the protocol stack, with formal verification by Runtime Verification ongoing. The integration deploys new Spokes and adapter contracts only. Adapter contracts are user-facing entry points that integrate BTC vaults on Ethereum into Aave V4 Spokes. The Babylon Core Lending Spoke uses Aave V4’s standard open-source Spoke implementation; while the Bitcoin Vault Swap Spoke introduces custom Spoke code. The integration introduces two new Spokes on Aave V4 (Ethereum Mainnet) and one new collateral asset listed inside them: 1. Babylon Core Lending Spoke The lending Spoke. Use Aave V4’s standard open-source Spoke implementation, with vaultBTC as the sole collateral asset and supported borrowable assets (stablecoins, wrapped BTC …) drawn from an Aave V4 Hub. A depositor locks BTC on Bitcoin; the corresponding BTC vault record on the host chain is translated into vaultBTC and supplied as collateral on the Spoke through adapter contracts. The same adapter contracts give depositors all standard position-management actions: adding collateral by providing additional BTC vaults, withdrawing one or more BTC vaults from a position, borrowing and repaying. Permissionless partial liquidations are also supported. 2. vaultBTC vaultBTC is an internal accounting unit required to integrate with Aave V4’s ERC-20 collateral interface, not a tradable or transferable BTC wrapper. It is a transfer-restricted ERC-20 whose destinations are limited to a fixed allowlist: the Aave V4 Hub, the Babylon Core Spoke, and the integration’s adapter contract. Transfers to any other address are not allowed. Mint and burn are restricted to the adapter contract. vaultBTC is minted only when a BTC vault is added to a user’s position as collateral, and burned only when a BTC vault is withdrawn from a position. No other mint or burn path exists. Total supply always equals the BTC locked in active positions. 3. BTC Vault Swap Spoke A custom Spoke for post-liquidation BTC collateral settlement. When a position is liquidated by a permissionless liquidator, the liquidator swaps the acquired BTC vaults for WBTC through this Spoke at a small premium, with the WBTC drawn from an Aave V4 Hub and held as debt against the BTC vaults. Arbitrageurs, a permissioned set with redemption rights, later buy individual escrowed BTC vaults by repaying the WBTC debt (principal plus accrued interest) and redeem the BTC on Bitcoin. The Spoke exists because BTC redemption is restricted to pre-committed actors in each BTC vault’s Taproot script and takes multiple days through the fraud-proof challenge window. Decoupling liquidation timing from BTC redemption lets permissionless liquidators settle in WBTC immediately while arbitrageurs handle redemption on Bitcoin’s timeline. The only direct fund-flow touchpoint between the Hub and the BTC Vault Swap Spoke is the WBTC drawn at liquidation, which is repaid when arbitrageurs purchase the escrowed BTC vault. Disclaimer Babylon Labs is the author of this proposal. We have not been compensated by any third party to publish it. This TEMP CHECK has been prepared solely to facilitate community discussion. Next Steps Temperature Check: Gather community feedback and assess sentiment towards the deployment of two new Aave V4 Spokes (Babylon Core Lending Spoke and BTC Vault Swap Spoke) and the listing of vaultBTC as collateral to onboard native BTC as collateral via the Babylon Trustless Bitcoin Vaults (TBV) protocol. The vaultBTC listing would be added either to an existing V4 Hub or to a new Hub deployed for this integration. ARFC: If the Temperature Check Snapshot indicates positive sentiment, proceed to the ARFC stage for further discussion, risk parameter evaluation, audit review, and finalization of the proposal. AIP: If the ARFC stage Snapshot is successful, submit the proposal as an AIP for voting and on-chain governance approval. Copyright Copyright and related rights waived via CC0.

Summary This proposal seeks community feedback on deploying Aave V4 on Avalanche, including a dedicated RWA hub. Avalanche has committed up to $15M in incentives, tied to growth KPIs, to support Aave V4 growth. Deploying V4 on Avalanche would position Aave as one of the first major lending protocols to bring V4’s Hub and Spoke architecture to a large existing DeFi ecosystem with dedicated launch support. Motivation Aave V4 is entering its next growth phase. The initial deployment on Ethereum proved the Hub and Spoke model in production. Expanding into networks with existing DeFi demand, active Aave usage, and a credible path to protocol revenue is the natural next step to growing Aave V4. Avalanche is a strong candidate for that expansion. Aave already has a live market on the network; V4 would not be entering a new network. Avalanche users are already familiar with supplying, borrowing, incentives, and Aave’s role as a core liquidity venue. The deployment will also include a dedicated RWA hub, extending Aave’s institutional product surface into one of the most active RWA ecosystems in DeFi. The $15M incentive commitment - tied to V4 growth milestones - gives the deployment a direct growth catalyst from launch. Dedicated ecosystem support will attract liquidity, drive borrow activity, support integrations, and accelerate V4 adoption. V4 would launch into an ecosystem with existing Aave distribution, active DeFi liquidity, and incentives specifically aligned around growing the new architecture. That combination gives Avalanche a credible path to become one of the first major V4 growth markets outside Ethereum. A successful deployment would expand V4 TVL, increase protocol revenue, attract new integrations, and establish a repeatable expansion model for future V4 deployments built around existing demand and ecosystem support. Specification If governance supports this Temp Check, the next phase would prepare an ARFC for deploying Aave V4 on Avalanche. The ARFC would include the proposed initial Hub and Spoke configuration, supported tokens, oracle configuration, risk parameters, caps, incentives structure, deployment contracts, and any required operational permissions. Next Steps Gather community feedback on the proposed Aave V4 deployment on Avalanche. If feedback is supportive, advance this proposal to ARFC. Disclaimer Aave Labs is not receiving compensation from Ava Labs for this proposal or the potential deployment of Aave V4 on Avalanche. Aave Labs is presenting this proposal as a service provider to the Aave DAO under the budget approved by the Aave Will Win framework. Aave Labs is contributing this proposal as part of its approved scope of work in support of DAO operations. Copyright Copyright and related rights waived via CC0.

Summary This proposal restores stkAAVE emissions to reflect the targeted 2.75% staking APR, as mentioned in the https://governance.aave.com/t/aave-dao-funding-insights/24192. Motivation Overview In line with the Aave DAO Funding Insights publication, this proposal recommends restoring AAVE emissions to target a 2.75% APR. Given that recent outflows are not expected to return, and with more than 30,000 stkAAVE balances currently in Cooldown, AAVE emissions should be revised downward to align with the 2.75% target rate. This publication follows the prudent decision to pause the AAVE buyback program, facilitating the Aave DAO's redirection of capital to strengthen the balance sheet after donating 25,000 ETH to restore the backing of rsETH following the LayerZero exploit, and preparing to introduce an incentive campaign on the Ink Network in the near future. Rationale for stkAAVE Emission Reduction To date in Q2, four (4) large stkAAVE holders have withdrawn AAVE from the staking contract, resulting in the APR adjusting from 2.68% to 3.87%. !Image 1.jpg Source: https://aave.tokenlogic.xyz/umbrella/stkaave !Image 2.png Source: https://aave.tokenlogic.xyz/umbrella/stkaave With an expected 32,593 AAVE to be withdrawn across four (4) addresses and slightly more than 35k AAVE currently in Cooldown, the yield is expected to increase towards 3.93% APR in the near future. !Image 3.png Source: https://aave.tokenlogic.xyz/umbrella/stkaave With reference to the Aave DAO Funding Insights publication, this proposal seeks to reduce AAVE emissions to align with the targeted 2.75% APR. After adjusting for recent and forecast near-term stkAAVE withdrawals, an emission rate of 150 AAVE/day is anticipated to achieve the targeted 2.75% APR. Reducing the AAVE emissions by 70 AAVE/day continues the recent trend of revising stkAAVE emissions lower, as shown in the table below. !Image 4.png Source: https://aave.tokenlogic.xyz/umbrella/stkaave The impact upon AAVE emissions is shown below: | Metric | Current | Proposed | Delta | | --- | --- | --- | --- | | Emission Rate (AAVE/day) | 220 | 150 | (70) | | Annualised Emissions (AAVE) | 80,300 | 54,750 | (25,550) | | Annualised Spend (At $90/AAVE) | ~$7.2M | ~$4.9M | ($2,299,500) | | stkAAVE APR | 3.30% | ~2.75% | (80) bps | Specification The stkAAVE emission rate is to be updated as follows, with no other Safety Module parameters modified by this proposal. | Parameter | Current | Proposed | | --- | --- | --- | | stkAAVE Emission Rate | 220 AAVE/day | 150 AAVE/day | | stkAAVE Target APR | 3.30% | ~2.75% | The change aligns the cost of stkAAVE emissions with expected participation levels and reduces annualised stkAAVE emission spend by approximately $2,300,000 at $90/AAVE. Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If the snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

Summary This ARFC proposes the creation of a new 3-of-4 rewards operations multisig at rewards.aave.eth to receive, hold, and administer incentive funding provided by third parties for Aave growth campaigns. No Aave treasury funds are requested or authorized by this proposal. The multisig would function as a pass-through operations wallet for partner-funded incentive programs. Third parties may fund the wallet for approved campaigns, and the multisig would manage the operational configuration and distribution of those rewards. The multisig would be operated by representatives from Aave Labs, TokenLogic, and LlamaRisk. Signer identities will not be publicly disclosed for personal safety and protocol opsec. This proposal does not replace any existing multisig. It does not modify any active incentive program. It does not grant authority to request, receive, or deploy Aave treasury funds. It does not grant authority to change protocol risk parameters, list tokens, modify protocol contracts, or deploy funds outside the approved incentives mandate. Motivation Aave growth campaigns increasingly require timely coordination with external partners across new market launches, integrations, liquidity campaigns, and ecosystem programs. Many of these campaigns are funded by third parties rather than the Aave DAO. A dedicated rewards operations multisig gives contributors a known endpoint for incentive funding while giving the DAO a clearer view into how externally funded campaigns are administered. The purpose of this proposal is to establish that operational structure before upcoming campaign windows begin. The multisig would not control DAO capital. It would only receive incentive funding from third parties and manage those rewards according to the mandate approved by governance. Expedited Timeline Aave Labs proposes to move this ARFC to an immediate Snapshot vote. The standard ARFC process generally includes a longer discussion window before Snapshot. Aave Labs is requesting an expedited timeline because certain incentive operations require a dedicated rewards administration structure before upcoming campaign start dates. This expedited process is limited to the mandate described in this ARFC. The Snapshot vote will still give the DAO the ability to approve or reject the proposed structure before it is used as the recognized rewards operations wallet for the approved mandate. Specification A new rewards operations multisig will be created with the following configuration. Signer identities will not be disclosed. Address: 0x66Ac7223048037826e12cef9a848199e31AEFabE ENS: rewards.aave.eth Threshold: 3-of-4 Signer Address Signer 1 0x4b752551fC6345A7de82F76fd7a5015CA16d1a74 Signer 2 0xb291232F480F41c75802C4a60F1D2AC03404Afef Signer 3 0xb647055A9915bF9c8021a684E175A353525b9890 Signer 4 0x45d11217458aEE68A4D976A8f17e2E24Fc5898A1 Interim Incentive Campaigns There may be campaigns that begin before the Snapshot vote for this ARFC is completed. The relevant Aave service providers have aligned on the campaigns, and there is no practical reason to delay launch while the DAO considers the proposed rewards operations structure. If this ARFC does not pass, the campaigns may be cancelled or wound down. Until then, they will proceed as limited interim campaigns supporting the same scope described in this proposal. Initial Mandate The rewards operations multisig may receive incentive funding from third-party contributors for Aave growth campaigns. The multisig may hold and administer those third-party-funded rewards for campaigns connected to Aave markets, integrations, partner programs, or other growth initiatives approved under this mandate. The multisig may configure and manage rewards distributions where operational action is required to activate, adjust, or complete a campaign. The multisig may coordinate with service providers, contributors, and ecosystem partners to execute incentive campaigns within the approved scope. The multisig must provide public reporting on funded campaigns, including the source of incentive funding, the market or program supported, the amount received, the amount distributed, and any remaining balances. The multisig may not use funds for purposes unrelated to incentive administration. Reporting Aave Labs, TokenLogic, and LlamaRisk will provide periodic updates to the DAO covering active campaigns, completed campaigns, budget deployed, remaining budget, and observed performance where available. Reports will be posted to the governance forum and will include enough information for the DAO to understand how the mandate is being used. Next Steps If the DAO supports this ARFC, it will proceed to Snapshot. If Snapshot passes, rewards.aave.eth will be created and may be used to administer incentive campaigns within the approved mandate. Disclaimer Aave Labs is presenting this proposal as a service provider to the Aave DAO under the budget approved by the Aave Will Win framework. Copyright Copyright and related rights waived under CC0.

!image.jpg Summary In response to the launch of Aave V4 and recognizing Aave Labs’ role as the primary technical innovator, this proposal presents TokenLogic as the team responsible for managing finances and supporting operations at Aave. Upon implementation, TokenLogic will be responsible for: Finances: Responsible for managing Aave's finances, budget, reporting, KPI monitoring, user acquisition cost monitoring, popular use case analysis and investor relations insights in alignment with key stakeholders, such as Aave Labs. Market Structure: Provide market structure recommendations, perform capital-efficiency and interest-rate analyses, including Borrow Rate parameter recommendations, and design all incentive campaigns across Aave V3 and V4, in collaboration with other Service Providers. GHO Stablecoin: In conjunction with Aave Lab’s oversight, upgrade the GSMs to facilitate allocating to off-chain yield sources such as RWAs, develop cross-chain sGHO, and continue to lead the growth efforts supporting Aave's GHO stablecoin. Tooling: Provide and maintain tooling, such as Aave Seatbelt, Aave Robot, bridging, and swaps, among others, for Aave V3 and V4. Liquidation Engine: Support Chainlink's SVR rollout and upgrades; contribute quantitative analysis; present recommendations; collaborate with other service providers; and support the configuration of Aave V4 liquidation parameters to balance risk and expand revenue. Aave V4: Research and develop at least one Spoke that unlocks a new type of collateral, or that allows liquidity to move between networks using CRE. Responsible for leading efforts to develop the reinvestment feature strategy implementation and provide general operational support with asset onboardings and parameter updates via AIP. Business Development and Growth: Focusing on driving institutional adoption, strategic partnerships, and ecosystem growth across Aave Protocol. Upon implementation, this proposal will cancel the existing 100072 stream and replace it with a new $2M Allowance, a new $2.5M EthLidoGHO stream and a new 5k AAVE stream over 12 months. The existing KPI's remain unchanged. Motivation The launch of Aave V4 marks a defining moment for the protocol and the operational demands on the ecosystem grow in parallel. The recent restructuring of Aave's service provider landscape has concentrated responsibility across fewer teams, requiring those that remain to broaden their scope and deepen their commitments. TokenLogic has consistently delivered across treasury management, GHO development, incentive design, and analytics. At Aave's request, over the past year, we have expanded beyond our original mandate driving business development initiatives and building tooling infrastructure that underpins Aave's daily operations. With fewer service providers and a significantly broader mandate, we are now responsible for delivering across finance, GHO, incentive design, tooling maintenance, V4 feature development, and business development. This proposal ensures TokenLogic is resourced to meet those demands and continue delivering at the pace that Aave's growth requires. Scope of Work This section outlines the full scope of services to be provided by TokenLogic. Upon implementation, subject to a vote by AAVE token holders, this proposal replaces the existing Phase II proposal and recognizes TokenLogic's new focus within the Aave ecosystem. Whilst delivering the scope below, TokenLogic will work closely with Aave Labs, Certora, LlamaRisk to ensure product delivery schedules are executed seamlessly. Note : Detailed scope available on the discussion link. Finance TokenLogic manages Aave's financial operations, ensuring that protocol revenue is optimally allocated across growth initiatives, operational expenses, and strategic reserves. As Aave's financial complexity grows with multichain deployments, new product lines, and an expanding set of strategic partnerships, a dedicated and proactive treasury function is essential to sustaining growth and maintaining long-term stability. Treasury Management TokenLogic focuses on ensuring the Aave DAO's expenses and initiatives are funded efficiently. We support financial planning, budgeting, forecasting, risk management, and capital optimization to safeguard long-term stability. Our responsibilities span cash flow management, treasury operations, expense payments, and financial analysis, providing data-driven insights that guide strategic decision-making and business growth. Strategic Importance As Aave continues to grow, we are witnessing an increase in the volume of strategic opportunities, rising cash flow demands, and suppressed market conditions, all of which require continuous, thorough analysis and oversight to avoid overcommitting funds whilst maintaining an aggressive pursuit of growth. Asset Management Tooling Continue to expand Aave's financial stewardship tooling and introduce new asset management tooling to optimize and scale fund management. Analytics Continue to build and maintain the Aave Analytics platform to provide users with the most up-to-date and detailed analysis of the Aave Protocol and Aave's finances. TokenLogic will continue to expand the data analysis offering, providing new insights and creating an investor relations section. Incentive Campaign TokenLogic designs and iteratively optimizes incentive campaigns across all Aave deployments. Our approach combines rigorous quantitative analysis with close coordination across ecosystem partners and service providers to maximize the impact of incentive. GHO Stablecoin TokenLogic will continue to support the ongoing technical development in close collaboration with Aave Labs and drive the adoption of Aave's GHO Stablecoin. The scope is broadly defined as five key areas : Growth, Liquidity, GHO stewards, Technical Develoment and RWA Exposure. Aave V3 and V4 Aave V4 Liquidation Analysis & Configuration Aave V4 has a configurable liquidation engine that lets Aave determine how user positions can be liquidated. These parameters shape the trade-off between borrower protection and execution reliability and directly influence how the liquidation surplus is distributed among borrowers, liquidators, and the protocol. This work is also tied to Umbrella. Aave V3 and V4 Interest Rate Analysis Interest rate parameters such as Base Rate, Slope1, UOptimal, and Slope2 determine how borrowing costs are priced across Aave markets, while Reserve Factor in Aave V3 and the equivalent Liquidity Fee in Aave V4 determine how borrower interest is split between suppliers and the DAO. Together, these are some of the protocol's most important levers for balancing borrower demand, supplier competitiveness, utilization, and revenue generation. Aave V3 and V4 SVR Monitoring & Configuration SVR (Smart Value Recapture) is a Chainlink subsystem, currently integrated with Aave V3 and soon to be introduced in Aave V4, that redirects non-toxic liquidation MEV back to the protocol, creating an additional source of DAO revenue. Aave V3 and V4 Tooling Amidst the restructuring of responsibilities within Aave, TokenLogic will support by assuming responsibility for continuing to improve the DAO's tooling from BGDLabs, including Helpers such as Aave Robot, Aave Seatbelt, address book, and permissions book. Aave V4 - Technical Development The following highlights TokenLogic's technical contribution to the Aave V4 protocol, which will be carried out in collaboration with Aave Labs, the primary technical team overseeing Aave V4 development. Our focus is on unlocking new revenue sources for Aave by expanding access to new collateral types and enhancing the protocol's overall capital efficiency. Business Development TokenLogic has been at the forefront of Aave's business development efforts, driving strategic partnerships and network launches that have materially expanded the protocol's reach and revenue. While not formally recognized under the previous scope, our contributions have delivered significant results. Under this extended scope, in collaboration with Aave Labs, TokenLogic's contribution to broader Business Development and Institutional Sales efforts is formally recognised. Specification Upon implementation: TokenLogic's contribution to the Aave ecosystem includes the scope of work defined in the Scope section above. Cancel Stream 100072, 2.5M aEthLidoGHO over 12 months. The existing KPI program remains unchanged. Create a 2M aEthLidoGHO Allowance. Create a 12-month 2.5M aEthLidoGHO stream. Create a 12-month 5k AAVE stream. Following on from past funding updates, and for avoidance of doubt, the Audit, Gas and Legal costs are to be reimbursed through periodic funding updates. Next Steps If the ARFC snapshot outcome is YAE, escalate to the AIP stage. Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. TokenLogic supports and maintains an independent delegate voting platform within the Aave community.

Summary It has been one year since LlamaRisk’s last renewal. LlamaRisk submits this proposal to renew its role as Aave’s Risk Service Provider. Aave’s risk layer recently lost critical infrastructure operated by a departing risk provider, including automated risk-oracle infrastructure, parameter automation pipelines, and Risk Steward coverage. LlamaRisk stepped in with Aave Labs to assume control of the Risk Steward and maintain operational continuity across Aave markets. The immediate issue is continuity. The structural issue is ensuring Aave does not depend on risk infrastructure the DAO cannot inspect, verify, or replace without disruption. This proposal renews LlamaRisk’s mandate and expands its scope across Aave V3, Aave V4, and Horizon, with a focus on protocol-owned risk infrastructure built on Chainlink CRE. The goal is to move Aave’s risk layer toward infrastructure owned and controlled by the DAO, with off-chain logic independently verifiable through cryptographic workflow IDs. LlamaRisk will deliver: Protocol-owned risk infrastructure on Chainlink CRE. Risk-managed price feeds for Pendle PTs, CAPO assets, USDe, RWA NAV, and related integrations. Dynamic parameter automation for supply caps, borrow caps, interest rates, Umbrella calibration, credit lines, risk premiums, and liquidation configuration. Safety mechanisms including freeze guardians and V4 per-Spoke circuit breakers. Risk Steward co-ownership and operational accountability. AIP and governance payload review. Guardian signer duties. Monitoring, dashboards, escalation playbooks, and incident response support. Continued Horizon cooperation and LlamaGuard NAV expansion. R&D for V4-native risk systems, including RWA liquidation infrastructure and instant settlement infrastructure. Legal and regulatory research covering stablecoins, custody, counterparty risk, DeFi lending compliance, and tokenized RWA structuring. LlamaRisk is currently a team of 16 contributors and expects to scale to 20+ contributors during this engagement. LlamaRisk also proposes to phase out remaining non-Aave work over six months and become Aave-exclusive by the midpoint of the engagement. The proposed compensation is structured as: 1.5 million GHO paid upfront. 1.5 million GHO streamed linearly over one year. 5,000 AAVE streamed linearly over one year. The current GHO stream with ID 100071 will be terminated. Motivation 1. LlamaRisk’s role has evolved LlamaRisk began serving Aave as a lean risk supplement. That is no longer the role it performs. Across Aave V3, LlamaRisk now provides risk frameworks, parameterization methodologies, quantitative models, market monitoring, Guardian signer duties, and governance review support across active deployments. Across Aave V4, LlamaRisk has produced research and frameworks for Hubs and Spokes, the Reinvestment Controller, Umbrella coverage logic, credit line limits, liquidation configuration, and cross-pool contagion modeling. This work has been conducted in coordination with Aave Labs and other service providers and directly informs V4’s launch strategy and risk architecture. Across Horizon, LlamaRisk supports due diligence, parameterization, and risk monitoring. LlamaRisk also developed LlamaGuard, a bounded dynamic NAV model for RWA integration that is being extended through Chainlink CRE as protocol-owned infrastructure. LlamaGuard makes off-chain computation values publicly verifiable through the on-chain Parameter Registry. LlamaRisk does not retain privileged access controls, and parameter updates are cryptographically verifiable through CRE workflow IDs. LlamaRisk also provides independent legal and regulatory research for Aave, covering stablecoin regulation, custody and counterparty risk, DeFi lending compliance, tokenized RWA legal risk, and institutional structuring. The scope has outgrown the prior mandate and now requires a broader renewal. 2. What changed The departure of Aave’s primary risk provider created a concentration of operational risk that must be resolved structurally. This is not only a staffing issue. It is an ownership and verification issue. On March 10, the wstETH CAPO oracle failed, resulting in approximately $1.03 million in borrower damages, 47 wrongful liquidations, and more than four hours of depressed pricing. Separately, LlamaRisk’s analysis of the WETH utilization spike and Slope2 Risk Oracle performance identified a significant divergence in risk-oracle behavior during a utilization spike. Both incidents point to the same issue: critical risk logic was operated through proprietary systems with limited independent verification. Aave should not rely on closed infrastructure for protocol-critical risk decisions. This proposal addresses that gap by moving Aave’s risk layer toward infrastructure owned, controlled, and verifiable by the DAO. 3. Proposed scope The core of this renewal is protocol-owned risk infrastructure. LlamaRisk will work with Chainlink on CRE workflow design, Certora on audit coverage, and TokenLogic where risk parameters intersect with growth, incentives, and treasury operations. LlamaRisk also commits to private escalation with Aave Labs and service providers before public communication on sensitive matters. LlamaGuard and risk oracles LlamaRisk will progressively deploy a suite of risk oracles for Aave. Aave DAO retains control through co-ownership of the CRE admin panel, cryptographic verification through workflow IDs, and no update or shutdown without Aave DAO explicit consent. Priority integrations include: | # | Integration | Scope | |---|---|---| | 1 | Pendle PT Price Oracles on CRE | On-chain methodology for PT exposure. | | 2 | Aave V3 and V4 Interest Rate Analysis | IRM coverage across Slope1, Slope2, base rate, and optimal utilization. | | 3 | Dynamic Supply and Borrow Caps | Automated cap management across active deployments. | | 4 | SVR Monitoring and Configuration | Parameter inputs from SVR auction data and MEV recapture analysis. | | 5 | Aave Umbrella | Coverage calibration and risk monitoring. | | 6 | CAPO Risk Oracle | CRE-based validation for LST, LRT, and stablecoin pricing. | | 7 | USDe Oracle and Freeze Guardian | Circuit-breaker design for Ethena and related yield-bearing stablecoin exposure. | | 8 | Dynamic RWA NAV Feeds | LlamaGuard NAV expansion for Horizon and future RWA use cases. | V4-native risk work V4 introduces new parameter surfaces that require dedicated modeling from inception. LlamaRisk will cover: | # | Integration | Scope | |---|---|---| | 1 | Credit Lines and Draw Caps | Hub and Spoke exposure limits. | | 2 | V4 Liquidation Configuration | Target HF calibration and liquidation bonus modeling. | | 3 | Freeze Agents | Per-Spoke circuit breakers. | | 4 | Dynamic Risk Premiums | User-level pricing based on collateral risk. | | 5 | Reinvestment Controller Limits | Allocation limits that protect supplier withdrawal guarantees. | V3, V4, and Horizon coverage Aave V3 remains critical infrastructure during the V4 migration period. LlamaRisk will continue V3 market monitoring, parameter recommendations, cap management, oracle design, Umbrella calibration, SVR monitoring, AIP payload review, and governance participation. For Aave V4, LlamaRisk will support parameterization of Hubs, Spokes, credit lines, isolation pools, liquidation configuration, risk premiums, and related controls. For Horizon, LlamaRisk will continue supporting due diligence, NAV methodology, parameterization, RWA monitoring, LlamaGuard development, and the Horizon Vision 2026 roadmap. R&D and tooling LlamaRisk will continue investing in simulation, monitoring, and incident response tooling for Aave’s risk operations. This includes stress testing for V4 cross-Spoke contagion and credit line utilization, RWA simulations for settlement friction and NAV deviation, expanded SVR monitoring, off-hour protection modules for tokenized equities, corporate event handling automation, and updated incident response SOPs. R&D tracks include a liquidator Spoke for RWAs and self-custodied integrations with limited secondary-market liquidity, and an instant settlement bridge aligned with the goal of internalizing looping infrastructure. 4. Fee and team scaling The proposed renewal uses the following payment structure: | Component | Amount | Payment Method | |---|---:|---| | Upfront payment | 1.5 million GHO | Immediate payment | | Streamed payment | 1.5 million GHO | Linear stream over one year | | Streamed payment | 5,000 AAVE | Linear stream over one year | The upfront payment funds immediate absorption of departing scope, contributor scaling, and infrastructure buildout required for continuity. The streamed component aligns compensation with delivery over the engagement. LlamaRisk is currently a team of 16 contributors and plans to scale to 20+ contributors during the engagement. Planned hires include: | Role | Primary Assignment | |---|---| | Backend Engineer | CRE risk oracle deployment pipeline and monitoring infrastructure. | | Quantitative Researcher | V4 parameter modeling, credit line calibration, and risk premium methodology. | | Smart Contract Developer | Risk Steward integration, governance payload review, and Spoke development. | | Team Lead, Risk Oracles | CRE risk oracle engineering and deployment coordination. | Specification Proceed with the immediate payment of 1.5m GHO, and create a payment stream of 1.5m GHO and 5,000 AAVE to address 0x9eE16dBDE572886342fc1e2Db8525DEFB007b27c a LlamaRisk-controlled multisig for 1 year. Terminate current GHO stream (ID = 100071). Next Steps If the ARFC snapshot outcome is YAE, escalate to the AIP stage.

[ARFC] Update Aave DAO Bug Bounty Program Structure Summary Aave Labs proposes restructuring the Aave DAO bug bounty framework into multiple subsystem-specific programs, each with its own scope, severity criteria, payout framework, and operating platform. Motivation Aave no longer operates as one homogeneous smart contract system. Core Aave V3, Core Aave V2, GHO, governance and other non-liquidity infrastructure, Aave V4, Aave V3 on Aptos, and Aave App Stack each have materially different architecture, threat models, and user impact. A single unified bug bounty program forces one shared set of eligibility rules, severity assumptions, and payout tiers across systems that do not share the same risk profile. That creates avoidable ambiguity for both researchers and reviewers. Specification This ARFC proposes the following protocol-wide bug bounty structure. Program Structure | Program | Platform | |---|---| | Core Aave V3 | Immunefi | | Core Aave V2 | Immunefi | | GHO | Immunefi | | Non-liquidity protocol infrastructure | Immunefi | | Aave V4 | Sherlock | | Aave V3 on Aptos | Cantina | | Aave App Stack | Sherlock | Each program will have its own published scope, severity framework, payout table, and platform-specific operating setup where applicable. Submissions would be reviewed by the main technical team responsible for the relevant scope together with the respective audit firm or platform review team. For each program, those teams would align on scope interpretation, severity classification, reward amounts, and other relevant factors before finalizing conclusions on eligible reports. Payout Framework The following tables summarize the current and proposed payout structure for each program. Sherlock and Cantina already operate under aligned severity levels. Under this proposal, the intention is to update the Immunefi programs so that their severity levels are aligned with the Sherlock and Cantina framework as well, while preserving any program-specific scope restrictions, such as those applicable to Core Aave V2. Core Aave V3 | Severity | Current Min | Current Max | Proposed Min | Proposed Max | |---|---:|---:|---:|---:| | Critical | $50,000 | $1,000,000 | $100,000 | $5,000,000 | | High | $10,000 | $75,000 | $25,000 | $75,000 | | Medium | $10,000 | $10,000 | $10,000 | $10,000 | | Low | $1,000 | $1,000 | $5,000 | $5,000 | Core Aave V2 For assets labeled as Aave V2 and deployed on Ethereum, only Critical and High impacts are in scope. For assets labeled as Aave V2 and deployed on Ethereum’s L2s, only Critical impacts are in scope. | Severity | Current Min | Current Max | Proposed Min | Proposed Max | |---|---:|---:|---:|---:| | Critical | $50,000 | $1,000,000 | $100,000 | $1,000,000 | | High | $10,000 | $75,000 | $10,000 | $50,000 | | Medium | — | — | — | — | | Low | — | — | — | — | GHO Scope would be reviewed and expanded where needed as part of implementation. | Severity | Current Min | Current Max | Proposed Min | Proposed Max | |---|---:|---:|---:|---:| | Critical | $50,000 | $1,000,000 | $50,000 | $1,000,000 | | High | $10,000 | $75,000 | $25,000 | $75,000 | | Medium | $10,000 | $10,000 | $10,000 | $10,000 | | Low | $1,000 | $1,000 | $5,000 | $5,000 | Non-liquidity Protocol Infrastructure This bucket would include: Governance V3 Aave Safety Module StkAAVE V3 and stkABPT Umbrella V3, and Umbrella V4 when ready Aave Delivery Infrastructure, or aDI | Severity | Current Min | Current Max | Proposed Min | Proposed Max | |---|---:|---:|---:|---:| | Critical | $50,000 | $1,000,000 | $50,000 | $1,000,000 | | High | $10,000 | $75,000 | $25,000 | $25,000 | | Medium | $10,000 | $10,000 | $10,000 | $10,000 | | Low | $1,000 | $1,000 | $5,000 | $5,000 | Aave V4 | Severity | Current Min | Current Max | Proposed Min | Proposed Max | |---|---:|---:|---:|---:| | Critical | $25,000 | $500,000 | $100,000 | $2,500,000 | | High | $5,000 | $25,000 | $10,000 | $25,000 | | Medium | $5,000 | $5,000 | $5,000 | $10,000 | | Low | $1,000 | $1,000 | $1,000 | $5,000 | Aave V3 on Aptos | Severity | Current Min | Current Max | Proposed Min | Proposed Max | |---|---:|---:|---:|---:| | Critical | $25,000 | $500,000 | $100,000 | $1,000,000 | | High | $5,000 | $25,000 | $10,000 | $50,000 | | Medium | $5,000 | $5,000 | $5,000 | $10,000 | | Low | $1,000 | $1,000 | $1,000 | $5,000 | Aave App Stack | Severity | Current Min | Current Max | Proposed Min | Proposed Max | |---|---:|---:|---:|---:| | Critical | — | — | $50,000 | $100,000 | | High | — | — | $10,000 | $25,000 | | Medium | — | — | $5,000 | $10,000 | | Low | — | — | $1,000 | $5,000 | In cases where a single vulnerability clearly affects multiple subsystems, the payout framework should escalate to the most critical affected subsystem. For example, if a vulnerability in a GHO component could be used to create a loss-of-funds scenario for Core Aave V3, the Core Aave V3 payout framework should apply. Payment Process While the programs are split operationally, payout execution can remain unified at DAO level. Valid payouts across programs can continue to be batched through periodic treasury proposals or another DAO-approved payout flow, reducing governance overhead while preserving subsystem-specific evaluation. Funding Responsibility Core Aave V3, Core Aave V2, GHO, non-liquidity protocol infrastructure, and Aave V4 programs are funded by the Aave DAO. Similarly, Aave App Stack would fall under the Aave DAO funding responsibilities. The Aave V3 on Aptos program is presently funded directly by Aave Labs. Under the Aave Will Win effort, funding responsibility for the Aave V3 on Aptos bug bounty would be transferred from Aave Labs to the Aave DAO. After transfer, all programs described in this proposal would be funded by the DAO under the unified payout flow described above. Transition mechanics, including any required treasury action or reimbursement for the transition period, would be handled through the applicable governance path. Principles The proposed structure follows these principles: separate programs by subsystem keep scope and severity guidance specific to each subsystem maintain explicit reviewer ownership for each program preserve the ability to compare platform performance before deciding on consolidation transfer Aptos bug bounty funding responsibility from Aave Labs to the DAO Scope Core Aave V3 This program should cover the production Core Aave V3 liquidity protocol and its explicitly listed production contracts and integrations. The rewards module would be excluded, including the RewardsController, RewardsDistributor, EmissionManager, and any associated library or contract, given their limited and infrequent use. Core Aave V2 This program should continue to cover the explicitly listed Core Aave V2 deployments subject to the impact restrictions described in the payout framework. GHO This program should cover GHO-specific contracts and infrastructure, including the token system, savings-related contracts, facilitators, bridging components, and other GHO-specific production infrastructure explicitly listed. In cases where components rely on external integrations or third-party systems, the program may cover only the integration layer or any additional code built on top, while the underlying systems remain out of scope and are covered by their respective programs. Non-liquidity Protocol Infrastructure This program should cover governance, Safety Module components, Umbrella, aDI, and other explicitly listed non-liquidity protocol infrastructure. Aave V4 This program should cover the final list of Aave V4 in-scope repositories, deployed contracts, environments, and official or canonical spokes included in the launch configuration and subsequent production scope updates. Any non-canonical or third-party spokes would only be in scope if they are separately and explicitly added. Aave V3 on Aptos This program should continue to cover the current Aptos deployment under the existing Cantina structure. Operational scope and severity framework remain unchanged. The rewards module would be excluded, including the RewardsController and RewardsDistributor, given their limited and infrequent use. Funding responsibility would transition from Aave Labs to the Aave DAO as part of the Aave Will Win effort. Aave App Stack This program should cover Aave V3 App, Aave Pro, Aave Kit, and a number of critical domains and web applications that users and integrators interact with. The main focus of this program would be vulnerabilities that could directly lead to loss of funds. Review Period This structure should remain in place for an initial observation period of 6 to 12 months. At the end of that period, the DAO can review: whether the split structure improved clarity and operational handling whether platform diversity improved researcher coverage and report quality whether consolidation across one or more platforms would improve efficiency A subsequent review can be initiated once enough operating data has been collected. Next Steps Seek community feedback on the proposed split, payout framework, platform allocation, and Aptos funding transfer to the DAO. If consensus is reached on this ARFC, move the proposal to Snapshot. If Snapshot passes, implement the revised multi-program structure and the related funding and operational updates through the appropriate governance paths.

Summary This publication presents to the Aave community, for discussion and vote, a proposal to have the Aave DAO provide financial assistance to restore the backing of Kelp DAO’s rsETH product following the April 18, 2026, bridge incident. The Aave DAO’s participation forms part of a broader DeFi United recovery effort with ecosystem partners aimed at the orderly resolution of the rsETH backing shortfall. Early contributors to DeFi United include EtherFi, Lido, Mantle, Stani, Ethena, Ink Foundation / Tydro, Golem Foundation and Golem Project, Emilio, BGD Labs, Ernesto with more to come soon. Further communication regarding the financial implications of this contribution to restoring rsETH users will be shared once the coordinated recovery plan has progressed further. Motivation Overview On April 18, 2026, a vulnerability enabled an unauthorised release of rsETH from the Ethereum LayerZero adapter, breaking the cross-chain backing invariant between locked Ethereum collateral and remote-chain mints. A detailed account of the incident, the attacker's on-chain footprint, and the resulting bad-debt scenarios is available in the rsETH Incident Report and in LlamaRisk's follow-up analysis,. Aave DAO service providers and other ecosystem participants are coordinating a recovery effort (called “DeFi United”) intended to close the remaining ETH backing shortfall and protect affected users across the Aave V3 deployments where rsETH and wrsETH were listed. This proposal is limited to the Aave DAO's component of that effort. No Ghost Left Behind Aave has a long-standing commitment to protecting users during systemic events. Following the 2022 CRV short-squeeze incident, which resulted in 2,651,906 CRV of bad debt, which at the time represented roughly $1.9M, the DAO moved to cover the shortfall rather than socialise losses with suppliers. This proposal continues that posture. The Aave DAO balance sheet is well-positioned to participate in a coordinated response. Participation supports the integrity of the Aave V3 markets affected by the incident (Ethereum, Arbitrum, Mantle), preserves depositor confidence in the WETH and LST markets, and demonstrates the DAO's willingness to absorb a systemic event of this nature. Recovery Effort This ARFC lays out a credible path to making affected users whole, but it is important that the DAO approaches it with open eyes. The recovery depends on actions by parties outside the coalition's control, including Kelp reopening withdrawals, LayerZero reopening the bridge, the Arbitrum Security Council, the Aave and Compound liquidation markets, that could play out over the coming weeks. The DeFi United coalition has assembled the best plan available with the information at hand, and the numbers in this document reflect the central case. They are not guaranteed. This is a call to arms: if each of the external pieces lands as expected, the outcome is a full make-whole of users with limited long-term exposure for the DAO, but the path there is not risk-free. According to the Llamarisk report, the exploit resulted in the extraction of 152,577 rsETH from the LayerZero lockbox. At the prevailing ratio of 1.0696 rsETH per ETH, this represents an original shortfall of approximately 163,183 ETH. Coordinated action by multiple parties across the ecosystem has since reduced the outstanding gap materially: Kelp recovered and froze 40,373 rsETH, equivalent to approximately 43,168 ETH at the reference ratio. Following this action, the immediate hole stands at approximately 120,015 ETH. The Arbitrum Security Council successfully froze 30,766 ETH that the hacker was still holding on Arbitrum. The hacker's remaining position on Aave can be liquidated. The delta between collateral and debt represents an expected recovery of up to 12,323 WETH. On the same basis, the hacker's position on Compound yields an additional 1,845 WETH. Combined, these four streams represent approximately 87,955 ETH of recovered or recoverable funds, equivalent to roughly 54% of the original shortfall. The residual funding gap that the coalition needs to bridge is therefore approximately 75,081 ETH. Of the four recovery streams, only the Kelp freeze is immediately deployable as rsETH backing. The remaining streams, such as the Arbitrum Security Council release and the liquidation of the hacker's positions on Aave and Compound, are recoverable in substance but not yet liquid, and could take several weeks. !image Current Funding and Treasury Ask Due to Snapshot's character limitations, this section was removed and is available on the Aave governance forum. https://governance.aave.com/t/arfc-rseth-incident-funding-update/24740 Specification Voluntary Donation The Aave DAO approves making the following funds available as a Donation from the treasury to support rsETH backing recovery, subject to the finalisation of the broader ecosystem’s DeFi United recovery plan. !image Recovery Effort This proposal authorises Aave Labs (or a designated affiliate acceptable to Aave Labs and the DAO) to act as counterparty on any loan, settlement, indemnity or related legal instrument on behalf of the Aave DAO, solely for the purpose of executing the recovery plan referenced above. Supporting the recovery plan is anticipated to involve, but not be limited to, providing collateral such as Aave DAO assets and future Aave Protocol revenue, to secure various funding arrangements, such as under-collateralised loans, warrants, and potential token sales. To facilitate entering into such arrangements, assets held by the Aave DAO across SAFEs and Ecosystem Reserve are to be made available as and when required. Refined figures, the asset composition of the contribution, the payment schedule, and any associated counterparty and indemnity terms will be disclosed in a subsequent publication to the DAO once the coordinated recovery plan has progressed further. Approval If approved by AAVE token holders via Snapshot vote, Aave DAO representatives shall make the stated funds available for the intended purpose and authorise Aave Labs (or a designated affiliate acceptable to both Aave Labs and the DAO) to secure funding on behalf of the Aave DAO exclusively for the purpose of orderly resolution of the rsETH backing shortfall, including remediating bad debt and restoring the health and normal functioning of affected markets, and facilitating any future restructuring of those facilities. That authority is subject to defined limits. Aggregate borrowing across all rescue lenders is capped at a maximum amount reflecting the residual funding gap. The revenue share directed to repayment will not exceed a pre-defined percentage of total Aave protocol revenue, as determined by Aave service providers, applied on full drawdown and directed onchain to dedicated repayment contracts. The repayment term for each drawdown is subject to a maximum duration from the applicable drawdown date, with the option to refinance respective facilities at a later date. Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If Snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

Summary Following the rsETH bridge incident on April 18, 2026, AAVE buybacks have been paused since April 19, 2026. This ARFC formalises the pause and outlines the conditions under which the buyback cadence will be reassessed. Motivation Overview On April 18, 2026, an exploit on Kelp's LayerZero rsETH bridge route caused unbacked rsETH to enter Aave V3 markets across multiple chains. The Aave Protocol Guardian and Risk Steward executed immediate defensive measures, including freezes on all rsETH and wrsETH reserves and interest rate adjustments on WETH reserves across affected deployments. The incident, its scope, loss allocation scenarios, and potential bad debt figures are detailed in the LlamaRisk incident report and subsequent update: rsETH Incident Report (April 20, 2026) Update following the Arbitrum Security Council seizure (April 21, 2026) Rationale for Pausing Buybacks The range of potential outcomes for rsETH loss allocation, recovery, and any resulting DAO-level response remains wide. Until these external variables are resolved, preserving balance sheet flexibility is prudent. Deploying DAO revenue into buybacks during this window would reduce the treasury's capacity to participate in a coordinated response should one become necessary. For that reason, no buyback transactions have been executed since April 19, 2026. This ARFC formalizes and discloses the pause to the community. Specification AAVE buybacks are paused effective April 19, 2026, and will remain paused until the situation surrounding the rsETH incident becomes clearer. The cadence will be revisited at a later date, and any resumption will be communicated via the standard funding update. Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If the snapshot outcome is YAE, implement the proposal. Copyright Copyright and related rights waived via CC0.

Author: Aave Labs Date: 2026-04-10 Simple Summary The current proposal is set to onboard Sonic stablecoin USSD to Aave V3 Sonic Instance. USSD will enable users to supply USSD for yield and use it as a stable borrowing mechanism. Motivation USSD is Sonic's network-integrated USD stablecoin designed to become the key source of stable liquidity across the Sonic ecosystem, built on Frax's frxUSD infrastructure. USSD is backed 1:1 by high-quality USD assets and can be redeemed back to USDC on any CCTP-supported chains, providing a familiar and reliable on and off-ramp. Using Layer Zero interoperability, USSD enables users to mint USSD from over 10+ chains directly to Sonic. Reserves consist of short-duration, tokenized U.S. Treasury products, including BlackRock's BUIDL, Superstate's USTB, and WisdomTree's WTGXX, custodied with regulated providers to support redemption confidence and regulatory alignment. Technical Details Minting: USSD is minted through non-custodial smart contracts at a 1:1 ratio with no minting fees. Peg: 1:1 USD Reserve Composition: Tokenized short-duration U.S. Treasury instruments: - BlackRock USD Institutional Digital Liquidity Fund (BUIDL) - Superstate Short Duration U.S. Government Securities Fund (USTB) - WisdomTree Government Money Market Digital Fund (WTGXX) Collateral Types: USDC, USDT, PYUSD, USDB, BUIDL, USTB, WTGXX, and others at 1:1 ratio Custodians: Regulated institutional custodians Supported Mint Assets Stablecoins USDC USDT PYUSD USDB Tokenized Treasuries BUIDL USTB WTGXX Other approved USD / Treasury representations Contract Address (Sonic): https://sonicscan.org/token/0x000000000eccff26b795f73fb0a70d48da657fef Specification Risk Parameters will be provided by Risk Service Providers and proposal will be updated accordingly at ARFC stage. Useful Links https://www.soniclabs.com/ussd https://blog.soniclabs.com/ussd-sonics-native-permissionless-usd-stablecoin-built-with-frax/ https://docs.soniclabs.com/sonic/ussd Next Steps Publication of TEMP CHECK to gather community & service providers feedback, and escalate to TEMP CHECK Snapshot. Publication of a standard ARFC, if TEMP CHECK Snapshot passed, to continue collecting 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. Disclaimer The current proposal is raised on behalf of a third party. Aave Labs is not compensated for raising this proposal. Copyright Copyright and related rights waived via CC0.

Overview Given the current state of the Aave V2 instance, Chaos Labs conducted a detailed evaluation of the oracle configurations and risk parameters across all listed assets. The objective of this analysis is to identify assets whose oracle setups and risk parameters can be adjusted according to their specific market condition and risk profiles. Where appropriate, these changes aim to reduce potential risk exposure, simplify oracle dependencies, and support the orderly wind-down and deprecation of the V2 instance. Stablecoin Oracle Recommendation For stablecoins that are used exclusively as debt assets and do not have a CAPO-imposed upper bound, we recommend hardcoding their price to $1. In addition to operational simplicity, this approach mitigates protocol risk by preventing debt inflation driven by oracle manipulations. More specifically, these stablecoins are exposed to risks of temporary overpricing due to oracle manipulation. In such scenarios, an attacker controlling a large portion of the stablecoin supply can artificially inflate its price, causing the reported value of the debt to increase rapidly, even though the underlying economic value of the asset has not materially changed. This creates a critical risk in liquidation dynamics. As debt is marked at an inflated price, positions will be pushed into liquidation. At this point, the liquidator/attacker, can repay debt using assets acquired at significantly lower market prices while seizing collateral valued based on manipulated oracle prices. This results in an economically unbalanced transfer of value from borrowers to liquidators. In addition to harming borrowers, this behavior can also introduce risk to the protocol. If the debt price is sufficiently inflated, liquidators can repay a small portion of the debt while seizing the entirety of the collateral. Once the manipulation reverts, the position may be left with no remaining collateral but still outstanding debt, which effectively becomes bad debt for the protocol. Importantly, this risk is not limited to positions where the manipulated asset represents the majority of the debt. Even when the affected asset constitutes only a small portion of a multi-asset debt position, a sharp increase in its reported price can be sufficient to push the entire position below the liquidation threshold. As a result, the full collateral of the position may become subject to liquidation, despite the manipulation originating from a relatively small component of the total debt. Given these considerations, we recommend hardcoding the prices of these stablecoins that do not have a CAPO-imposed upper bound. In addition to mitigating potential bad debt risk, this configuration does not introduce additional risk under normal market conditions. Temporary deviations, including short-term overpricing or depegging, do not pose a risk to the protocol when these assets are used solely as debt and are hardcoded. Only in scenarios where prices remain persistently deviated does the risk profile change. If the asset trades below the peg for an extended period, the impact is primarily borne by borrowers, who effectively repay more relative to market value. If, instead, the asset remains persistently overpriced, this may introduce potential risk to the protocol. In such cases, liquidators must acquire the stablecoin at elevated market prices to repay debt accounted at $1. If the deviation becomes sufficiently large, the liquidation bonus may no longer compensate for the higher acquisition cost, weakening liquidation incentives and potentially leaving positions unresolved. However, to mitigate this risk, we also recommend to increase the liquidation bonus for collateral assets associated with these hardcoded stablecoins, ensuring that liquidation incentives remain sufficient under such conditions. Based on the above, we recommend hardcoding the oracle price of FEI and RAI, and increasing the LB of their associated collateral to ensure sufficient liquidation incentives. Risk Parameter Recommendation We propose a slight reduction in the LT of TUSD. The objective is to facilitate the gradual unwinding of TUSD borrowing positions as part of the Aave V2 deprecation process, while avoiding forced immediate liquidations for a large number of existing users. The rationale for this adjustment is consistent with the reasoning behind the risk parameter changes for volatile assets outlined below. Volatile Asset Oracle Recommendation We recommend fixing the price of selected volatile assets in terms of the base currency (ETH), rather than relying on market-based oracle feeds. This approach is consistent with the treatment applied to stablecoins described above, aiming to mitigate the risk of upward price manipulation and reduce protocol-level risk arising from distorted debt valuation. At the same time, we do not recommend modifying the oracle configuration for assets that retain sufficient market depth and liquidity, as the current market depth makes sustained oracle manipulation less likely and limits the associated bad debt risk. In addition, we propose setting these fixed asset/ETH prices at a level above their current market-implied value (e.g., ~30% higher than spot). This serves two purposes. First, it mitigates the risk of liquidation inaction arising from discrepancies between the fixed oracle price and the actual market price. If the asset trades materially above the fixed oracle level, liquidators may be forced to acquire the asset at significantly higher market prices than implied by the oracle, rendering liquidations economically unattractive. By introducing an upward buffer, this risk is reduced, helping ensure that liquidations remain executable in practice. Second, by increasing the effective debt value, it helps push marginal positions closer to liquidation, thereby facilitating the unwinding of smaller positions and contributing to the overall acceleration of Aave V2 deprecation. Risk Parameter Recommendation We recommend reducing the liquidation thresholds of all assets that currently have a non-zero LT. This change is to support the gradual unwinding of remaining positions as part of the Aave V2 deprecation process, without triggering immediate liquidations for the majority of the market, allowing for the primary existing users to react to the changes. To assess this, we simulate user-level position snapshots under progressive LT reductions using the latest full position dataset. At each reduction level, we apply small absolute LT cuts of 1% to 10% simultaneously across all collateral assets that have a non-zero LT, while holding prices and debt fixed. For each reduction level, we recompute wallet-level health factors under the shocked LT parameters and identify wallets that are newly pushed into liquidation. Newly liquidatable wallets are defined as those with a pre-shock health factor at or above 1 that fall below 1 after the LT change. We then measure the resulting newly liquidatable collateral exposure as the total collateral-enabled supply held by these wallets across all shocked assets. !image1.jpg The above exposure metric represents the total amount of collateral that becomes associated with wallets entering liquidation risk under the given LT reduction scenario. However, this estimation is conservative, as it accounts for the full collateral balance held by newly liquidatable wallets, rather than the smaller portion that would actually be liquidated in practice. The results indicate that the system remains relatively stable under moderate LT reductions, but exhibits a nonlinear increase in risk beyond a certain point. When all collateral LTs are reduced by 4%, the resulting newly liquidatable collateral exposure is approximately $319K. However, increasing the reduction to 5% leads to a sharp increase in exposure to roughly $761K. This inflection suggests that the system begins to enter a more sensitive regime beyond the 4% reduction level. Based on these results, we recommend implementing a uniform 4% LT reduction across all collateral assets on Ethereum. This level introduces a controlled amount of liquidatable collateral, facilitating more efficient system deleveraging, while preserving the stability of the vast majority of user positions. Additionally, based on the simulation framework outlined above, we have also applied corresponding LT reductions to assets with non-zero LT on Avalanche and Polygon to accelerate the deprecation of Aave V2 on these instances. Interest Rate Model Recommendation Reduce IRM For assets where healthy debt is significantly smaller than stressed debt, we recommend reducing IRM to ~0% to stop further interest accrual. In such scenarios, additional interest primarily accrues on already distressed or uncollectible positions, effectively increasing the protocol’s eventual loss. Freezing debt growth is therefore a more appropriate approach during the unwind process. The chart below shows the composition of outstanding debt across selected borrowed assets on Aave V2, split between healthy debt and stressed debt. Healthy debt refers to debt backed by positions with a HF of at least 1, while stressed debt refers to debt associated with positions where HF is below 1. For each asset, the left column presents a 100% stacked view of this composition, showing the relative share of healthy versus stressed debt. The adjacent column shows the total amount borrowed for that asset in USD. !image2.png As shown, for assets such as MANA, FEI, and BUSD, stressed debt already exceeds healthy debt by a significant margin. In these cases, continued interest accrual is unlikely to be recovered and instead increases the notional size of bad debt. Accordingly, we recommend reducing IRM to ~0% for assets where stressed debt exceeds healthy debt, as IRM no longer serves as an effective risk management tool and instead amplifies realized losses. Other Considerations We suggest setting the Slope2 parameter to 100% for selected assets with non-zero IRM. These assets do not fall under the condition outlined in the previous section, and therefore their overall IRM configuration can remain unchanged. However, adjusting Slope2 allows for a more controlled response under high utilization, helping to accelerate deleveraging and liquidations without pushing borrow rates to excessively high levels. This achieves a more balanced and effective risk management outcome. We also recommend increasing the IRM of TUSD to align with the parameters proposed in our previous recommendation, while lowering its Slope2 for the reasons described above. Additionally, as the AMPL market does not contain remaining collateralized positions, and the existing suppliers have been previously compensated through Merkl distribution here, we recommend setting its Interest Rate Curve to 0. Finally, we recommend increasing the IRM of WPOL. Despite being a major asset on Polygon, its oracle exhibits relatively slow update characteristics, with an inferred deviation threshold of ~1% and a heartbeat of approximately 6 hours. As WPOL remains enabled as collateral, hardcoding its price is not feasible, leaving the system exposed to potential upward price deviations. To mitigate this risk, increasing IRM introduces additional pressure on outstanding borrow positions, encouraging faster deleveraging and reducing the duration of exposure under potentially stale or distorted pricing conditions. Specification Stablecoin Oracle Adjustment | Asset | Instance | Recommended Oracle Value | | --- | --- | --- | | FEI | Ethereum | $1 | | RAI | Ethereum | $4 | Volatile Asset Oracle Adjustment | Asset | Instance | Recommended Asset Price in ETH (1e18) | | --- | --- | --- | | SNX | Ethereum | 181283037000000 | | YFI | Ethereum | 1570701733962692240 | | xSUSHI | Ethereum | 188874382650430 | | ENS | Ethereum | 3750500000000000 | | BAT | Ethereum | 68399060169053 | | MANA | Ethereum | 53454081966022 | | DPI | Ethereum | 29597100000000000 | | ZRX | Ethereum | 63782978634450 | | BAL | Ethereum | 95553200014979 | | 1INCH | Ethereum | 57057200000000 | | KNC | Ethereum | 86975575866599 | | ENJ | Ethereum | 12846949494839 | | REN | Ethereum | 2242430213652 | | CVX | Ethereum | 1062775618954092 | | BAL | Polygon | 95553200014979 | | GHST | Polygon | 39940215118135 | Risk Parameters Adjustment | Asset | Instance | Current LT | Current LB | Recommended LT | Recommended LB | | --- | --- | --- | --- | --- | --- | | USDC | Ethereum | 87.50% | 4.5% | 83.5% | 10% | | WETH | Ethereum | 86% | 5% | 82% | 10% | | DAI | Ethereum | 77% | 4% | 73% | 10% | | MKR | Ethereum | 10% | 7.5% | 6% | 10% | | stETH | Ethereum | 83% | 7% | 79% | 10% | | TUSD | Ethereum | 65% | 10% | 61% | - | | LINK | Ethereum | 65% | 7% | 61% | 10% | | WBTC | Ethereum | 82% | 5% | 78% | 10% | | AAVE | Ethereum | 73% | 7.5% | 69% | 10% | | WBTC.e | Avalanche | 70% | 5% | 65% | 10% | | USDC.e | Avalanche | 78% | 5% | - | 10% | | WETH.e | Avalanche | 82.5% | 5% | 77.5% | 10% | | DAI.e | Avalanche | 77% | 5% | - | 10% | | WAVAX | Avalanche | 65% | 10% | 55% | - | | AAVE.e | Avalanche | 65% | 10% | 50% | - | | WETH | Polygon | 82.5% | 5% | 80.5% | 10% | | WBTC | Polygon | 75% | 5% | 70% | 10% | | USDC.e | Polygon | 84.5% | 5% | - | 10% | | DAI | Polygon | 77% | 5% | - | 10% | | AAVE | Polygon | 65% | 10% | 50% | - | | WPOL | Polygon | 70% | 10% | 65% | - | IRM Adjustment | Asset | Instance | Current Uoptimal | Current Base | Current Slope1 | Current Slope2 | Recommended Uoptimal | Recommended Base | Recommended Slope1 | Recommended Slope2 | | --- | --- | --- | --- | --- | --- | --- | --- | --- | --- | | ENS | Ethereum | 45% | 20% | 0% | 300% | 1% | 1% | - | 0% | | LUSD | Ethereum | 45% | 20% | 0% | 300% | 1% | 1% | - | 0% | | FEI | Ethereum | 45% | 20% | 0% | 300% | 1% | 1% | - | 0% | | AMPL | Ethereum | 45% | 20% | 0% | 300% | 1% | 1% | - | 0% | | GUSD | Ethereum | 45% | 20% | 0% | 300% | 1% | 1% | - | 0% | | KNC | Ethereum | 45% | 20% | 0% | 300% | - | - | - | 100% | | DPI | Ethereum | 45% | 20% | 0% | 40% | - | - | - | 100% | | UST | Ethereum | 45% | 20% | 0% | 300% | - | - | - | 100% | | CRV | Ethereum | 45% | 20% | 0% | 300% | - | - | - | 100% | | FRAX | Ethereum | 45% | 20% | 0% | 300% | - | - | - | 100% | | UNI | Ethereum | 45% | 20% | 0% | 300% | - | - | - | 100% | | TUSD | Ethereum | 1% | 1% | 0% | 0% | 45% | 20% | - | 100% | | WPOL | Polygon | 25% | 5% | 15% | 40% | 45% | 20% | 0% | 100% | Disclaimer Chaos Labs has not been compensated by any third party for publishing this recommendation. Copyright Copyright and related rights waived via CC0

Author: Aave Labs Date: March 25, 2026 Summary This ARFC proposes to onboard PT-USDG-28MAY2026 to the Aave V3 Core Instance on Ethereum. Motivation We propose onboarding PT-USDG-28MAY2026 to the Aave V3 Core Instance. This PT token is attractive because the underlying asset is USDG, issued by Paxos, a highly regulated financial institution. This gives the market a dollar-denominated base asset with a straightforward reference point. A listing would allow users holding this Pendle maturity to access borrowing liquidity on Aave against that position, extending the utility of an already live market on Ethereum. The relevant Pendle market is already live, which allows the asset to be evaluated against observable market activity rather than hypothetical demand. Where demand scales, onboarding can allow Aave to capture additional collateral usage and related borrowing activity around this maturity. The underlying yield of PT-USDG has three components: a NIM rate pass-through, Paxos-denominated incentives, and PENDLE incentives. As a GDN member, Paxos passes yield to Pendle, which distributes it to YT holders via the Pendle Dashboard. PT holders capture this yield implicitly through the fixed discount at which PT is acquired, redeemable at par upon maturity. Specification Asset: PT-USDG-28MAY2026 Network: Ethereum Pendle Market: USDG May 2026 Expiry PT token address: 0x9db38D74a0D29380899aD354121DfB521aDb0548 Pendle market address: 0xc5b32dba5f29f8395fb9591e1a15f23a75214f33 Underlying asset: USDG Underlying asset address: 0xe343167631d89b6ffc58b88d6b7fb0228795491d Maturity: May 28, 2026 Risk Parameters This proposal will be updated with initial risk parameters once provided by Risk Service Providers. Useful Links Pendle market: https://app.pendle.finance/trade/markets/0xc5b32dba5f29f8395fb9591e1a15f23a75214f33/swap?view=pt&chain=ethereum&tab=book USDG overview: https://docs.paxos.com/guides/stablecoin/usdg Disclaimer Aave Labs is not directly affiliated with Pendle or Paxos and did not receive compensation for creating this proposal. Next Steps If the ARFC Snapshot outcome is YAE, publish an AIP with risk parameters and supporting analysis. Copyright Copyright and related rights waived under CC0.

1. Summary Aave began with the thesis that decentralized lending could play a major role in traditional finance. Eight years later, that thesis has been validated. Aave is the largest protocol in decentralized finance, commanding a 60% market share in lending. The opportunity ahead, however, is bigger than anything behind us. Detailed below is a strategic framework proposal for Aave’s next chapter. It is the result of extensive community discussion during the Temp Check phase and incorporates significant feedback from DAO stakeholders. It proposes to direct revenue from Aave-branded products to the DAO treasury and to establish a one-year budget for continued development under an accountability framework. It also includes a commitment to protect the Aave brand and its intellectual property. Based on community feedback, the ratification of Aave V4 and the detailed structure of a brand-governing structure have been unbundled from this proposal and will each be addressed in separate, dedicated governance proposals. This proposal asks the DAO to approve the following operational framework: Direct 100% of revenue from all Aave Labs’ Aave-branded products to the Aave DAO treasury. Commit to a solution for protecting the Aave brand and its intellectual property. Create a one-year framework for the DAO to fund strategic growth and development with accountability. 2. Aave Labs Commitment We are becoming a token-centric company and formalizing our alignment with the Aave DAO. Going forward, we will continue to generate revenue, but that revenue will flow to the DAO. Under this framework, Aave Labs works exclusively on Aave-related products, protocol development, and ecosystem growth. We will not build non-Aave related products, pursue outside revenue, or retain product revenue for our own operations. The DAO funds our work, and the DAO receives the revenue that work produces. Every dollar we receive is invested in building, growing, and scaling the Aave Protocol. Any unspent funds at the end of the 12-month period will be returned to the DAO treasury or rolled into any DAO-approved subsequent budget. 3. Motivation The LEND token sale in 2017 raised $16M to build a decentralized lending protocol. That initial foundation grew into Aave, a multi-billion-dollar ecosystem that has since created billions in value. Along the way, Aave Labs (the core development team behind the Aave protocol) has requested DAO funds only for direct protocol development and marketing activities. Everything else has been self-funded. This includes the product layer, which encompasses aave.com, the Aave mobile app, Aave Pro, Aave Kit, and Aave Horizon. It also includes legal and regulatory work, such as the response to a multi-year US Securities & Exchange Commission investigation, brand protection, trademark management, and compliance. Business development and growth has been self-funded as well. We are now entering one of the most important periods that will determine Aave’s success going forward. Fintechs are entering DeFi, institutions are coming onchain, and regulatory clarity is emerging in certain markets that allows us to go directly to consumers. The protocols that win the next decade will be those that move fast, build great tools and products, and capture new markets before competitors. With the right focus, and by investing in important growth areas, Aave is positioned to do exactly that. Other approaches to this framework exist, but each involves different trade-offs. Aave Labs could operate independently and retain product revenue to fund itself. However, this would require a clear separation between protocol revenues and those generated by the Aave-branded products built on top of the protocol. Alternatively, the DAO could directly build and operate Aave-branded products through governance, but the execution would likely be slower, and governance overhead is inherently difficult to scale at the pace required. This proposed framework achieves a token-centric alignment and a vision to help Aave win in the coming decade. It directs product revenue to the DAO, includes a commitment to protecting the brand and intellectual property on behalf of the DAO, and provides a clear development roadmap with the resources to execute it. 4. Specification Aave Product Revenue to the DAO The first ever Aave governance proposal, AIP-1, established that the Aave Protocol be governed by AAVE token holders, resulting in the DAO rightfully receiving 100% of protocol fees. And since Aave Protocol’s launch, Aave Labs has operated the primary interface, aave.com, which became a key access point for most of the protocol usage across retail users, power users, institutions and integrators. This interface has supported millions of users without a single security incident, demonstrating both reliability and sustained execution. In parallel, the DAO has matured significantly since AIP-1. With that foundation in place, we believe the time is right to evolve toward a more aligned, token-centric model that reflects the protocol’s growth and long-term trajectory. Under this proposal, 100% of revenue from all Aave-branded products developed by Aave Labs will be directed to the Aave DAO treasury. This includes revenue from: aave.com, the existing interface, and all associated fees Aave App, the consumer mobile application Aave Card, a card tied to Aave App with all fees flowing to the DAO Aave Pro, the primary interface for Aave V4 Aave Kit, enterprise solutions for fintechs and institutions building on Aave Aave Horizon, Aave’s RWA market and institutional services Any future Aave-branded products that may be developed If approved, this proposal would direct all revenue from the products listed above. That includes revenue from the aave.com swap integration, currently generating approximately $12-24 million annually, to the DAO treasury. As a result, the DAO’s product revenue stream would become immediately material from day one. We heard the community’s feedback on revenue definitions, and we appreciate the request for greater clarity. The intent of directing product revenue to the DAO is value-accretive. The purpose of this framework is to grow the DAO’s treasury rather than create a mechanism for Aave Labs to retain value alongside it. “Revenue” is defined as gross product revenue earned by Aave Labs, minus any direct revenue sharing paid by Aave Labs to external partners including revenue rebates, revenue subsidies, revenue sharing arrangements and any additional direct user incentives. Under this definition, expenses only in relation to revenue-sharing arrangements and user incentives are explicitly included. No other costs, including development, infrastructure, or operating expenses, may be deducted from product revenue. For increased community assurance, we commit to per-product transparency. All product revenue and deductions will be reported quarterly and verified by an independent third-party such as an auditor. This way, the DAO can have direct oversight of funding decisions and outcomes, and continue to vote accordingly. With proper execution, the product layer can be an additional source of revenue for the DAO treasury. Combined with protocol fees, the DAO can fund its own growth, security, and development from a diversified revenue stream. Aave Labs commits to work on only Aave-related products and protocols and nothing else. Aave V4 and V3 Maintenance Based on community feedback, the ratification of Aave V4 has been unbundled from this proposal. A separate, dedicated ARFC for the activation of Aave V4 has been passed by the DAO. And an AIP is now live for that activation. This allows the community to evaluate the V4 activation on its own merits, while this proposal focuses on the funding and operational framework. Aave V3 will continue to operate as long as it is needed. Expanding Revenue Through Aave V4 The product layer is one part of the path to increasing the DAO’s annual revenue. The protocol layer, powered by Aave V4, is the other. Aave V3 already generates over $100 million in annualized revenue for the DAO, making it one of the highest earning DAOs in DeFi. Aave V4 expands on V3 with new monetization features that allow the protocol, and DAO, to capture more value from the risk it underwrites. V4’s architecture also unlocks revenue streams that are not easily possible in previous Aave versions. Each Spoke can extend Aave into a new market or use case, with its own risk parameters and revenue model. As with V3, 100% of Aave V4’s protocol revenue will also go to the DAO. We’ve taken a look at various products and protocols across the crypto, fintech, and financial services industries to show estimations that highlight the size of the opportunities available: These opportunity estimates are based on other protocols or products in each category (e.g. Pendle, Fluid), and the size of the opportunity (e.g. OTC lending volume), etc. They each represent a net new revenue opportunity on top of what Aave already generates today, and they are only possible to pursue in a scalable way once V4 is live. Reaching these estimates would also depend on market conditions, scale of adoption, and execution. Aave V4 also introduces a new reinvestment module, which is an optional net new revenue opportunity for the DAO to consider. Currently, Aave pools maintain a significant idle float that currently earns nothing. This reinvestment feature allows the protocol to sweep this capital into short-term, low-risk yield opportunities pre-vetted and approved by the DAO, similar to a collateral listing. When Aave rates fall below SOFR-rates, it signals underutilized liquidity that could be productively deployed. Based on historical stablecoin float levels and a risk-free proxy SOFR-rate, the additional interest that would have been earned is substantial: These figures are illustrative good faith estimates based on historical performance and idle liquidity, and are included to inform governance discussions around prioritization and resource allocation. They do not constitute projections, commitments, or expectations, and actual outcomes may vary materially depending on governance choices, execution, adoption, and market conditions. This interest can be allocated between users and the DAO, or otherwise distributed at the DAO’s discretion. The analysis does not account for other strategies such as ETH staking or reinvesting into higher-yield opportunities, which may also be pursued if the DAO elects to do so. Taken together, these opportunities illustrate the range of operational scale the DAO may need to support across both the protocol and product layers if adoption and market conditions warrant it. Viewed as an aggregate opportunity set, they suggest that the long-term revenue ceiling for the Aave ecosystem is materially higher than today. The Aave Brand and Intellectual Property As outlined above, we are moving toward a token-centric model and strongly believe that the Aave IP should be held in a community-protected vehicle. This includes repositories, domains and any other operational assets necessary to ensure continuity in the event of service provider changes. As requested by the DAO community, the detailed structure for governing the Aave brand and its associated intellectual property will be presented in a separate, dedicated ARFC. Establishing this community-protected vehicle will require substantial research, legal structuring, and consultation. The evolving regulatory environment can also be a factor in affecting this process and informing the range of viable options. The Temp Check for this proposal will be live within 180 days if the Aave Will Win Framework passes. This gives ample time to properly research, scope, and provide precise details on how this could take place. However, the community-protected vehicle itself would not be created until the DAO decides on all relevant details. Technical Roadmap and Expanded Responsibilities This section covers what Aave Labs plans to build and maintain over the next year as part of the funding request in this proposal. It also explains how we will handle the responsibilities previously managed by BGD Labs and ACI following their departures. Our work currently falls into four areas including the core protocol, GHO, user-facing applications (e.g. Aave Pro, Aave App), and developer tooling (e.g. Aave Kit). Core Protocol Our primary protocol work covers both Aave V3 and Aave V4. Development continues on the V4 core architecture and a full set of Spoke implementations. Development priority and sequencing will be determined by market demand, technical readiness, and strategic fit. Some Spokes listed here may be deprioritized or replaced by new opportunities as the market evolves. Our current focus includes the Umbrella Spoke, Flash Loans Spoke, Permissioned Spoke, Debt Trading Spoke, Segregated Collateral Spoke, LP Collateral Spoke, and Cross-Chain Spoke. Some Spokes and extensions, such as Reinvestment Strategies, may be developed by other service providers. Aave V3 and V2 will continue to receive maintenance, security monitoring, and contract upkeep. We have the engineering bandwidth to absorb these responsibilities from BGD Labs. Parameter optimizations, risk management updates, security patches, and technical reviews of governance proposals will proceed as normal in collaboration with the DAO’s other service providers. New chain deployments and asset listing support will also continue as needed. Aave App The Aave App for iOS and Android is being built from the ground up as a consumer-facing mobile application. Planned work includes a simplified yield-bearing savings product, cross-chain yield strategy tools, fiat on- and off-ramp connectivity, recurring deposits, smart accounts with anti-phishing protections, and account recovery. The Aave App represents a major, multi-year commitment to bring Aave to a new generation of retail users. Aave App puts Aave in front of a whole new consumer market with the potential to onboard millions of users. This puts Aave next to many of the largest fintech names in the world and allows it to expand beyond a DeFi-native brand. While Aave App will begin as a simple savings application, it is designed to evolve into a more comprehensive product suite, incorporating features such as the Aave Card, unlocking yet more revenue opportunities. GHO Stablecoin Aave Labs will supervise, or directly implement, a direct minting integration for Aave V4 and on- and off-ramp infrastructure through a specific GHO Stability Module. Other activities like new collateral facilitators and multi-chain sGHO implementation will be supervised or contributed to without disrupting the work of other active service providers, that will continue operating as they where before and eventually expand their scope over time. These features expand GHO’s utility and make it easier for users and integrators to work with the stablecoin. While Aave Labs will supervise the core GHO maintenance when needed, the product’s scope is wide enough to support and maintain continued contributions from multiple service providers. Aave Kit Aave Kit is our dedicated, enterprise-grade B2B product suite for fintechs and institutions building on Aave. This is a significant opportunity. As more traditional financial companies look to integrate DeFi into their products, Aave needs a purpose-built set of tools, APIs, SDKs, and documentation to serve them. Aave Kit addresses this by providing enterprise-grade developer tooling, integration support, and a clear onboarding path for institutional partners. We are also exploring agentic interfaces (MCP for AI agents) as part of our R&D efforts in this area. Aave Pro Aave Pro is the primary user-facing interface for the Aave ecosystem, significantly enhancing and expanding the capabilities available to users. Its vision includes advanced functionality such as a transaction builder for complex position management, seamless migration tooling from V3 to V4, one-click leverage and deleverage strategies, direct fiat on-ramping from bank accounts, and expanded swap revenue through automated strategies. Many of these features will be directly revenue-generating for the DAO. The existing aave.com interface will continue to be maintained as a reliable access point and revenue source for the DAO, while Aave Pro represents its natural evolution. Expanded Responsibilities BGD Labs and ACI together have historically handled a range of distinct protocol functions. Each has been reviewed, and we have outlined which responsibilities can be absorbed by Aave Labs within the scope and funding framework of this proposal. On the protocol side, this includes V2 and V3 contract maintenance, security coordination, chain upgrade analysis, asset listing and network technical reviews, support for V2 off-boarding, and enabling a user-driven migration path from V3 to V4. Treasury and collector contract management will transition to other service providers. On the governance and infrastructure side, Aave Labs will assume responsibility for governance proposal tooling, maintenance of the Aave DAO GitHub repository, Guardian coordination, the Address Book, the Permission Book, CAPO pricing management, ENS space management, DNS and hosting for the governance interface, bridge adapter maintenance, Proof-of-Reserve automation, technical reviews of governance proposals, and securing the governance forum. From ACI, Aave Labs will absorb, and in some cases further improve alongside the DAO, the governance proposal lifecycle (Skyward), Dolce Vita and incentive program infrastructure. Some specialized functions will be transitioning to service providers other than Aave Labs. These include Risk Agents, the Aave Seatbelt safety mechanism, Aave Robot infrastructure, and the Generalized Risk Stewards (AGRS). This allocation ensures that responsibilities are best aligned with each team’s core competencies. Roadmap Summary The table below provides a high-level view of our technical priorities. | Focus Area | Initiatives | Workstream | |---|---|---| | Protocol Core | Aave V4 launch and continuous development, security, and maintenance | Development, Maintenance, Security | | Protocol Core | Aave V4 Spoke development | Development | | Protocol Core | V2/V3 maintenance and security | Maintenance, Security | | Protocol Core | New chain deployments and asset listings | Maintenance | | Protocol Core | Protocol improvements and R&D | R&D | | Aave Horizon | Continuous expansion of RWA collateral | Development, Maintenance | | Aave Horizon | Port Aave Horizon over to Aave V4 | Development | | GHO | GHO/sGHO development | Development, Maintenance, Security | | GHO | V4 GHO integrations | Development | | GHO | On/off-ramp solutions (GSM) | Development | | GHO | LP collateral facilitator | Development | | Aave App | Product development (iOS and Android) | Development | | Aave App | Savings product and yield strategy integrations | Development | | Aave App | Fiat on/off-ramp and recurring deposits | Development | | Aave Pro | Product development | Development | | Aave Pro | Transaction builder, leverage and deleverage feature, advanced strategies, fiat on-ramping, etc. for revenue generation | Development | | Aave Pro | Incentive management and integrations | Development | | Aave Kit | API, SDK, documentation | Development | | Aave Kit | Agentic Aave R&D (MCP for AI agents) | R&D | | Governance | Governance tooling and infrastructure | Maintenance, Security | | Absorbed from BGD | Several protocol maintenance, security, and infrastructure functions for Aave V3/V4 | Maintenance, Security | | Absorbed from ACI | Governance operations and BD functions for Aave V3/V4 | Operations | While not exhaustive and subject to expansion over time, this list reflects the minimum scope included in the funding request under this proposal. DAO Growth Requires Resources at Scale The operational framework outlined above requires execution at a scale commensurate with the opportunity. For Aave to scale and play a role in the real financial system, it must invest in growth with the same discipline and ambition as fintechs, banks, and other financial institutions. Without a clear commitment to this objective, Aave’s long-term upside will remain constrained. If all product revenue generated by Aave Labs flows to the DAO, the DAO must also be prepared to fund the continued development, maintenance and expansion of these products. This is especially relevant as Aave Labs assumes the responsibilities of two departing service providers. The scope of work encompassed by this proposal is materially broader than any prior Aave Labs engagement and exceeds that of any individual service provider to date. It spans protocol development, product engineering, business development, legal and compliance, go-to-market execution, and nearly the full set of governance and infrastructure functions previously handled by BGD Labs and ACI. Despite this significantly expanded workload, we are confident we can deliver within the budget proposed during the Temp Check. Aave Labs Funding Request The DAO is now facing a structural decision regarding Aave Labs’ operating model going forward. Currently, Aave Labs self-funds a substantial portion of its operations. This reflects the original direction set by AIP-1: revenue from Aave-branded products, such as aave.com and other product surfaces, has been used to fund Aave Labs’ product development, marketing, legal, and operations costs, while the DAO has funded core protocol development and version upgrades. Under the proposed operational framework, all fees generated by Aave-branded products would flow directly to the DAO treasury rather than being retained by Aave Labs to support its operations and product development. As a result, responsibility for funding Aave Labs’ activities would shift correspondingly to the DAO. In parallel, Aave Labs would absorb the majority of responsibilities previously handled by BGD Labs and ACI. Together, these two service providers were funded at approximately $7.4M per year in stablecoins plus 9,450 AAVE per year. This is a combined value of roughly $9M per year at current token prices. Aave Labs requests $25 million in stablecoins, 75,000 AAVE, in addition to growth and development grants structured in line with community feedback, as detailed below: Primary Grant Aave Labs proposes a total primary grant of $25 million, structured across three components: $5 million paid upfront upon approval of the proposal Two concurrent streams both starting at month one: - Stream A: $5M over 6 months (~$833K/month, ends at month 6) - Stream B: $15M over 12 months (~$1.25M/month, ends at month 12) This structuring is intentionally front-loaded to support the most capital-intensive phase of execution, particularly pre-launch product development and initial go-to-market efforts, where timely investment is critical to success. Any unspent portion of the primary grant at the end of the 12-month period will be returned to the DAO treasury or rolled into a subsequent DAO-approved budget, ensuring continued accountability and capital efficiency. In addition, 75,000 AAVE will be allocated upon approval of the proposal, vesting linearly over a four-year period. This extends the vesting schedule outlined in the original Temp Check, in response to community feedback for stronger long-term alignment between Aave Labs and the DAO. This grant is intended to fund Aave Labs’ operations over the 12-month period and support the expanded scope of work outlined above. The AAVE token allocation further enables Aave Labs to offer competitive long-term aligned compensation as the organization scales. Recruiting experienced engineers and operators in DeFi requires token-based incentives, which are standard across the industry. The AAVE token grant serves two purposes: keeping Aave Labs competitive in a brutal talent market, and ensuring our team is directly aligned with the AAVE token. On the talent front, we are 8 years post-TGE, competing head-to-head for engineers and operators against companies that are pre-TGE or have raised hundreds of millions of dollars, all of whom can offer token or equity compensation with asymmetric upside. Token grants are therefore a critical mechanism for Aave Labs to remain competitive. Without them, both retention and recruiting become increasingly difficult. Staff compensated in AAVE have a direct financial stake in the long-term success of the protocol, creating a level of alignment that is difficult to replicate through cash compensation alone. As Aave Labs takes on a broader operational mandate, we believe this alignment is essential. These tokens will not be used by Aave Labs to vote on any governance proposals. Instead, they are allocated exclusively for employee compensation and will vest according to individual vesting schedules, reinforcing long-term alignment between the team and the protocol. Growth and Development Grants In addition to the primary grant, Aave Labs requests a set of growth and development grants tied to specific product launches and milestones. These grants are distinct from the $25 million operating budget and are designed to fund the continued development, scaling, and long-term growth of the associated products and services. Based on community feedback, the growth and development grants have been restructured to better reflect the relative scale of commitment required by each product: Aave App: $7,500,000 allocated for Aave App, to support product development, marketing, and ongoing product operations. The Aave App is a major, multi-year commitment to build an entirely new consumer product from the ground up. This grant will be distributed in three tranches based on the following milestones: - Milestone 1: $5M upon public launch of the Aave App. - For go-to-market costs, insurance premiums, operating costs, ongoing product development, and consumer marketing. - Milestone 2: $2.5M upon reaching 50,000 verified user sign-ups within the Aave App. - For ongoing operating costs, user acquisition, onboarding costs, and consumer marketing. Aave Pro: $2,500,000 for Aave Pro, structured as a milestone-based grant payable upon the launch of advanced, revenue-generating features. This reflects a more balanced approach based on community feedback, given that the existing Aave interface already generates significant revenue for the DAO in its current form. - Milestone 1: $1.5M upon delivery of the transaction builder, leverage and deleverage tool, and rewards dashboard. - Milestone 2: $1M upon delivery of new vaults integration (with custom yield strategies for users) and fiat on-ramping. Aave Card: $5,000,000 for Aave Card launch, with funds used for card program creation and maintenance, marketing, and ongoing product development streamed over 6 months. Aave Kit: $2,500,000 for Aave Kit launch, with funds used for B2B go-to-market, marketing, product development and maintenance streamed over 6 months. Note: For clarity, all funds will be spent on Aave-related efforts. Growth and development grants are released upon delivery of the associated product and streamed over a nine month period, with governance confirming milestone completion prior to disbursement. This streaming structure, consistent with the primary grant, enables the DAO to maintain ongoing oversight while evaluating effectiveness over time. As well-capitalized companies increasingly enter DeFi and invest aggressively in both product and distribution, Aave must operate at a comparable scale to remain competitive. This level of commitment enables long-term planning, accelerated hiring, and sustained investment in product and go-to-market without the constraints of annual budget cycles. These growth and development grants are designed to fund the cost of bringing each product to market, from engineering through go-to-market, covering all associated development and commercialization costs. The funding requested represents a significant expansion in scope relative to historical funding. To date, Aave Labs has largely self-funded the cost of building and scaling the product layer, seeking DAO support mainly for core protocol development and focused marketing. This proposal secures the level of investment required for Aave to remain competitive and continue building over the next decade. Scaling Aave to compete with leading TradFi institutions requires stable, predictable funding, enabling contributors to plan effectively, attract and retain talent, and execute at the standard of a global financial platform. Altogether, these funds cover the following costs: Continued protocol development (V4 improvements, Spokes, core infrastructure, research and development) Continued protocol maintenance and security coordination for Aave V3 Product engineering across Aave Pro, Aave App, Aave Kit, and other products Product go-to-market, user acquisition, marketing (e.g. social media/content) and growth Business development, including partnering with the largest institutional and fintech names to integrate with Aave Aave Horizon asset onboarding and driving TVL/borrow growth Ongoing resource provision for institutional integrators, including technical, InfoSec and operational support Application security, including an extensive monitoring program and enterprise fees to social media platforms to protect the Aave brand Events, which Aave Labs historically has organized with DAO funding (e.g. rAAVE, DeFi Day, and institutional events) Absorption of ~40 functions from BGD Labs and ACI, including governance tooling, infrastructure maintenance, and security coordination Note: Security audits are funded separately by the DAO and, where managed by Aave Labs, will be agreed with the DAO. Aave Labs currently employs approximately 90 people. Roughly 60% are in technical teams (across engineering, product & design and security), with the remainder in business development, marketing, operations, legal and compliance. The approximate budget allocation by category is as follows: | Category | Approximate Allocation | |---|---:| | Engineering | 60% | | Product | 20% | | Business Development | 10% | | Marketing and Events | 5% | | Operations, including Legal and Compliance | 5% | With this funding, Aave Labs would have the runway required to execute effectively on the initiatives outlined above. It also reflects a deliberate choice by the DAO to fund the level of execution necessary to support protocol operations at an increased scale, should governance determine that such expansion is warranted. To maximize effectiveness, Aave Labs would retain autonomy over individual product strategy and day-to-day operations. Building competitive products requires the ability to move quickly, make decisions without excessive coordination overhead, and iterate in response to real-time market feedback. We recommend a similar model for other Service Providers who might choose to operate under this framework, enabling each to execute efficiently with clearly defined mandates. Accountability Framework This funding is subject to a strict accountability framework built on community feedback. Aave Labs will publish quarterly accountability reports covering: (1) funds received and spent by category, (2) KPI performance versus targets, (3) product delivery status, and (4) headcount changes. The first report will be published within 90 days of funding approval. Product-level KPIs will be tied directly to each funded initiative: | Product | Key Performance Indicators | |---|---| | Aave App | User Sign-Ups, Assets Under Management (AUM), Balance Retention Rate | | Aave Protocol | Net deposits, loans outstanding and originated, fees generated for DAO, active addresses | | Aave Pro | Trading volume through new features, revenue generated for the DAO, user adoption of advanced tools, AUM | | Aave Kit | Number of institutional partners integrated, net deposits and borrow volume onboarded through Aave Kit | | Aave Card | Number of active cardholders, transaction volume, net revenue generated for the DAO | | Protocol Core | V4 development milestones, V3 uptime and incident response, new chain deployments completed | All revenue and deduction figures will be independently verified and published to the governance forum. The DAO retains ultimate oversight through its control of the treasury and Aave Labs’ funding stream. If Aave Labs does not meet its commitments or perform effectively, the DAO can choose not to renew this budget. 5. Next Steps Aave remains early in its journey. What exists today is a foundational base layer, while the real scale of adoption lies ahead as global finance increasingly moves onchain. DeFi, in its current form, represents only a small fraction of the broader financial system. Over the coming decades, trillions of dollars in assets will migrate onto open rails. In that environment, Aave is well-positioned to become core infrastructure for global finance. Since 2017, the focus has been on disciplined execution at the frontier, and that approach continues to guide the protocol today. The next phase of growth, driven by innovation and accelerating institutional adoption, presents a significantly larger opportunity. With sustained commitment and effective execution, Aave can scale to support significantly greater demand and further solidify its role as core liquidity infrastructure for the onchain economy. This proposal seeks to establish a framework for Aave’s next decade. Upon approval, it would reaffirm Aave Labs’ alignment with the DAO by directing all Aave-branded product revenue to the DAO treasury, while enabling the resources required to execute at the necessary scale. It also commits to safeguarding the Aave brand and intellectual property on behalf of the DAO. A separate V4 activation proposal, along with a proposal outlining the structure for a separate community-protected vehicle will follow. If community consensus is reached, this proposal will be raised to Snapshot. If the Snapshot outcome is in favor, the framework will be implemented via one or more onchain AIPs to establish the funding streams and formalize the commitments outlined in this proposal. Disclaimer Historically, Aave Labs has self-funded its operations. Under this proposal, Aave Labs would receive funding from the DAO in exchange for directing revenue generated from Aave-branded products to the DAO treasury, if approved. This proposal was authored solely by Aave Labs, with no third-party contributors. Copyright Copyright and related rights waived under Creative Commons Zero (CC0).

!image Summary This publication provides an overview of the new native on-chain yield-accruing sGHO savings product upgrade. Within, we define the initial parameter configuration, present the migration process from the current sGHO (stkGHO rebranded), and introduce the new sGHO admin steward role. The proposal sets a fixed Aave Savings Rate (ASR) of 4.25% APR (50 basis points above the Sky Savings Rate), refines the boost program from 8 boosts to 1 transitional boost, establishes the sGHO Steward as the rate governance mechanism, and defines an aggressive migration schedule from the legacy sGHO contract. Motivation Overview GHO has reached an all-time high circulating supply of 404.7M across eight chains, with sGHO deposits totalling 304.6M. This growth, driven primarily by the @ACI powered savings product, validates the demand for a yield-bearing GHO instrument. The Aave Team has done a tremendous job managing the Merit-based reward system that fuelled this trajectory. !Screenshot 2026-03-30 at 10.15.32.png However, the current sGHO implementation presents structural limitations that constrain further growth: Composability unlock. The current Merit-based distribution, while highly effective for bootstrapping, relies on an off-chain reward model, making it difficult for external protocols to integrate natively. Moving to ERC-4626 means yield accrues directly in the share-to-asset conversion rate, making sGHO instantly composable across DeFi lending protocols, yield aggregators, and centralised exchanges. Streamlined yield story. The eight-boost system ACI designed was instrumental in driving targeted behaviours during the growth phase. With sGHO now at scale, consolidating five of those boosts into the native rate creates a simpler, more legible value proposition for the next wave of integrators and depositors, while retaining one strategic boost continues to reward core Aave ecosystem alignment. Frictionless onboarding. The introduction of the GhoRouter contract eliminates multi-step conversion friction. Users can go from USDC to sGHO in a single transaction, dramatically lowering the barrier to entry for new depositors and enabling seamless integration paths for partners. Market opportunity. With the Sky Savings Rate at 3.75% APR and broader DeFi yields compressed, a competitive fixed rate positions sGHO to absorb significant stablecoin demand. At the current sGHO deposit base of ~305M, incoming large allocations would compress the Merit-based yield from ~4.68% to approximately 3.70% at a deposit base of 385 M. Setting the native rate at 4.25% APR provides a clear premium over the competing sUSDS product while remaining sustainable within the DAO's revenue framework and other yield products in this rate environment. The ARFC: GHO Savings Upgrade established the technical foundation and passed Snapshot. This proposal now defines the launch parameters to operationalise that upgrade. sGHO (stkGHO) to sGHO (ERC4626) Transition The current sGHO implementation utilises stkGHO from Aave's Safety Module and periodic claimable rewards distributed via ACI's Merit program. The Merit program provides variable yields, consisting of a Base rate and a tiered boost system, to encourage specified types of behaviour. Details on the existing Boost campaigns are available on the ACI website at here. This proposal aligns the current sGHO (stkGHO) with the new sGHO (ERC 4626), adopting a Fixed Base Rate and consolidating the boosts from 8 to 1 (Stakoor) applied to both sGHOs (stkGHO and ERC 4626). In doing so, this shifts the current 275k/week spend to a variable amount subject to user deposits and boost application. Having aligned both sGHO (stkGHO) with the new sGHO (ERC 4626), to encourage migration, the existing sGHO (stkGHO) fixed rate will be less than the new sGHO (ERC 4626) rate. It will gradually decrease over three-week epochs until rewards are fully discontinued. The Stakoor boost shall be applied equally to each sGHO (stkGHO and ERC 4626) during the transition and then removed from sGHO (stkGHO) at sunset. Specification Architecture and Roles This section provides an overview of how the sGHO system comes together, the contracts, the administrative roles, and their interactions. !image sGHO Contract Architecture The upgraded sGHO is a single ERC-4626 compliant vault (upgradeable proxy pattern) audited by Certora and, more recently, by Sherlock. Key characteristics: Standard. Full ERC-4626 compliance with deposit, withdraw, mint, and redeem functions Yield mechanism. Internal index-based accounting, where a yieldIndex grows over time at a configured ratePerSecond. Yield accrues continuously and is reflected in the share-to-asset conversion rate Permit support. EIP-2612 gasless approvals via depositWithPermit() Pausable. All non-admin functions can be paused by the PAUSEGUARDIANROLE holder No rehypothecation. Deposited GHO remains in the contract. The DAO funds yield payouts separately from the Collector No cooldown. Atomic withdrawals, no lock-up period No slashing. No economic risk to assets held with sGHO contract. The sGHO Steward contract manages rate and supply cap parameters through a structured rate model with role-based access control. sGHO Steward Role Following the precedent set by the GHO Stewards ARFC, the sGHO Steward (GhoSghoSteward) enables responsive rate management without requiring full governance votes for every adjustment. The sGhoSteward can update the following parameters: Rate (fixedRate, floatRate): Set the target yield rate components Amplification factor: Adjust the amplification multiplier for the float rate Supply cap: Set the maximum deposits in the vault There is also a constraint on the Max Rate MAXSAFERATE = 5,000 bps (50% APR), enforced by the sGHO contract itself. Each of the above sGhoSteward influenced parameters is only callable by the following SAFE Address referred to as Gho Steward: Gho Steward: 0x8513e6F37dBc52De87b166980Fa3F50639694B60 Deployment status: Contracts have been audited and merged, and are scheduled for deployment soon. Deployment addresses will be confirmed in the AIP. Full implementation: github.com/aave-dao/gho-origin/pull/29 sGHO Rate Governance The GHO Stewards, a 3-of-4 multi-sig of Aave service providers already operational for GHO parameter management, will govern the sGHO rate. The sGHO Steward contract enforces the following role structure: | Role | Holder | Permissions | | --- | --- | --- | | YIELDMANAGERROLE | GHO Steward | Set target rate directly on the vault | | AMPLIFICATIONMANAGERROLE | Gho Steward | Adjust amplification factor | | FLOATRATEMANAGER_ROLE | Gho Steward | Adjust float rate component | | FIXEDRATEMANAGER_ROLE | Gho Steward | Adjust fixed rate component | | SUPPLYCAPMANAGER_ROLE | Gho Steward | Set vault supply cap | | PAUSEGUARDIANROLE | Aave Protocol Guardian | Emergency pause/unpause | Aave Protocol Guardian: 0x2CFe3ec4d5a6811f4B8067F0DE7e47DfA938Aa30 Rate adjustments will be discretionary, informed by GHO growth metrics, prevailing market conditions, and demand for sGHO. All rate changes will be documented on the governance forum. GhoRouter !image Alongside the sGHO vault, the GhoRouter contract (PR #34) provides a stateless routing layer that collapses multi-step conversions into single transactions. Without the router, converting USDC to sGHO requires three separate operations: (1) deposit USDC into stataUSDC, (2) sell stataUSDC on the GSM for GHO, (3) deposit GHO into sGHO. The router handles this entire flow atomically. Supported flows: | Flow | Input | Output | Description | | --- | --- | --- | --- | | swapToGho | Underlying (e.g. USDC) or stataToken | GHO | Convert any supported asset to GHO via GSM in one call | | swapFromGho | GHO | Underlying or stataToken | Convert GHO to any supported asset via GSM | | swapToSGho | Underlying or stataToken | sGHO | Full USDC-to-sGHO in one transaction (GSM + vault deposit) | | depositForSGho | GHO | sGHO | Direct GHO-to-sGHO deposit (no GSM needed) | | swapFromSGho | sGHO | Underlying or stataToken | Full sGHO-to-USDC in one transaction (vault redeem + GSM) | | redeemSGho | sGHO | GHO | Direct sGHO-to-GHO redemption (no GSM needed) | Key properties: Stateless. The router never holds user funds between transactions. Tokens are pulled, routed, and forwarded to the recipient atomically Slippage protection. Every flow includes a minAmount parameter; transactions revert with SlippageExceeded if output falls below the threshold Partial fill handling. If the GSM cannot consume all input, the remainder is returned to the caller GSM allowlist. The router owner curates which GSMs can be used, with validation on enablement (contract existence, correct GHO token, valid underlying) Preview functions. All six flows have a corresponding view preview function for gas-free output estimation The GhoRouter is a critical UX improvement for the sGHO launch. Eliminating conversion frictions, centralised exchanges and DeFi protocols to offer one-click sGHO entry and exit, significantly lowering the integration barrier. Full implementation: github.com/aave-dao/gho-origin/pull/34 --- Initial Rate Configuration sGHO | Parameter | Value | | --- | --- | | Target Rate (ASR) | 4.25% APR (425 basis points) | | Rate Type | Fixed | | Sky Savings Rate (reference) | 3.75% APR | | Premium over SSR | 50 basis points | | Steward Formula | amplification = 0, floatRate = 0, fixedRate = 425 | | Maximum Rate (contract cap) | 50% APR (5,000 bps) | The fixed rate is achieved by setting amplification = 0 and floatRate = 0 on the sGHO Steward, making the ASR equal to the fixedRate parameter alone. This eliminates dependency on any external index rate and provides predictability for depositors and integrators. Rationale for 4.25% APR: Positions sGHO 50 bps above the Sky Savings Rate (3.75%), providing a competitive premium while remaining sustainable as sGHO deposits grow with incoming large allocations Provides a clear incentive for migration from the legacy sGHO contract to the new ERC-4626 vault Maximises demand absorption in the current low-rate environment to accelerate GHO supply growth The fixed nature simplifies integration for centralised exchanges and DeFi protocols Gho Steward Constraints The sGHO contract enforces a maximum rate of 5,000 bps (50% APR) via MAXSAFERATE. Beyond this hard cap, the sGhoSteward imposes no additional on-chain constraints on rate adjustments. The GHO Stewards are expected to exercise prudent discretion when updating parameters, guided by market conditions and GHO growth metrics. --- Merit Configuration Update sGHO (rebranded stkGHO) The current sGHO (stkGHO) consists of a fixed weekly budget of 275k, a variable Base rate, and eight (8) boost multipliers. Upon implementation of this proposal, the eight (8) boost multipliers are reduced to one (1) -- Stakoor -- and the variable base rate is converted to a fixed rate at a 50 bps discount to the new sGHO (3.75% APR). The discount is then increased over time until Day 43, when rewards are discontinued. | Instance of sGHO | Current | Proposed | | --- | --- | --- | | sGHO (stkGHO) | Variable derived from fixed budget with eight (8) boosts | 3.75% Fixed Rate + One (1) boost (Stakoor) | | sGHO (ERC4626) | NA | 4.25% Fixed Rate + One (1) boost (Stakoor) | stkGHO Fixed Base Rate Discount and Boost Schedule | Phase | Duration | New sGHO (ERC-4626) | Legacy sGHO | Differential | | --- | --- | --- | --- | --- | | Phase 1: Grace period | Weeks 1-3 | 4.25% APR (native) | 3.75% APR (fixed) | -50 bps | | Phase 2: Accelerated Migration | Weeks 4-6 | 4.25% APR (native) | 3.25% APR (fixed) | -100 bps | | Phase 3: Full sunset | Week 7+ | 4.25% APR (native) | 0% (rewards terminated) | N/A | | sGHO (stkGHO) | Current | AIP Execution to Day 21 | Day 22 to 42 | From Day 43 | | --- | --- | --- | --- | --- | | Discount Schedule | NA | -50 bps | -100 bps | Cease rewards | | Boost Schedule | 8 | 1 (Stakoor) | 1 (Stakoor) | 0 | Transitional Boost A single boost is retained on a transitional basis as a supplementary top-up distributed via Merkl, separate from the native ERC-4626 rate. This boost will be phased out as the native rate matures and sGHO adoption stabilises, with the timeline aligned to the broader transition away from off-chain reward infrastructure. | Boost | Value | Criteria | | --- | --- | --- | | Stakoor | 5% | Hold stkAAVE on Ethereum (minimum threshold applied to exclude dust accounts; threshold not disclosed to prevent gaming) | The Stakoor boost is retained because it directly rewards long-term AAVE staking, a behaviour that strengthens the Aave ecosystem's security layer. The long-term objective is for the native sGHO rate to be the sole yield mechanism, with no dependence on off-chain boost infrastructure, and for AAVE/stkAAVE holders to receive preferential borrow rates on Aave v4. The Aavenger boost (which uses AAVE as collateral) has been sunset because it creates an incentive to borrow GHO against AAVE collateral and deposit it into sGHO, effectively subsidising a rate arbitrage loop. Boosts Removed The yield previously allocated to these boosts is absorbed into the native sGHO base rate: | Boost | Value | Criteria (for reference) | | --- | --- | --- | | Aavenger | 5% | Use AAVE as collateral on Ethereum | | Second-degree user of aligned protocol | 5% | DeFi Saver and Den users | | ETH Maxi | 5% | Supply wETH on Ethereum, Lido, Arbitrum, or Base instances | | Holdooor | 5% | Hold AAVE for 100+ days in the past year on Ethereum | | Staker | 5% | Stake AAVE or StkBPT on Ethereum | | Active in Governance | 10% | Vote or delegate to an Aave DAO recognized delegate platform | | Aave Aligned Frens | 5% | Boost for specific addresses/protocols defined by Aave DAO (currently InfiniFi and Gate.io) | Migration There is no atomic migration contract. Users holding legacy sGHO will need to withdraw GHO from the legacy sGHO contract and deposit it into the new ERC-4626 sGHO vault. The migration schedule is defined in the Merit Configuration Update section above. The three-phase, ~7-week schedule with 3-week epochs provides a grace period for large depositors and integrators to coordinate their migration, followed by an accelerated incentive to complete the transition. Beyond the rate differential, migration is further incentivised by: Composability: ERC-4626 standard enables integration across the DeFi ecosystem Simplified UX: No weekly claims through Merkl for the base rate; yield accrues automatically GhoRouter: One-click entry from USDC/stataTokens directly into the new sGHO Integration Opportunities The ERC-4626 standard unlocks significant new distribution channels for GHO: Centralised exchanges: Simplified earn programs where yield is transparently reflected in the share price, requiring no custom integration logic Stablecoin backing: Other stablecoin protocols can use sGHO as yield-bearing reserve collateral DeFi protocols: Native integration with lending protocols (Fluid), yield tokenisation (Pendle), and aggregators that support the ERC-4626 standard Cross-chain deployment: The standardised interface enables consistent sGHO deployments across chains Security The sGHO contract and sGHO Steward have undergone extensive review: Certora audit (September 9, 2025): Dedicated sGHO audit covering the vault and steward contracts Sherlock audit: Independent security review (PR #35) Precision analysis: Documented in the repository, confirming near-zero precision loss in yield calculations and overflow safety for the yieldIndex at maximum rate for 100+ years Legacy audits: The GHO protocol has been audited 12 times by OpenZeppelin, Sigma Prime, ABDK, Certora, and Emanuele Ricci since 2022 All audit reports are available in the gho-origin repository. Summary of Parameters | Parameter | Value | | --- | --- | | ASR (initial) | 4.25% APR (fixed) | | Steward Amplification | 0 | | Steward Float Rate | 0 | | Steward Fixed Rate | 425 bps | | Supply Cap | 400,000,000 | | Boosts Retained | Stakoor (5%) -- transitional, to be phased out | | Boosts Removed | 7 campaigns including Aavenger (yield folded into base rate) | | Aave Finance Steward Allowance | 10M GHO | | Rate Governance | GHO Stewards (existing multi-sig) | | Pause Guardian | Dedicated Safe (same config as GHO Steward) | | Migration | 3-phase, ~7-week schedule with 3-week epochs (legacy: 3.75% -> 3.25% -> 0%) | Disclosure TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Next Steps 1. Gather feedback from the community. 2. If consensus is reached on this ARFC, escalate this proposal to the Snapshot stage. 3. If the snapshot outcome is YAE, escalate this proposal to the AIP stage. Copyright Copyright and related rights waived via CC0.

Summary This publication proposes updates to the Budget SAFE signer configuration to improve transaction execution reliability, signer availability, and operational efficiency. Motivation As the operational scope and financial responsibilities of the Aave ecosystem continue to expand, ensuring timely and reliable transaction execution across SAFEs is critical. The current Budget Allocation SAFEs configuration has experienced occasional friction due to constraints on signer availability. Given the financial nature of transactions executed through these SAFEs, improving execution throughput while maintaining appropriate security standards is a priority. To address this, the proposed changes aim to: Increase signer redundancy to reduce execution delays Maintain a secure but more flexible approval threshold Reflect updated team compositions across service providers Improve overall signability of transactions through a more optimistic governance structure Transitioning from a 3-of-4 to a 3-of-5 signer configuration increases redundancy without increasing the execution threshold, thereby enhancing operational efficiency while preserving security guarantees. Rationale for Configuration Change Increasing the signer count improves availability and reduces the likelihood of blocked transactions Maintaining a 3-signature threshold preserves a strong security standard while enabling faster coordination Financial operations benefit from a slightly more optimistic governance model, where execution speed is balanced with appropriate oversight Updated signer composition better reflects active contributors and current service provider responsibilities Update The 2k GHO monthly retainer for @Figue, who has been supporting the ALC budget, stopped at the end of 2025. We would like to thank Figue for his contributions to the ALC. Specification The following updates are proposed for the Budget SAFE: !TokenLogic signers.png Budget Allocation SAFEs Update signer threshold: - From 3 of 4 → 3 of 5 General Signer updates: - Replace Barry (Chaos Labs) with Flavio (Chaos Labs) - Replace Val (Llama Risk) with Aidar (Llama Risk) - Add Emile (TokenLogic) as a new signer Resulting Configuration Total Signers: 5 Threshold: 3 signatures required for execution Next Steps 1. Gather feedback from the community 2. If consensus is reached, escalate this proposal to Snapshot 3. If the Snapshot outcome is YAE, TokenLogic will proceed with implementation Disclaimer TokenLogic is an active service provider to the Aave DAO, the beneficiary of stream 100072 and the KPI as outlined in this publication. The scope of this engagement is available via this forum proposal. TokenLogic supports and maintains an independent delegate voting platform within the Aave community. TokenLogic and associated entities have no undisclosed material conflicts of interest at the time of submission. Copyright Copyright and related rights waived via CC0.

[ARFC] Aave V4 Licensing Summary This proposal introduces a two-part licensing framework for the canonical Aave V4 repositories: a BUSL-based license for the core codebase, and a Contributor License Agreement (CLA) for anyone who wants to contribute to the codebase. The goal is to put in place a framework that is clear, consistent, enforceable, and fair to contributors. Together, these two elements would create a transparent foundation for how V4 is developed and shared going forward. Motivation V4 represents one of the most significant innovations for the protocol to date. Its modular architecture is designed to set the foundations for continuous expansion, and will enable the protocol to evolve over time while maintaining the path for community contributions. The proposed approach follows the same core principle used for V3 under BUSL: protect the codebase for a defined period, then transition to open source automatically. With V4, the goal is the same, but with a couple of improvements suggested for the implementation. Today, the community is preparing for the production release and the finalisation of the governance-aligned licensing framework. In line with the V4 development proposals, the intention is to migrate the V4 canonical repository under DAO ownership, with the full licensing package and CLA published for the community. This proposal introduces a couple of practical improvements to make that model more robust and clear to the community. First, contributions. V4 is intentionally more extensible, and we expect more contributions from service providers and community builders. The proposed CLA brings those contributions under the same licensing framework as the core codebase. This keeps the repository licensing coherent and avoids fragmentation as the ecosystem grows. Second, clarity. The V4 repository uses SPDX license identifiers at the file level rather than applying a single license across the entire codebase. We are looking to restructure the repository so that each file will include a simple header indicating its license using SPDX identifiers, with the full license texts stored in a /licenses folder in the repository. This makes it easy to follow which license applies to which part of the code. This structure also aligns well with possibilities that come with the modular Hub and Spoke architecture of V4. Together, these improvements are designed to make the V4 licensing framework clearer, more resilient, and better aligned with the community and how the protocol will evolve. Specification BUSL-based repository license (Aave V4 core) Please review the proposed text here: BUSLLICENSE The V4 core repository will be licensed under BUSL, consistent with the approach taken for V3 BUSL implementation, with these clarifications: DAO Ownership. Aave DAO is the owner of the canonical Aave V4 codebase and the associated intellectual property rights. During the development and deployment phases of Aave V4, Aave Labs has held the relevant copyright and licensing authority to protect and administer those rights on behalf of the Aave DAO while the governance-aligned licensing framework is finalised and the Aave DAO legal structure is built. Restriction design. V4 BUSL inherits the broad principles of the earlier BUSL restriction framework defined by the community, but with change in how those restrictions are phrased. V3’s language leaned on outcome-based concepts, things like “harm” or “migration”, which we think shifts the burden of proof in an unhelpful direction. V4 BUSL approach would improve the approach by reframing the underlying restrictions in conduct-based terms: what was deployed, where, and for what purpose, because it would make it far easier to act on in practice. Change Date. Consistent with the BUSL, the codebase transitions automatically to a permissive open-source license on the Change Date. That mechanism is unchanged from V3 BUSL. We suggest that the Change Date occurs within 5 years from the date of deployment of Aave V4 or earlier as recorded in a designated changedate text record. Scope note on architecture. This license governs the canonical repository and derivatives under copyright doctrine. Custom deployments that don’t incorporate or derive from the canonical repository code are not intended to fall within its scope. Aave V4 Contributor License Agreement (CLA) Please review the proposed text here: CLALICENSE Any contributor to the canonical V4 repository will be asked to accept the CLA. The CLA is a license, not a transfer of ownership. Contributors are not handing their rights over, instead, they’re granting the community a consistent, irrevocable right to use, incorporate, and sublicense their contribution as part of the canonical codebase. This matters because, without a CLA, contributions sit in an ambiguous space: the community may not have a clear, enforceable right to the code it’s building on. The CLA just formalises what should be common sense, and ensures the licensing framework applies consistently across the entire repository. Voting Option YAE NAY Abstain Copyright Copyright and related rights waived via CC0.