[TEMP CHECK] Deploy Aave V4 on Avalanche
Vote Result: YES
Rationale
This proposal seeks community feedback on deploying Aave V4 on Avalanche, including a dedicated RWA hub, as a Temp Check ahead of a formal ARFC. Avalanche already hosts an active Aave market with established user familiarity, and the $15M incentive commitment tied to growth KPIs provides a credible, low-risk catalyst to accelerate V4 adoption outside Ethereum. Therefore, we are voting FOR this proposal.
[TEMP CHECK] Babylon Trustless BTC Vault Integration on Aave V
Vote Result: YES
Rationale
This proposal seeks community feedback on deploying two new Aave V4 Spokes, the Babylon Core Lending Spoke and BTC Vault Swap Spoke, to onboard native BTC as collateral through Babylon’s trustless, non-custodial Trustless Bitcoin Vaults protocol. The integration leverages peer-reviewed cryptography and V4’s isolated Hub-and-Spoke architecture to add a genuinely trustless BTC collateral primitive while preserving full Aave DAO control over risk parameters and caps, with detailed risk and audit review still to follow at the ARFC stage. Therefore, we are voting FOR this proposal.
[Temp Check] Deploy Aave V4 on Arc
Vote Result: YES
Rationale
This proposal seeks community feedback on deploying Aave V4 on Arc, Circle’s institutional-grade layer-1 built for stablecoin and real-world asset liquidity, alongside an initial asset set of USDC, EURC, and cirBTC. Launching at or near mainnet positions Aave as core lending infrastructure for regulated institutional liquidity flows, with a guaranteed minimum $2M annual revenue backstop for the first five years de-risking the bootstrap phase. Therefore, we are voting FOR this proposal.
stkAAVE Emissions Update
Vote Result: YES
Rationale
This proposal seeks to reduce stkAAVE emissions from 220 AAVE/day to 150 AAVE/day, targeting a staking APR of approximately 2.75% rather than the current upward trend toward ~3.93%. We had voted in support of this proposal during the temp-check phase and our position has remained unchanged. Therefore, we are voting FOR this proposal.
[ARFC] June - Update Signers and SAFE Configuration
Vote Result: YES
Rationale
This proposal seeks to refresh the signer composition of Aave’s seven budget/asset-holding SAFEs and upgrade each to a 2-of-3 structure where every signer is an independent, organisation-controlled Nested SAFE. This architecture strengthens treasury security and reduces OpSec risks, while consolidating signers sensibly as the service provider roster shrinks. Therefore, we are voting FOR this proposal.
[ARFC] Launch remoteGSM on Arbitrum
Vote Result: YES
Rationale
This proposal seeks to deploy a stataUSDC remoteGSM on Arbitrum, along with a GhoReserve, updated CCIP bridge limits, and an extended GhoGsmSteward, minting and bridging 50M GHO to establish a local peg anchor ahead of the sGHO launch. This replicates the proven, capital-efficient Plasma remoteGSM playbook, which reached its full 40M cap and now represents over 13% of GHO’s circulating supply, using a conservative 20M starting cap on Arbitrum. Therefore, we are voting FOR this proposal.
May/June 2026 Funding Update
Vote Result: YES
Rationale
This proposal seeks to execute the May/June Funding Update, covering idle ETH deposits, refreshed MainnetSwapSteward and AFC allowances to support GHO acquisition and runway, a new incentive allowance for the Tydro campaign, and payouts for bug bounties and audit reimbursements. These are routine operational maintenance items consistent with established DAO processes and prior funding strategies, with clear specifications and reasonable amounts. Therefore, we are voting FOR this proposal.
Onboard PT-sUSDe-22OCT2026 to Aave v3 Plasma
Vote Result: YES
Rationale
This proposal seeks to onboard PT-sUSDe-22OCT2026 as a collateral asset on the Aave V3 Plasma Instance. This listing provides a natural rollover destination for existing PT-sUSDe-18JUN2026 holders ahead of that maturity’s expiry, and uses conservative, non-borrowable risk parameters with capped supply consistent with the established sUSDe E-Mode framework and pricing methodology already in use on Plasma. Therefore, we are voting FOR this proposal.
Monad aDI path activation
Vote Result: YES
Rationale
This proposal seeks to register the necessary Ethereum-to-Monad a.DI bridge adapters (CCIP, Hyperlane, and LayerZero) on the Ethereum Cross-chain Controller, a technical pre-requirement for enabling the Aave V3 Monad activation vote. This is a straightforward, low-risk infrastructure step using a 2-of-3 confirmation threshold across multiple independent bridge providers, consistent with standard a.DI deployment practice for prior network expansions. Therefore, we are voting FOR this proposal.
Onboard PT-srUSDe-22OCT2026 to Aave V3 Core
Vote Result: YES
Rationale
This proposal seeks to onboard PT-srUSDe-22OCT2026 as a collateral asset on the Aave V3 Core Instance on Ethereum. This listing provides a natural rollover destination for existing PT-srUSDe-25JUN2026 holders ahead of that maturity’s expiry, and applies conservative, non-borrowable risk parameters consistent with the established PT-srUSDe E-Mode framework and dynamic linear discount rate pricing already used for similar assets. Therefore, we are voting FOR this proposal.
[ARFC] Deploy Aave Protocol on Monad
Vote Result: YES
Rationale
This proposal seeks to deploy Aave Protocol v3.7 on the Monad Network, including full risk parameters, four e-modes, GHO stewards and lanes, a stataUSDT0 remoteGSM, and a 50M GHO mint-and-bridge. Monad’s EVM-compatible, high-throughput architecture offers straightforward integration for existing Ethereum builders, and the deployment is backed by a substantial $15M incentives package plus sustained GHO acquisition from the Monad Foundation, giving Aave a well-supported entry into a new high-performance ecosystem. Therefore, we are voting FOR this proposal.
[ARFC] Strengthening Upgrade Safety: Concord Equivalence Checker by Certora
Vote Result: YES
Rationale
This proposal seeks Aave DAO participation as a founding sponsor, contributing $50,000, in the development of Certora Concord, an open-source equivalence-checking framework to formally verify that smart contract upgrades preserve protocol behavior. The modest contribution unlocks matching Ethereum Foundation funding and shared development costs across leading protocols, offering Aave meaningful upgrade safety guarantees and reduced audit overhead at low cost relative to the protocol’s complexity and upgrade cadence. Therefore, we are voting FOR this proposal.
[ARFC] Onboard stcUSD to Aave V3 MegaETH
Vote Result: YES
Rationale
This proposal seeks to onboard stcUSD, the staked, yield-bearing component of Cap Protocol, as a collateral asset to the Aave V3 MegaETH market via an isolated Stablecoin E-Mode. The listing is backed by a completed LlamaRisk risk assessment, uses conservative parameters including a capped supply and isolated E-Mode configuration, and adds incremental stablecoin borrow demand that benefits the broader MegaETH instance. Therefore, we are voting FOR this proposal.
Launch of V4 Paxos Hub and onboard PT-USDG-24SEP2026
Vote Result: YES
Rationale
This proposal seeks to onboard PT-USDG-24SEP2026 to Aave V4 on Ethereum via a dedicated Paxos Hub and correlated USDG Pendle spoke, and to migrate the USDG price reference from a fixed $1.00 feed to a capped live Chainlink feed. The dedicated hub provides clean risk isolation from other stablecoin ecosystems while the correlated asset grouping supports tighter collateral factors, and moving to a capped market-responsive oracle improves downside liquidation responsiveness while still bounding upside risk, consistent with the standard already used for USDC, USDT, and RLUSD. Therefore, we are voting FOR this proposal.
TokenLogic Service Provider Renewal
Vote Result: YES
Rationale
This proposal seeks to renew and expand TokenLogic’s Service Provider mandate, formalizing its expanded responsibilities across finances, market structure, GHO, tooling, liquidation engine support, and Aave V4 feature development, alongside replacing its expiring GHO stream with a new 2.5M GHO and 5,000 AAVE stream over 365 days. We had voted in support of this proposal during the offchain vote and our position has remained unchanged. Therefore, we are voting FOR this proposal.
[ARFC] Umbrella Parameter Update: Target Liquidity and Emission Optimization
Vote Result: YES
Rationale
This proposal seeks to recalibrate Umbrella’s Target Liquidity and emission configurations for the USDC, USDT, and WETH markets while sunsetting the GHO Umbrella market and shifting future GHO deficit responsibility to the DAO Treasury, alongside a temporary increase to the GHO Deficit Offset to protect existing stakers. These adjustments are well justified by a 43% decline in active loan volumes, materially improved collateral quality, and substantially larger Deficit Offsets since launch, and the changes deliver approximately $4.84 million (59%) in annual emissions savings while preserving adequate protocol protection. Therefore, we are voting FOR this proposal.
[ARFC] Risk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment
Vote Result: YES
Rationale
This proposal seeks to reduce the Risk Steward minDelay from 72 to 36 hours on seven cap and IRM parameters, and to reassign Umbrella’s stkToken pause/unpause authority from the Aave Governance Executor to the Aave Protocol Guardian. Both changes address concrete operational friction observed during recent incident response, restore Umbrella’s originally specified role assignment, and improve response speed without weakening any maxPercentChange safety bounds or shifting configuration authority away from governance. Therefore, we are voting FOR this proposal.
GHO Monad Activation
Vote Result: YES
Rationale
This proposal seeks to activate CCIP Lanes for GHO on the Monad blockchain, deploying the necessary GhoToken, GhoTokenPool, and steward contracts alongside the planned Aave instance launch on Monad. Deploying GHO concurrently with Aave on Monad positions the stablecoin to become foundational to the ecosystem from inception, and the configuration uses conservative and established rate limits consistent with prior cross-chain GHO deployments. Therefore, we are voting FOR this proposal.
Update USDG Price Feed on Aave V3 Instances
Vote Result: YES
Rationale
This proposal seeks to replace the existing USDG price feed on the Aave V3 Ethereum Core and X Layer instances, including the expired PT-USDG-28MAY2026 asset, with a price cap adapter capped at 1.04 using the Chainlink USDG feed as the underlying source. This follows LlamaRisk’s assessment that Chainlink now offers higher-quality pricing than the current source, and applies the same capped-adapter standard already used elsewhere across the protocol, improving pricing accuracy while bounding upside risk. Therefore, we are voting FOR this proposal.
Certora Concord Equivalence Checker Funding
Vote Result: YES
Rationale
This proposal seeks Aave DAO participation as a founding sponsor, contributing $50,000, in the development of Certora Concord, an open-source equivalence-checking framework to formally verify that smart contract upgrades preserve protocol behavior. We had voted in support of this proposal during the offchain vote and our position has remained unchanged. We will therefore vote FOR this proposal.
[ARFC] Upgrade PT Risk Oracle to Protocol-Owned Infrastructure on CRE
Vote Result: YES
Rationale
This proposal seeks to upgrade Aave’s Pendle PT risk oracle stack to a protocol-owned, automated pipeline using Chainlink CRE workflows, replacing LlamaRisk’s manual, opaque interim process with an onchain, auditable system while keeping the existing discount-rate methodology, agent architecture, and Aave Governance’s contract ownership unchanged. This closes a real transparency and key-person risk gap left after Chaos Labs’ departure, and the atomic router design with unchanged safety checks preserves execution guarantees while improving verifiability. Therefore, we are voting FOR this proposal.
Aave V3.7 Monad Activation
Vote Result: YES
Rationale
This proposal seeks to activate the Aave V3.7 Monad pool by listing twelve initial assets with detailed risk parameters, e-mode categories, and Chainlink-based oracle configurations, following the completed governance approval and Risk Service Provider recommendations. The parameters are conservative and well-structured, using appropriate CAPO adapters for correlated and stable assets, capped growth rates, and disabled borrowing on higher-risk collateral, consistent with the previously approved Monad deployment plan. Therefore, we are voting FOR this proposal.
Onboard stcUSD to Aave V3 MegaEth
Vote Result: YES
Rationale
This proposal seeks to onboard stcUSD, Cap Protocol’s yield-bearing token, to the Aave V3 MegaETH instance with collateral use restricted to a dedicated isolated E-Mode for borrowing USDT0 and USDm. The conservative configuration, including a 10 million supply cap, non-borrowable status, restricted collateral eligibility, and a dedicated CAPO oracle, provides appropriate safeguards while enabling additional borrowing demand and stablecoin liquidity on MegaETH. Therefore, we are voting FOR this proposal.
Grant Claim Helper Role to StkGhoMigrator
Vote Result: YES
Rationale
This proposal seeks to introduce a migration helper contract that allows users to migrate their stkGHO deposits into the new ERC-4626-compliant sGHO vault through a single flow in the Aave UI. The helper simplifies the migration process by bundling the required cooldown, redemption, approval, and deposit steps while limiting its permissions to the CLAIM_HELPER_ROLE on stkGHO. Therefore, we are voting FOR this proposal.
[ARFC] Aave Risk Framework
Vote Result: YES
Rationale
This proposal seeks to establish a comprehensive risk framework governing assets, bridges, monitoring systems, and chains across Aave V3, V4, and Horizon. The framework strengthens Aave’s risk management through standardized due diligence, continuous monitoring, automated defensive mechanisms, defined deprecation triggers, and clear hard-block conditions, providing a more consistent approach to managing protocol-wide exposure. Therefore, we are voting FOR this proposal.
[ARFC] Launch sGHO Cross-Chain
Vote Result: YES
Rationale
This proposal seeks to extend sGHO to Layer 2 networks, initially Arbitrum, through a cross-chain architecture using a single Ethereum mainnet vault and Chainlink CCIP. The Fast and Slow paths provide flexible cross-chain access while consolidating accounting and liquidity in a single vault, supporting Aave App and other integrations without fragmenting GHO backing across networks. Therefore, we are voting FOR this proposal.
[ARFC] Deploy Aave V4 on Avalanche
Vote Result: YES
Rationale
This proposal seeks to deploy Aave Protocol V4 on Avalanche through a Liquidity Hub and three specialized Spokes, with a dedicated RWA Hub planned for a later phase. The deployment builds on Aave’s established presence on Avalanche, while the proposed risk parameters, exposure caps, and up to $15 million in milestone-based incentives provide a measured framework for V4 expansion. Therefore, we are voting FOR this proposal.
[TEMP CHECK] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP
Vote Result: YES
Rationale
This proposal seeks to deploy a dedicated, EtherFi-operated Aave V4 hub on OP Mainnet to replace EtherFi Cash’s existing bespoke lending market. The isolated and whitelisted structure limits Aave’s direct risk while providing the DAO with revenue share, substantial committed liquidity, GHO integration, and exclusive access to EtherFi Cash’s growing on-chain activity. Therefore, we are voting FOR this proposal.
[ARFC] Technical Asset Listing Framework
Vote Result: YES
Rationale
This proposal seeks to establish a standardized Technical Asset Listing Framework for assets listed or seeking to be listed on Aave V3, Aave V4, and Horizon. The framework improves consistency and transparency in technical due diligence by establishing clear requirements across token architecture, access controls, oracles, bridges, audits, and ongoing monitoring, while complementing existing risk assessment frameworks. Therefore, we are voting FOR this proposal.
Aave V4 Avalanche Activation
Vote Result: YES
Rationale
This proposal seeks to activate Aave Protocol V4 on Avalanche through a Core Hub with dedicated Main, AVAX Correlated, Forex, and tokenization Spokes. The deployment builds on Aave’s established presence on Avalanche while using conservative risk parameters, spoke-specific exposure caps, and differentiated market structures to manage risk during the initial V4 expansion. Therefore, we are voting FOR this proposal.
Remote GSM Launch: Arbitrum
Vote Result: YES
Rationale
This proposal seeks to launch a GHO GSM on Arbitrum using the RemoteGSM architecture, including minting and bridging 50 million GHO to seed the local GhoReserve and standardizing GHO CCIP lane capacity across supported networks. The deployment expands GHO’s stability infrastructure to Arbitrum while maintaining defined reserve and exposure limits and retaining DAO control over GHO minting and cross-chain transfers. Therefore, we are voting FOR this proposal.
Aave V3 LTV and E-Mode Update
Vote Result: YES
Rationale
This proposal seeks to adjust LTV and E-Mode parameters across several Aave V3 markets and restore wstETH borrow caps on Ethereum Core and Prime. The changes reduce collateral exposure where liquidity or utilization does not justify existing parameters, while introducing a dedicated WMNT stablecoin E-Mode and restoring wstETH borrowing capacity following the resolution of the prior oracle issue. Therefore, we are voting FOR this proposal.
[ARFC] Onboard syrupUSDC to Aave V3 Core Instance
Vote Result: YES
Rationale
This proposal seeks to onboard syrupUSDC, a yield-bearing token backed by Maple Finance’s institutional fixed-rate lending strategies, as collateral on the Aave V3 Core Instance. The listing could attract significant institutional liquidity, improve USDC utilization and rates, and support GHO adoption, while conservative supply limits and CAPO safeguards help manage the associated risks. Therefore, we are voting FOR this proposal.
[ARFC] Onboard USDai & sUSDai to Aave V3 Arbitrum Instance
Vote Result: YES
Rationale
This proposal seeks to onboard USDai and sUSDai on the Aave V3 Arbitrum instance, enabling users to supply and borrow these stable assets. The proposed listing provides Aave with exposure to an emerging AI infrastructure backed stablecoin ecosystem while applying conservative supply caps, isolated E-Mode configurations, and CAPO safeguards to manage associated risks. Therefore, we are voting FOR this proposal.
[ARFC] Aave App Launch
Vote Result: YES
Rationale
This proposal seeks to approve the initial configuration and launch of the Aave App, including Stable Vaults, Balance Protection, the RPUR framework, a launch campaign, and related bug bounty coverage. The initiative could significantly broaden Aave’s retail user base and create new revenue streams while routing net revenue to the DAO and leveraging Aave Protocol’s existing infrastructure. Therefore, we are voting FOR this proposal.
Umbrella Parameter Update: Target Liquidity and Emission Optimization
Vote Result: YES
Rationale
This proposal seeks to update Umbrella Target Liquidity and emission configurations for USDC, USDT, and WETH while sunsetting the GHO Umbrella market and transferring future GHO deficits to the DAO Treasury. The changes materially reduce annual incentive expenditure by approximately 59% while aligning coverage levels with lower protocol exposure, improved collateral quality, and increased deficit offsets, with higher WETH incentives supporting an underserved market. Therefore, we are voting FOR this proposal.
[Temp Check] Deploy Aave V4 on Tempo
Vote Result: YES
Rationale
This proposal seeks to gauge community support for deploying Aave V4 on Tempo Mainnet, a payments-focused Layer 1 designed for stablecoin and enterprise use cases. The deployment could expand Aave’s liquidity and revenue footprint, support GHO adoption, and access new enterprise-driven credit markets, while subsequent ARFC and AIP stages provide appropriate risk and technical review. Therefore, we are voting FOR this proposal.
[ARFC] Deploy a Dedicated Aave V4 Whitelabel Instance fully managed by EtherFi on OP Mainnet to Power Ether.fi Cash
Vote Result: YES
Rationale
This proposal seeks to deploy a dedicated EtherFi-operated Aave V4 hub on OP Mainnet to provide the credit backend for EtherFi Cash, replacing its existing bespoke Debt Manager. The isolated, borrow-whitelisted structure limits Aave’s operational risk while providing meaningful revenue potential, GHO integration, and committed liquidity, with independent risk administration and EtherFi’s exclusivity commitment further strengthening the proposal. Therefore, we are voting FOR this proposal.
[Direct to AIP] Onboard syrupUSDG on Aave V4 Global Dollar Hub
Vote Result: YES
Rationale
This proposal seeks to deploy a dedicated Maple Spoke on the Aave V4 Global Dollar Hub and onboard syrupUSDG as collateral. The proposed 10 million syrupUSDG cap, conservative collateral parameters, dynamic liquidation configuration, and capped oracle design provide appropriate safeguards while expanding the utility of USDG and supporting demand for yield-bearing institutional lending assets. Therefore, we are voting FOR this proposal.
Remote GSM Launch Monad
Vote Result: YES
Rationale
This proposal seeks to launch a USDC GHO GSM on Monad using the RemoteGSM architecture, including the minting and bridging of 50 million GHO to seed the Monad GhoReserve. The deployment extends GHO’s stability infrastructure to Monad while maintaining governance control over minting and bridging and applying defined reserve limits, exposure caps, and swap controls. Therefore, we are voting FOR this proposal.
[ARFC] Onboard PT-AUSD-8OCT2026 to Aave V3 Monad Instance
Vote Result: YES
Rationale
This proposal seeks to onboard PT-AUSD-8OCT2026, a short-dated Pendle Principal Token backed by AUSD, to the Aave V3 instance on Monad. The asset is supported by meaningful liquidity and an established underlying reserve, while the proposed conservative supply cap, risk parameters, E-Mode configuration, and dynamic discount rate oracle provide appropriate safeguards for its use as collateral. Therefore, we are voting FOR this proposal.
[ARFC] Governance Framework v2
Vote Result: YES
Rationale
This proposal seeks to replace Aave DAO’s Governance Process v1 with a consolidated Governance Process v2 that removes the mandatory TEMP CHECK stage, refreshes governance roles and mandates, and reduces the standard process from 19 days to 13 days. The revised framework improves governance efficiency while retaining appropriate community oversight through the ARFC, Snapshot, and on-chain voting stages and maintaining established risk and technical review standards. Therefore, we are voting FOR this proposal.
[ARFC] Low Adoption Asset Deprecation on Aave V3
Vote Result: YES
Rationale
This proposal seeks to offboard a broad set of low-activity Aave V3 reserves and six whole deployments by freezing them, reducing caps to 1, and raising reserve factors to wind down exposure in an orderly manner. Applying the Aave Risk Framework consistently to assets that no longer justify their operational load reduces the protocol’s risk surface, and the standardized wind-down mechanics minimize disruption to existing positions while curbing new activity. Therefore, we are voting FOR this proposal.
[ARFC] Oracle Deprecation for Long-tail Assets Across Aave V2 and V3
Vote Result: YES
Rationale
This proposal seeks to deprecate Chainlink price feeds for a set of long-tail, high-risk assets across multiple Aave V2 and V3 reserves by freezing the reserves, hardcoding oracle prices, and adjusting caps and interest rate parameters to wind down remaining positions in an orderly fashion. LlamaRisk’s per-asset analysis shows these markets have deteriorated to the point of unreliable pricing, and the proposed fixed-price adapters combined with rate incentives to encourage repayment mitigate manipulation risk without materially harming existing borrowers. Therefore, we are voting FOR this proposal.
[ARFC] GHO Stewards Signer Update
Vote Result: YES
Rationale
This proposal seeks to update the GHO Risk Council Safe’s signer set to a 2-of-3 configuration held by entity Safes from LlamaRisk, TokenLogic, and Aave Labs, replacing individual signer addresses. Moving to entity-owned signers improves continuity against individual personnel turnover, and requires no change to the Safe address or any on-chain Steward permissions. Therefore, we are voting FOR this proposal.
[ARFC] Deploy remoteGSM for GHO on X Layer
Vote Result: YES
Rationale
This proposal seeks to deploy a remote GSM for GHO on X Layer, bridging 25M GHO via CCIP and configuring the associated token pool, GSM, reserve, and steward parameters to support the token’s launch on the network. Bootstrapping GHO alongside the upcoming Aave deployment positions it as a foundational stablecoin on X Layer from inception, and the bucket capacity limits, GSM peg-defense bounds, and bounded steward permissions keep the initial exposure controlled. Therefore, we are voting FOR this proposal.
[ARFC] Onboard PAXG to the Global Dollar Hub in Aave V4 Ethereum
Vote Result: YES
Rationale
This proposal seeks to onboard Pax Gold (PAXG) as a collateral-only asset in a new Gold Spoke on the Aave V4 Ethereum Global Dollar Hub, alongside enabling native USDG borrowing on the Pendle Spoke. PAXG’s regulated, physically-backed structure introduces a non-correlated real-world asset that diversifies the Hub’s collateral base, and the conservative liquidation parameters, capped draw limits, and appropriate XAU/USD oracle configuration adequately address the asset’s distinct risk profile. Therefore, we are voting FOR this proposal.
[ARFC] Aave Governance Emergency Guardian: Signer Rotation
Vote Result: YES
Rationale
This proposal seeks to rotate the signer set of the Aave Governance Emergency Guardian while retaining its existing 5-of-9 threshold, permissions, and Safe addresses. Refreshing the signers reflects the DAO’s current stakeholder landscape and improves operational resilience, while withholding public attribution of identities reduces targeted security risks without changing the Guardian’s scope of authority. Therefore, we are voting FOR this proposal.
[ARFC] Liquidation Protocol Fee Increase for WBTC, WETH, and wstETH on Aave V3 Ethereum Core
Vote Result: YES
Rationale
This proposal seeks to raise the Liquidation Protocol Fee from 10% to 20% for WBTC, WETH, and wstETH on Aave V3 Ethereum Core. LlamaRisk’s extensive backtesting across 14,006 liquidations shows a material net revenue gain of $1.35M–$2.23M per year with no attributable bad debt, and limiting the change to these three deep, well-covered markets avoids shifting disproportionate risk onto thinner reserves. Therefore, we are voting FOR this proposal.
Maintenance: Grant AL RETRY_ROLE on a.DI (Part 1)
Vote Result: YES
Rationale
This proposal seeks to grant the Aave Labs multisig the RETRY_ROLE on a.DI across ten networks to support the retry and rerouting of previously sent governance messages. The role improves operational resilience and message delivery reliability without granting control over governance actions, while the additional Scroll and Metis guardian updates align their configurations with the standard a.DI setup. Therefore, we are voting FOR this proposal.
Risk Stewards Cooldown Reduction & Umbrella Pauser Role Reassignment
Vote Result: YES
Rationale
This proposal seeks to reduce the Risk Steward minimum delay from 72 hours to 36 hours for selected cap and interest rate parameters and reassign Umbrella pause and unpause authority to the Aave Protocol Guardian. The changes improve operational responsiveness during periods of elevated demand and incident response while retaining existing parameter change bounds and governance control over Umbrella configuration. Therefore, we are voting FOR this proposal.
July 2026 Funding Update
Vote Result: YES
Rationale
This proposal seeks to execute the July Funding Update, including GHO acquisition, treasury allowance updates, operational funding, audit cost reimbursement, liquidity support for GHO on Monad, hedging permissions, and Stable Vault incentives. The measures support Aave’s operational runway and growth initiatives while refreshing and consolidating allowances and funding previously approved strategic activities. Therefore, we are voting FOR this proposal.
Asset Listing - Pendle PT-AUSD Monad
Vote Result: YES
Rationale
This proposal seeks to list PT-USDG-29OCT2026 on Aave V3 X Layer as a non-borrowable collateral asset within two dedicated isolated eModes for stablecoin and USDG borrowing. The conservative configuration, including a 35 million supply cap, restricted collateral use, isolated eModes, and a dedicated linear discount oracle, provides appropriate safeguards while enabling fixed-yield USDG positions to be used as collateral. Therefore, we are voting FOR this proposal.
Onboard PT-srUSDe-22OCT2026 to the LlamaRisk PT Risk Oracle
Vote Result: YES
Rationale
This proposal seeks to register LlamaRisk’s predeployed discount rate and eMode risk agents on Aave’s AgentHub to automatically maintain risk parameters for PT-srUSDe-22OCT2026 within defined bounds. The use of Chainlink CRE and LlamaRisk’s RiskOracle, combined with conservative per-update limits, timelocks, and Protocol Guardian controls, provides a controlled mechanism for keeping parameters aligned with the asset’s evolving fair value while retaining governance oversight. Therefore, we are voting FOR this proposal.
[ARFC] Onboard cirBTC on Aave v3 Core and Aave V4 Core
Vote Result: YES
Rationale
This proposal seeks to onboard Circle Wrapped Bitcoin (cirBTC) as a collateral-enabled asset on both the Aave V3 Core and Aave V4 Core Instances on Ethereum. The regulated, 1:1 BTC-backed structure of cirBTC broadens Aave’s BTC-denominated collateral base and supports institutional borrowing demand, while conservative caps and Chainlink’s established BTC/USD feed keep the initial exposure well contained. Therefore, we are voting FOR this proposal.
[ARFC] Deploy Aave V4 on Arc
Vote Result: YES
Rationale
This proposal seeks to deploy Aave Protocol V4 on Arc Network with an initial Core Hub and two Spokes supporting USDC, EURC, WETH, and cirBTC, alongside a supply-only tokenized spoke layer. The launch parameters are conservatively calibrated with tight caps and phased expansion, and the deployment carries a revenue backstop from Arc ecosystem participants for the first five years, limiting downside while positioning Aave in institutional stablecoin liquidity flows. Therefore, we are voting FOR this proposal.
[ARFC] Activate Aave Risk Stewards on Aave V4
Vote Result: YES
Rationale
This proposal seeks to activate the Aave Risk Steward on the Aave V4 Ethereum and Aave V4 Avalanche instances, splitting each configurator’s domain admin role into five granular roles and granting the Risk Steward bounded, revocable authority to adjust Hub, Spoke, and Oracle risk parameters within defined cooldowns and caps. This extends a pattern already proven on Aave V3 to reduce governance overhead for routine parameter tuning, while the granular role split, fixed bounds, and ongoing Certora audit keep the delegated authority narrow and auditable. Therefore, we are voting FOR this proposal.