Aave V3 Aptos Activation
Vote Result: YES
Rationale
This is the onchain proposal for this Snapshot ARFC that we voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.
[TEMP CHECK] Onboard syrupUSDC to Aave V3 Core Instance
Vote Result: YES
Rationale
As we mentioned in our comment, we’re excited about syrupUSDC. The $500M of additional allocation into USDC/USDT is a significant boost to Aave’s TVL and the looping strategy by depositors should bring additional revenue to Aave. It’d be good to understand at the ARFC stage what the revenue projection actually is. The growth incentives are a cherry on top for the ecosystem. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Onboard USD1 to Aave V3 Core and BNB Instance
Vote Result: YES
Rationale
USD1 is a growing stablecoin and with Chainlink PoR natively enabled, seems to be safe enough from an asset-backing perspective. We’d be interested in seeing the risk analysis, especially from LlamaRisk, at the ARFC stage, as well as the incentives offered. Therefore, we will vote YES in favour of this proposal.
Onboard tETH to Aave v3 Prime Instance
Vote Result: YES
Rationale
This is the onchain proposal for this Snapshot ARFC that we voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.
Enable Additional SVR Oracles
Vote Result: YES
Rationale
Expanding SVR to 58.6% of the market size from a mere 2.6% is a big move and one we are in favour of. The metrics are on an upward trend; 2/3rd of the revenue has been captured in the last 30 days, while the recapture rate has increased significantly over the last month. The system has also shown no security issues yet. Therefore, we will vote YES in favour of this proposal.
[ARFC] stS Loop Incentive Program
Vote Result: YES
Rationale
The plan for the Incentive Program is very clear and there is an added benefit of Aave being the exclusive lending market for stS. A looping program is beneficial for Aave given the revenue it brings to the DAO. Therefore, we will vote YES in favour of this proposal.
Add EURC to Aave V3 Core Instance
Vote Result: YES
Rationale
EURC is issued by Circle and the reserves are subject to monthly attestations by a Big 4 accounting firm. We voted to onboard EURC onto Base and both risk service providers are in favour of this proposal. Therefore, we will vote YES in favour of this proposal.
Discount Rate Risk Oracle Activation and Update Manual AGRS
Vote Result: YES
Rationale
Extending the automated AGRS system to Pendle PT tokens is sensible and replicates the same infrastructure for other AGRS’. This will increase operational efficiency for risk parameter updates. Therefore, we will vote YES in favour of this proposal.
Aave v2 Non-Ethereum Pools Next Deprecation Steps
Vote Result: YES
Rationale
Completing the deprecation of v2 pools needs to take place and cleans house for the protocol. Therefore, we will vote YES in favour of this proposal.
[ARFC-Addendum] Update Merit for Round 18
Vote Result: YES
Rationale
Distributing rewards weekly now in sGHO is much more positive for Merit participants. Removing Diluters also is a good move now given how the market has evolved. Therefore, we will vote YES in favour of this proposal.
Upgrade Aave Instances to v3.4
Vote Result: YES
Rationale
This is the onchain proposal for this Snapshot ARFC that we voted in favour of according to our rationale here. Therefore, we will vote YES in favour of this proposal as well.
[ARFC] Update Signers and SAFE Configuration
Vote Result: YES
Rationale
This is an operational proposal that will enhance efficiency for the Aave Finance team and for ops across the DAO. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Onboard openUSDT to Aave V3 BOB Instance
Vote Result: YES
Rationale
oUSDT, led by Chainlink, provides an interoperable standard for USDT liquidity across chains and deepens stablecoin liquidity across chains. The BOB team considers it a strategic asset for the Aave launch and it is 1:1 backed with native USDT. Therefore, we will vote YES in favour of this proposal.
[TEMP CHECK] Onboard SolvBTC to Aave V3 BOB Instance
Vote Result: YES
Rationale
SolvBTC is a pretty established asset now with over 20k BTC in its reserves and deployed across >10 networks. SolvBTC also enables a lot of use cases with key assets like WBTC, potentially with looping strategies. The SolvBTC ecosystem also has numerous yield opportunities built on top of it which the BOB instance will benefit from. Therefore, we will vote YES in favour of this proposal as well.
[TEMP CHECK] Onboard xSolvBTC to Aave V3 BOB Instance
Vote Result: YES
Rationale
xSolvBTC will provide multiple use cases on Aave, especially against SolvBTC, including yield opportunities. The asset is relatively mature with 10k xSolvBTC being minted. Therefore, we will vote YES in favour of this proposal.
is there any update on your more recent voting partecipation?
Vote Rationales - February 2026
[ARFC] Deploy Aave V3 to MegaETH
Vote Result: YES
Rationale
This proposal seeks to deploy Aave V3 on MegaETH at mainnet launch with risk-parameterized listings and either a points incentive program or revenue guarantee structure. Early deployment with guaranteed minimum revenue helps reduce downside risk while positioning the protocol to capture early network activity and growth opportunities. Therefore, we are voting FOR on this proposal.
MKR and USDtb oracle adjustments
Vote Result: YES
Rationale
This proposal seeks to replace the MKR price feed on Aave v3 Ethereum Core with one derived from the SKY/USD Chainlink feed and the on-chain MKR-to-SKY migration contract, and to set the USDtb price feed to a static 1 USD. Given the declining secondary liquidity for MKR during its migration to SKY and the fixed on-chain conversion rate, this approach strengthens oracle resilience, and pricing USDtb at par is a conservative treatment aligned with its borrow-only design. Therefore, we are voting FOR on this proposal.
Listing PT Ethena May
Vote Result: YES
Rationale
This proposal seeks to onboard the May 2026 expiry PT-USDe and PT-sUSDe tokens to the Aave V3 Core instance with the specified risk parameters and oracle configurations. Given the strong traction of prior PT listings and the conservative caps, disabled borrowing, and risk-oracle-driven E-Mode parameters, the onboarding supports continued demand while maintaining prudent risk controls. Therefore, we are voting FOR on this proposal.
Enhancing Market Granularity in Aave v3.6: Part 1
Vote Result: YES
Rationale
This proposal seeks to apply Aave v3.6 configurability upgrades across selected instances by removing collateral and borrowable status for certain assets, introducing LTV0 where appropriate, and restricting them to exclusive eMode participation. These changes tighten risk isolation, reduce unintended exposure outside correlated environments, and create clearer parameter boundaries across markets without disrupting intended use cases. Therefore, we are voting FOR on this proposal.
Onboard Strata srUSDe PT tokens to V3 Core Instance
Vote Result: YES
Rationale
This proposal seeks to onboard the Strata srUSDe April 2026 PT token as a new collateral option within the Aave V3 Core instance. The onboarding follows existing patterns for PT assets with conservative risk parameters, including disabled borrowing, capped supply, and oracle-based discount pricing, which helps maintain protocol safety while supporting yield demand. Therefore, we are voting FOR on this proposal.
[ARFC] Focussing the Aave V3 Multichain Strategy - Phase 1
Vote Result: YES
Rationale
This proposal seeks to focus Aave V3 multichain operations by freezing low-usage deployments on zkSync, Metis, and Soneium while establishing a higher revenue threshold for future deployments. Concentrating resources on higher performing markets can reduce operational burden and improve capital efficiency for the protocol. Therefore, we are voting FOR on this proposal.
Aave V3.6 MegaETH Activation
Vote Result: YES
Rationale
This proposal seeks to activate the Aave V3 MegaETH pool and list selected assets with conservative caps, oracle protections, and controlled permissions for protocol expansion. The setup follows risk provider guidance, limits exposure during the bootstrap period, and introduces eMode configurations to keep correlated assets efficiently managed. Therefore, we are voting FOR on this proposal.
Aave V3.6 Mantle Activation
Vote Result: YES
Rationale
This proposal seeks to activate the Aave V3 Mantle pool and list multiple assets with predefined risk parameters and oracle safeguards. The conservative caps, eMode structures, and restricted borrowing for higher risk assets help manage exposure while enabling ecosystem growth. Therefore, we are voting FOR on this proposal.
Increase WBTC Liquidation Bonus and EURS Reserve Factor on Polygon V3
Vote Result: YES
Rationale
This proposal seeks to increase the WBTC liquidation bonus on Aave v3 Polygon and raise the EURS reserve factor to improve liquidation efficiency and reduce residual exposure to a deprecated stablecoin market. The adjustments aim to improve liquidation throughput for large positions while discouraging inactive EURS supply from remaining in the protocol. Therefore, we are voting FOR on this proposal.
[ARFC] Revenue-indexed deficit offsets for Umbrella
Vote Result: YES
Rationale
Rationale: This proposal seeks to introduce a revenue-indexed deficitOffset mechanism to better align first-loss buffers with liquidation earnings. The mechanism improves risk alignment by linking protocol profitability to staker protection and reducing unnecessary slashing risk during profitable liquidation regimes. Therefore, we are voting FOR on this proposal.
Update syrupUSDC liquidation protocol fee
Vote Result: YES
Rationale
This proposal seeks to correct the Liquidation Protocol Fee for SyrupUSDC on the Aave V3 Base instance from 0% to 10%, aligning the configuration with what was originally intended by risk service providers. Correcting this parameter helps preserve protocol revenue capture during liquidations and reduces configuration risk caused by the prior setup error. Therefore, we are voting FOR on this proposal.
February 2026 - Funding Update
Vote Result: YES
Rationale
This proposal seeks to execute the February funding update by acquiring GHO for runway, providing liquidity support, and creating operational allowances for treasury management and incentives. The funding allocations support ongoing protocol operations, liquidity provisioning, and governance reimbursement while maintaining treasury activity within predefined limits. Therefore, we are voting FOR on this proposal.
Create Allowance GHO Mantle
Vote Result: YES
Rationale
This proposal seeks to create an allowance of 1.5M aEthLidoGHO from the Aave Collector to the Aave Liquidity Committee to support GHO liquidity provisioning on Mantle. Enabling controlled liquidity deployment supports GHO adoption across new markets while keeping operational management with the designated committee. Therefore, we are voting FOR on this proposal.
Focussing the Aave V3 Multichain Strategy - Phase 1
Vote Result: YES
Rationale
We voted in support of this proposal during the temp-check vote. Our position remains unchanged, therefore we will be voting YES on the onchain vote.
[ARFC] Aave v3.7 candidate
Vote Result: YES
Rationale
This proposal seeks to pre-approve Aave v3.7 upgrades that simplify protocol architecture, improve maintainability, and reduce operational complexity while preserving core risk controls. The changes remove legacy or unused features and strengthen eMode isolation logic without materially increasing protocol risk. Therefore, we are voting FOR on this proposal.
[TEMP CHECK] Aave Will Win Framework
Vote Decision: YES
Rationale
Our view was that Aave had reached a point where adopting a concrete strategic direction was preferable to prolonged internal conflict and uncertainty over the protocol’s future direction, and that this proposal offered the most practical path forward. Our reasoning is set out in more detail below:
-
Our perspective was that the Aave situation had escalated to an unsustainable degree. A considerable part of this stemmed from internal disagreements and competing narratives, yet the underlying issue remained that the approach taken by all parties had become value destructive. The situation needed to be resolved one way or another to restore stability to the protocol and provide clarity on its future direction.
-
As outlined in our comment here, we sought to cut through the noise and focus on the key long-term objective for Aave: building a financial powerhouse capable of rivalling some of the largest financial institutions in the world through open, permissionless rails. Aave Labs had, to its credit, presented a tangible vision aimed at advancing that objective. By contrast, no competing vision or proposal had emerged, despite these discussions continuing for more than two months. That left us with little practical choice but to support the vision that had been presented, which we viewed as a natural stage in the industry’s maturation.
-
The choice, in our view, was between continued misalignment with no forward movement, or committing resources to building a top-quality fintech product. At that stage, there was no real “winning” outcome in either direction; the decision was between adopting a path forward or continuing to absorb the corrosive effects of internal division.
-
We recognised that the amount proposed was significant - $51m is a substantial figure. Yet that number could not be assessed in isolation. Comparables cited by Blockworks showed that Ramp, Brex, and Revolut had materially higher burn rates in the $60m–$100m range, and that Lido, Uniswap, and Sky all operated with larger budgets. Against that backdrop, we did not view the request as excessive.
-
We also took into account the changing market structure across the industry. DeFi-native distribution and purely onchain markets appeared to be approaching their natural limits. In our assessment, Aave needed to compete through institutional business development and enterprise-focused execution if it intended to continue growing. Ignoring those structural constraints would likely have stalled growth altogether. Our own experience suggested that institutional counterparties were generally reluctant to engage directly with a DAO.
-
The proposal itself was not perfect. Based on our experience in DAO governance, very few proposals are. What mattered was that substantial community feedback from the prior two months appeared to have been incorporated, including the redirection of 100% of revenues from Aave-branded products to the DAO, the creation of a Foundation to hold IP assets, and a more measured transition from v3 to v4. In light of those revisions, characterising Aave Labs as an “extractive” actor appeared to us more emotional than analytical, and that framing did not guide our assessment.
-
We were fully aware that no outcome would satisfy all stakeholders, and that a public YES or NO vote on such a contentious matter would inevitably invite scrutiny of our rationale. That is part of public governance, particularly when views are sharply divided. Our objective was simply to present a reasoned position that we believed could be defended on its merits.
Add GHO on Aave Plasma and deploy GSM on Plasma.
Vote Result: YES
Rationale
This proposal seeks to define the launch parameters for GHO on Plasma, including the deployment of RemoteGSM infrastructure, bridging of GHO via CCIP, and the introduction of multiple eMode configurations to stimulate GHO supply and demand. The framework introduces controlled minting, conservative caps, and incentive programs that promote adoption while maintaining risk management and peg stability. Therefore, we are voting FOR this proposal.
GSM Migration
Vote Result: YES
Rationale
This proposal seeks to upgrade the existing Ethereum mainnet GHO GSMs to the new Remote GSM architecture, introducing the GhoReserve and GhoDirectFacilitator while migrating liquidity and deprecating the legacy GSM contracts. Aligning the GSM framework across mainnet and L2 deployments improves operational consistency and governance control over GHO issuance and liquidity management. Therefore, we are voting FOR this proposal.
[TEMP CHECK] Deploy Aave Protocol on Monad
Vote Result: YES
Rationale
This proposal seeks to gauge community support for deploying the Aave Protocol on Monad, alongside a proposed incentives package to bootstrap liquidity and adoption. Early deployment supported by substantial ecosystem incentives could position Aave as a foundational liquidity layer within a new network designed for high-frequency DeFi apps. Therefore, we are voting FOR this proposal.
[ARFC] Deploy Aave v3 on X Layer
Vote Result: YES
Rationale
This proposal seeks to deploy an Aave v3 instance on X Layer with an initial set of assets, risk parameters, and eMode configurations designed to support lending activity and ecosystem growth. Launching on X Layer could expand Aave’s reach through integration with OKX’s user base and create new liquidity opportunities while maintaining a conservative initial market configuration. Therefore, we are voting FOR this proposal.
ACI is Leaving Aave
Vote Result: YES
Rationale
This proposal seeks to cancel ACI’s active GHO payment stream and replace it with a one-time transfer covering 120 days of service to support a structured wind-down of their responsibilities. First of all, we’d like to commend the ACI for their outstanding governance contributions to Aave DAO. Providing a defined payout for the transition period supports continuity of operations, documentation handover, and orderly knowledge transfer while returning the remaining stream balance to the DAO treasury. Therefore, we are voting FOR this proposal.
Activate Capo Risk Agent and expand Rates Agent on more networks
Vote Result: YES
Rationale
This proposal seeks to activate the CAPO Risk Agent on Ethereum and expand the Slope2 Interest Rates Agent to Avalanche, Arbitrum, and Base, alongside aligning parameter constraints across supported networks. Automating these risk parameter updates strengthens protocol responsiveness and improves safeguards for yield-bearing assets and high-utilization markets across deployments. Therefore, we are voting FOR this proposal.
Enhancing Market Granularity in Aave 3.6: part 2
Vote Result: YES
Rationale
This proposal seeks to use Aave v3.6’s new configuration flexibility to tighten risk isolation by setting selected assets to LTV0, disabling unnecessary borrowability, and restricting many reserves to dedicated eModes only. These changes clean up legacy parameter workarounds, reduce unintended exposure across markets, and make reserve behavior more consistent with actual asset usage patterns. Therefore, we are voting FOR this proposal.
[ARFC] Safety Module - Reduce Emissions
Vote Result: YES
Rationale
This proposal seeks to reduce AAVE emissions to the Safety Module, adjust stkAAVE cooldown parameters, and lower stkABPT incentives in line with the DAO’s stronger treasury position and protocol-owned liquidity strategy. With buybacks outpacing token distribution and staking participation remaining resilient, lowering emissions improves capital efficiency without weakening protocol security. Therefore, we are voting FOR this proposal.
[TEMP CHECK] Aave V4 Bug Bounty Program on Sherlock
Vote Result: YES
Rationale
This proposal seeks to launch a dedicated bug bounty program for Aave V4 on Sherlock to create a permanent security reporting channel with structured triage and spam-resistant submission rules. Adding an always-on bounty layer ahead of V4 deployment strengthens external security review and improves the likelihood that critical issues are surfaced quickly through a specialized platform. Therefore, we are voting FOR this proposal.
[ARFC] Buyback Program - Budget Adjustment
Vote Result: YES
Rationale
This proposal seeks to reduce the annual AAVE buyback budget from approximately $50M to $30M and shift primary funding from stablecoins to ETH and ETH correlated assets. The adjustment is justified by declining protocol revenue and a projected budget deficit, while still maintaining consistent AAVE accumulation and preserving stablecoin reserves for operational sustainability. Therefore, we are voting FOR this proposal.
[TEMP CHECK] Aave V4 Licensing
Vote Result: YES
Rationale
This proposal seeks to establish a two-part licensing framework for the Aave V4 canonical repositories, comprising a BUSL-based license for the core codebase and a Contributor License Agreement for all contributors. The framework brings meaningful improvements over the V3 implementation, particularly the shift to conduct-based restriction language and the introduction of a CLA that ensures coherent, enforceable licensing across all contributions to the repository. Therefore, we are voting FOR this proposal.
Gho X-Layer Activation
Vote Result: YES
Rationale
This proposal seeks to activate Chainlink CCIP lanes for GHO on the X-Layer blockchain, enabling cross-chain GHO liquidity as part of a concurrent Aave deployment on the network. Establishing GHO as a foundational stablecoin on X-Layer from inception, with clearly defined rate limits and steward configurations, is a sound strategy for driving adoption and capital efficiency on a payments-focused chain. Therefore, we are voting FOR this proposal.
wstETH CAPO Oracle Incident User Reimbursement
Vote Result: YES
Rationale
This proposal seeks to refund 34 users who were erroneously liquidated as a result of a wstETH CAPO oracle misconfiguration on the Ethereum Core and Prime instances. Since the affected users bear no fault for losses stemming directly from a protocol-level parameter error, making them whole is both a reasonable and necessary action to preserve user trust in Aave. Therefore, we are voting FOR this proposal.
[ARFC] Aave <> Chainlink SVR. Multi-network expansion
Vote Result: YES
Rationale
This proposal seeks to expand the Aave/Chainlink SVR oracle system to Aave v3 deployments on Base and Arbitrum. Given the proven track record of SVR on Ethereum, including stability through volatile market conditions, and the inclusion of a SVROracleSteward as a safety backstop, the expansion to these two high-volume networks is a logical and well-structured next step. Therefore, we are voting FOR this proposal.
[ARFC] Aave V4 Activation on Ethereum Mainnet
Vote Result: YES
Rationale
This proposal seeks to deploy Aave V4 to Ethereum Mainnet, introducing a modular Hub and Spoke architecture designed to unify liquidity while enabling more precise risk segmentation across diverse market structures. The architecture represents a meaningful evolution of Aave’s credit infrastructure, and the security-first rollout approach, backed by over 345 days of cumulative security review and a $1.5 million audit budget, provides a sound basis for activation. Therefore, we are voting FOR this proposal.
Reduce Safety Module Emissions
Vote Result: YES
Rationale
This proposal seeks to reduce Safety Module emissions for stkAAVE and sunset the stkAAVE/wstETH BPTv2 module in favour of Protocol-Owned Liquidity, yielding combined annual savings of approximately 29,200 AAVE. Given sustained healthy staking participation in stkAAVE and the availability of more capital-efficient liquidity alternatives through the AFC’s concentrated liquidity deployment, these adjustments represent a prudent step in the ongoing effort to make AAVE emissions more sustainable. Therefore, we are voting FOR this proposal.
Aave V3.6 XLayer Activation
Vote Result: YES
Rationale
This proposal seeks to activate the Aave V3 XLayer pool by listing nine assets, USDT0, USDG, xBTC, WOKB, xETH, xSOL, xBETH, xOKSOL, and GHO, with risk parameters recommended by the DAO’s risk service providers following the completion of all required governance procedures. The deployment follows Aave’s established expansion framework, with appropriate e-mode configurations, conservative borrow caps, and standard security controls in place for the bootstrap period. Therefore, we are voting FOR this proposal.
[ARFC] Bug Bounty Program on Sherlock
Vote Result: YES
Rationale
This proposal seeks to establish a dedicated Aave V4 bug bounty program on the Sherlock platform as a continuous security reporting channel following the protocol’s launch. A persistent, well-structured bounty program with spam-resistant triage and a performance-based fee model is a prudent complement to the existing audit framework, particularly given V4’s new architectural surfaces. Therefore, we are voting FOR this proposal.
Enable SVR on Base and Arbitrum
Vote Result: YES
Rationale
This proposal seeks to enable SVR price feeds across Aave V3 deployments on Base and Arbitrum, while also revoking the now-redundant SVR steward permissions on Ethereum mainnet. The expansion follows a successful Ethereum rollout and is consistent with the previously approved multi-network SVR activation framework, with appropriate steward roles and asset coverage configured for each network. Therefore, we are voting FOR this proposal.
[TEMP CHECK] Onboard USSD to Aave V3 Sonic Instance
Vote Result: YES
Rationale
This proposal seeks to onboard USSD, Sonic’s native USD stablecoin, to the Aave V3 Sonic Instance as a suppliable and borrowable asset. Built on Frax’s frxUSD infrastructure and backed 1:1 by regulated, short-duration tokenized U.S. Treasury instruments from reputable issuers, USSD presents a credible and well-structured addition to the Sonic ecosystem’s stable liquidity base. Therefore, we are voting FOR this proposal.
Aave V4 Activation on Ethereum Mainnet
Vote Result: YES
Rationale
This proposal seeks to deploy Aave V4 to Ethereum Mainnet, introducing a modular Hub and Spoke architecture designed to unify liquidity while enabling more precise risk segmentation across diverse market structures. We had earlier voted in support of the ARFC proposal and published our voting rationale. Our position remains unchanged and therefore we will be voting YES.
Onboard BTC.b to Aave V3 Core Instance
Vote Result: YES
Rationale
This proposal seeks to onboard BTC.b to the Aave V3 Core Instance, extending an asset that has already undergone governance approval and demonstrated a sound risk profile on the Avalanche instance. Given the precedent set by the successful Avalanche listing and Lombard’s established infrastructure through the prior LBTC onboarding, this expansion is a straightforward and low-risk addition to the Core Instance. Therefore, we are voting FOR this proposal.
[ARFC] Aave V4 Licensing
Vote Result: YES
Rationale
This proposal seeks to formalize a two-part licensing framework for the Aave V4 canonical repositories, consisting of a BUSL-based license for the core codebase and a Contributor License Agreement to govern external contributions. We had earlier voted in support of this move during the temp-check vote. We still maintain our position and will therefore vote FOR.
[ARFC] Update Signers and SAFE Configuration March 2026
Vote Result: YES
Rationale
This proposal seeks to update the Budget SAFE signer configuration from a 3-of-4 to a 3-of-5 threshold while refreshing the signer composition to reflect current team structures across service providers. Adding a fifth signer increases redundancy and reduces the risk of execution delays without lowering the approval threshold in keeping with security standards. Therefore, we are voting FOR this proposal.
[ARFC] sGHO Launch Configuration
Vote Result: YES
Rationale
This proposal seeks to upgrade sGHO to a native ERC-4626 yield-accruing vault, setting an initial fixed Aave Savings Rate of 4.25% APR, consolidating the boost program to a single transitional boost, and establishing a structured migration schedule from the legacy stkGHO contract. The ERC-4626 standard materially improves composability and integration potential, the fixed rate provides a competitive premium over the Sky Savings Rate, and the phased migration schedule appropriately balances depositor flexibility with urgency. Therefore, we are voting FOR this proposal.
Listing PT Ethena 18JUN2026
Vote Result: YES
Rationale
This proposal seeks to onboard PT-18JUN2026 USDe and sUSDe tokens as collateral assets on the Aave V3 Plasma Instance ahead of the expiry and rollover of the current PT token listings. Prior PT token onboardings have demonstrated strong deposit inflows, and the structured e-mode configurations with linear discount rate oracles and appropriate supply caps reflect a prudent approach to managing these assets. Therefore, we are voting FOR this proposal.
[ARFC] Aave Will Win Framework
Vote Result: YES
Rationale
We had earlier voted in support of this proposal during the temp-check vote and published our rationale here.
[quote=“sid_areta, post:580, topic:16780”] Rationale
Our view was that Aave had reached a point where adopting a concrete strategic direction was preferable to prolonged internal conflict and uncertainty over the protocol’s future direction, and that this proposal offered the most practical path forward. [/quote]
[ARFC] Onboard PT-USDG-28MAY2026 to Aave V3 Core Instance
Vote Result: YES
Rationale
This proposal seeks to onboard PT-USDG-28MAY2026 as collateral on the Aave V3 Core Instance on Ethereum, enabling users to borrow against their Pendle principal token positions backed by Paxos-issued USDG. The underlying asset benefits from Paxos’s regulated issuer status, the Pendle market is already live providing observable demand data, and the fixed-discount structure of PT tokens offers a straightforward collateral profile. Therefore, we are voting FOR this proposal.
March Funding Update
Vote Result: YES
Rationale
This proposal seeks to address near-term operational funding needs through GHO acquisition, multi-chain asset consolidation to Ethereum, and the creation of allowances to support ongoing buyback and runway initiatives. The measures outlined are routine treasury management activities consistent with prior funding updates, and the reimbursement to TokenLogic for sGHO audit costs is a well-documented expense directly tied to a governance-approved upgrade. Therefore, we are voting FOR this proposal.
Listing PT Strata 25JUN2026
Vote Result: YES
Rationale
This proposal seeks to onboard PT-srUSDe-25JUN2026 to the Aave V3 Core Instance as collateral, continuing the established pattern of rolling over srUSDe PT token listings ahead of maturity expiry. Prior srUSDe PT onboardings have demonstrated strong LP adoption and user demand, and the use of the battle-tested dynamic linear discount rate oracle provides a consistent and reliable pricing mechanism aligned with previous listings. Therefore, we are voting FOR this proposal.
Umbrella Deficit Updates
Vote Result: YES
Rationale
This proposal seeks to increase the Umbrella Deficit Offset across key reserves on the Aave V3 Core Instance and cover existing realized deficits on CRV, ENS, USDC, USDT, and WETH. Calibrating the deficitOffset to better reflect liquidation-linked revenues generated by these reserves is a sound risk management adjustment, ensuring the DAO’s first-loss equity buffer is appropriately sized before losses are passed through to Umbrella stakers. Therefore, we are voting FOR this proposal.
[ARFC] Continued Deprecation Steps of Aave V2 Markets
Vote Result: YES
Rationale
This proposal seeks to adjust oracle configurations, risk parameters, and interest rate models across Aave V2 instances on Ethereum, Avalanche, and Polygon to reduce protocol risk and support the orderly wind-down of V2. Hardcoding stablecoin prices, fixing volatile asset oracle values, applying uniform liquidation threshold reductions, and reducing interest accrual on heavily distressed debt are all measured and well-reasoned steps that facilitate gradual deleveraging without triggering widespread forced liquidations. Therefore, we are voting FOR this proposal.
Collateral Parameters Adjustment on MegaETH v3
Vote Result: YES
Rationale
This proposal seeks to enable general market collateral parameters for WETH, BTC.b, and wstETH on the MegaETH Aave deployment, allowing cross-margin use cases that are currently blocked by the eMode-only configuration. The proposed parameters are conservatively calibrated relative to eMode equivalents to account for cross collateral composition, and the approach preserves the risk isolation benefits of the existing eMode structure while expanding utility for users whose borrowing needs span multiple asset types. Therefore, we are voting FOR this proposal.