[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.