[ARFC] Deploy Aave V4 on Base

Governance New Asset
1

Base thumbnail
Base thumbnail2880×1542 284 KB

Summary

This ARFC seeks community feedback on deploying Aave V4 on Base.

Base is an Ethereum Layer 2 incubated by Coinbase, offering low transaction costs, deep native USDC liquidity, and direct distribution to one of the largest retail user bases in crypto. Aave has operated on Base since 2023, and Base was among the first multi-chain deployments where Aave surpassed $1 billion in deposits.

Deploying Aave V4 on Base would bring the Hub and Spoke architecture to one of Aave’s largest and most active deployments, unifying network liquidity in a single Liquidity Hub while enabling specialized markets designed to serve the network’s millions of users.

Motivation

Base has become one of the most active networks in crypto. Consumer applications, payments products, and trading venues continue to launch on the network, Coinbase distribution places millions of verified users one step from onchain finance, and stablecoin activity on Base keeps growing. Activity of this kind generates steady demand for credit, and it rewards lending infrastructure that can serve many distinct use cases from a shared pool of liquidity.

Deploying Aave V4 on Base will

  • Upgrade one of Aave’s largest existing deployments to the current protocol architecture

  • Continue to extend Aave’s reach into the Coinbase ecosystem, where onchain consumer applications continue to onboard new users

  • Allow Aave to double down on an ecosystem where it’s already found success historically

Beyond current activity, we are extremely optimistic about the long-term trajectory of tokenized assets within the Base and Coinbase ecosystem. Coinbase has the distribution, the infrastructure, and the institutional relationships to bring a broad range of assets onchain over the coming years, whether crypto native or non-crypto native, including real-world assets and tokenized equities. Assets of this kind are particularly suited to the V4 architecture, where specialized markets can serve distinct collateral types and risk profiles. Deploying V4 on Base now positions Aave as the credit layer for that asset base as it develops.

Specification

The deployment will establish a Liquidity Hub on Base with an initial market scope and supported assets. The Hub configuration, oracle configuration, risk framework, deployment contracts, and the migration approach for existing Aave V3 positions on Base will be finalized during this ARFC’s discussion period, with parameter recommendations from relevant Aave DAO service providers, and published with the AIP.

Next Steps

  • Gather community feedback and service provider recommendations on this ARFC during a five day forum discussion period.

  • Aave Labs and LlamaRisk will complete their assessments and append the proposed initial assets and the Hub and Spoke configuration to this proposal.

  • Escalate the proposal to an ARFC Snapshot for a three day off-chain vote.

  • Following a successful Snapshot, submit an AIP for an onchain vote to deploy Aave V4 on Base.

Useful Links

Disclosures

Aave Labs is the author of this proposal and has received no compensation from third parties for its creation.

Copyright

Copyright and related rights waived via CC0.

7 Likes
2

Avalanche, Arc and Tempo each ran a Temp Check before their ARFC, and Base going straight to ARFC only reads as consistent if this is treated as an upgrade of an existing deployment rather than a new market. If it is an upgrade, then the migration approach for existing V3 positions is not a detail to finalize during the discussion period, it is the proposal. The Adoption Paths framework already set the expectation that v4 runs in parallel with v3 for 24 to 36 months and that early TVL is dominated by migration flow, with incentives and rate differentials inflating borrows without creating net new credit demand, and Base is where that distortion will be largest because the existing V3 book there is one of the biggest Aave has.

Three shapes for the V3 posture, and the ARFC should pick one before Snapshot rather than after. Run V4 alongside V3 with no scheduled change and let the market migrate on its own, which forces no exits but leaves two venues quoting the same assets on one chain for years while rates diverge and depth thins unpredictably on one side. Deploy with a dated V3 posture change written into the same proposal, for example freezing new supply on V3 Base once V4 Hub caps clear a stated utilization threshold, which produces a clean end state but commits to a trigger before the Hub has any Base specific operating history. Deploy with a deliberately narrow initial scope covering the collateral types V3 serves worst, leaving the majors on V3 until the Hub has been through a real liquidation event, which slows headline TVL but keeps the migration flow small enough to actually read.

The third, paired with one reporting commitment: report supply migrated from V3 Base separately from net new supply from the first day the Hub is live. Without that split the Base deployment will produce the largest and least informative TVL number in the V4 rollout, and every later cap decision on Base will be argued from it.

3

It’s been two weeks, hasn’t there been a snapshot vote yet?

4

Hi Aave Labs,

I have been reviewing the proposed V4 deployment on Base. Since the Hub configuration, oracle setup, deployment contracts and V3 migration approach are still being finalized, has the security review plan for the Base specific deployment boundary also been defined?

A focused review could cover the Base Hub and Spoke configuration, oracle and asset onboarding controls, deployment parameters and the V3 migration path before the AIP is submitted.

I run Arctek Audits and can send a concise proposed scope mapped to the final contracts and commit if an independent reviewer has not yet been selected.

1 Like