On September 2, Aave Labs advanced the ARFC proposal titled "Deploy Aave V4 on Arc" to the Snapshot stage, stating that voting will begin within 24 hours. The proposal plans to deploy a Core Liquidity Hub and two Spokes around the launch of Circle’s Arc mainnet, with initial assets including USDC, EURC, WETH, and cirBTC. While it has passed an earlier temperature check, it still requires approval via Snapshot and subsequent AIP finalization—it cannot be stated that Aave V4 is already live on Arc.
The proposal also outlines a launch-period revenue arrangement: Aave DAO expects to generate at least $2 million in protocol revenue annually; if actual revenue after deployment falls short, certain Arc ecosystem participants will cover the shortfall over the first five years. This mechanism reduces uncertainty around DAO revenue during the initial market launch, but it does not guarantee on-chain revenue growth or user returns. Final contracts, mainnet timing, and parameters remain subject to governance and risk assessment.
Arc has not yet launched on mainnet, and LlamaRisk’s support for the protocol is temporary and conditional. Risk institutions have clearly stated that network and asset evaluations are still ongoing, and the initial cap was set in advance without visibility into actual on-chain liquidity—it may be adjusted after mainnet launch. The most important news is not that a new market has “gone live,” but how Aave is defining boundaries for liquidity and risk before the new chain officially operates.
A hub connects two types of markets: stablecoin forex and general lending, each with separate pricing.
Aave V4 adopts a Hub-and-Spoke architecture. The Core Hub centrally holds shared liquidity for USDC, EURC, WETH, and cirBTC. The Main Spoke functions as a general lending market, allowing USDC, cirBTC, and WETH as collateral and permitting borrowing of all four assets. The Forex Spoke is designed exclusively around USDC and EURC, enabling these two stablecoins to serve as collateral for and be borrowed against each other, supporting forex-like demand within a narrower risk range.
The purpose of separating the Spokes is to isolate parameters for different use cases when sharing liquidity. The general market faces price volatility of crypto assets, while the Forex market primarily deals with stablecoin depegging and secondary market depth. The proposal sets a collateral factor of 78% for cirBTC and USDC in the Main Spoke, and 83% for WETH; for the Forex Spoke, it proposes 90% for USDC and EURC. These are proposed initial values, not current on-chain facts.
V4 also employs dynamic liquidation rewards that adjust based on changes in the health factor, rather than using the single fixed bonus from V3. Main Spoke and Forex Spoke have different target health factors and maximum reward ranges to accommodate differences between volatile and related assets. The dynamic mechanism may reduce over-liquidation in certain scenarios, but the actual performance of the code and parameters on the new network still requires validation through trading depth.
There is also a Tokenized Spoke that allows deposits only, providing composable deposit receipts for treasuries, aggregators, and strategies. It accepts lendable assets from the Hub but does not introduce new collateralized borrowing pathways, aiming to reduce additional credit risk when external applications access liquidity. Its more modular structure means users must identify which Spoke their funds enter and which set of rules applies, rather than simply recognizing the “Aave V4” brand.
The conservative cap limits early exposure, and the $2 million revenue floor also influences governance decisions.
LlamaRisk recommends setting initial Add Caps and Draw Caps separately for each asset and Spoke. For example, the Main Spoke is proposed to allow a maximum of $56 million USDC in new liquidity and $51 million USDC in withdrawals, with EURC set at $20 million and $18 million respectively; the Forex Spoke has separate add caps of $13 million USDC and $10 million EURC. cirBTC and WETH are also assigned capacities significantly below unlimited levels.
These figures are not target TVL, nor will they be fully filled upon launch. The purpose of the cap is to limit worst-case exposure while new chains, oracles, and bridge pathways have not yet been tested under real conditions. After mainnet launch, governance may adjust the cap up or down based on liquidity, utilization, and liquidation performance. Framing the cap as “expected funding volume” confuses risk management boundaries with business projections.
The revenue floor adds an additional economic incentive to the proposal. If actual protocol revenue falls below $2 million annually over the first five years, the agreed-upon ecosystem participants will cover the shortfall, encouraging the DAO to more readily assume the costs of deployment and maintenance. However, governance participants should verify who the guarantor is, how enforcement works, how defaults are handled, and how revenue is defined. Financial commitments should not obscure risks related to network security, stablecoin concentration, and the first-time integration of cirBTC into Aave.
The next steps remain community feedback, risk analysis, Snapshot voting, and the final AIP. If any step fails, deployment may be delayed or modified; even if voting passes, we must still wait for the Arc mainnet launch, contract deployment, oracle setup, and frontend readiness. Since the proposal states “around the time of mainnet launch” rather than a fixed date, reports cannot provide unconfirmed activation timelines.
The logic behind the Aave and Arc combination is clear: Circle wants Arc to concentrate liquidity for stablecoins and tokenized assets, while Aave aims to become the core lending layer on the new chain early on. What truly determines success or failure is not the initial list of four assets, but whether depth, liquidations, and cross-chain infrastructure can withstand pressure after mainnet launch. Currently, this is a deployment proposal with more complete parameters that has entered the voting phase; accurately labeling it as "proposed for deployment" rather than "planned for deployment" is essential to responsibly manage governance and user risk.