Aave v4 Architecture

Aave v4 introduces a hub & spoke architecture that fundamentally restructures how liquidity and risk are managed compared to v3’s monolithic pool design.

The hub acts as a central liquidity coordination layer while spokes are isolated borrowing modules with independent risk profiles. This design delivers contagion isolation, specialized risk per market, and improved capital efficiency through targeted liquidity allocation.

1. Hub-and-Spoke vs Monolithic Pool Design

Aave v3: Monolithic Pool Architecture

All deposits share one unified risk pool
Every asset contributes to and draws from the same liquidity reservoir
Cross-asset contagion risk: problems in one asset can affect the entire pool
Risk parameters set globally, not granularly

Aave v4: Hub-and-Spoke Architecture

Hub Layer (Central Coordination)

The hub is the central liquidity coordination entity. Based on official documentation:

Hub Data Structure:

Identification: id, name, chain, address
Aggregated metrics: totalSupplied, totalBorrowed
System caps: totalSupplyCap, totalBorrowCap

interface Hub {
  __typename: "Hub";
  id: HubId;
  address: EvmAddress;
  chain: Chain;
  name: string;
  summary: HubSummary; // aggregates supply, borrow, caps
}

Hub Functions:

Centralizes liquidity for cross-spoke availability
Coordinates governance parameters across all spokes
Manages oracle and price feed infrastructure
Provides aggregate risk metrics and system-wide caps

Hub Assets

ERC-20 tokens held by the hub for liquidity and swaps:

interface HubAsset {
  __typename: "HubAsset";
  id: HubAssetId;
  onchainAssetId: OnChainHubAssetId;
  hub: Hub;
  underlying: Erc20Token;
  summary: HubAssetSummary; // supplied/borrowed, APY rates, utilization
  settings: HubAssetSettings; // fee receiver, liquidity fees, strategies
  userState: HubAssetUserState | null;
}

Key insight: HubAssets enable interest rate modeling at the hub level, with curves describing how supply and borrow rates change across the utilization range.

Spoke Layer (Isolated Markets)

Spokes are individual borrowing modules with isolated risk:

interface Spoke {
  __typename: "Spoke";
  id: SpokeId;
  name: string;
  address: EvmAddress;
  chain: Chain;
}

Spoke characteristics:

Each spoke is an isolated market with its own risk profile
Spokes can be discovered by chain ID or hub ID
Individual active status and module settings per spoke
Liquidation isolation between spokes

Reserve Layer (Asset-Specific Markets)

Reserves represent individual asset lending/borrowing conditions within spokes:

interface Reserve {
  __typename: "Reserve";
  id: ReserveId;
  onChainId: OnChainReserveId;
  chain: Chain;
  spoke: Spoke; // ← Each reserve belongs to a specific spoke
  asset: HubAsset;
  summary: ReserveSummary;
  settings: ReserveSettings;
  status: ReserveStatus;
  canBorrow: boolean;
  canSupply: boolean;
  canUseAsCollateral: boolean;
  canSwapFrom: boolean;
  userState: ReserveUserState | null;
}

Reserve data includes:

Supply APY, liquidity, caps, collateral configuration
Borrow APY, available liquidity, utilization rates, caps
Collateral factor, liquidation bonus/fee, collateral risk
Status flags: frozen, paused

Architecture Summary

Key architectural insight: Reserves live inside spokes, and spokes pull liquidity from the hub. This means:

Liquidity is shared at the hub level (efficiency)
Risk is isolated at the spoke level (safety)
Each reserve has independent risk parameters

2. Liquidity Concentration Benefits

Capital Efficiency Improvements

Targeted liquidity allocation: Spokes can focus liquidity on specific market segments without cross-subsidization from unrelated assets
Reduced cross-asset subsidy effects: In V3, high-performing assets effectively subsidized riskier ones. V4 isolation eliminates this
Hub-level liquidity pooling: Spokes can access shared hub liquidity when needed, avoiding capital fragmentation
System caps: Hub-level caps (totalSupplyCap, totalBorrowCap) provide system-wide risk limits while allowing spoke-level optimization

Interest Rate Model at Hub Level

The hub-level interest rate model enables:

Utilization-based rate curves per hub asset
Each data point includes: utilization rate, borrow rate, supply rate, liquidity distance from current state
Rate adjustments happen at the hub asset level, not per-reserve

interface HubAssetInterestRateModelPoint {
  __typename: "HubAssetInterestRateModelPoint";
  utilizationRate: PercentNumber;
  borrowRate: PercentNumber;
  supplyRate: PercentNumber;
  liquidityDistance: Erc20Amount;
}

3. Spoke Market Isolation Mechanics

Spoke Creation and Parameterization

Spokes are addressable entities on specific chains
Each spoke has independent active status and module settings
Discovery by chain ID or hub ID allows targeted spoke deployment
Spoke parameters set at deployment time

Risk Parameter Independence

Each spoke maintains:

Independent risk parameters
Independent reserve configurations
Independent liquidation conditions
Independent frozen/paused states

Liquidation Isolation

Liquidations are contained within individual spokes
Problems in one spoke do not propagate to others
Hub liquidity remains available to healthy spokes

Oracle Architecture

Hub coordinates price feeds and oracle infrastructure
Price data flows from hub to spokes
Redundant oracle setup at hub level provides reliability for all spokes

4. Comparison to Compound V3 and Morpho

Compound V3 Comparison

Feature	Compound V3	Aave V4
Isolation Model	Single-asset markets (one collateral asset per market)	Multi-asset spokes (multiple assets per spoke)
Liquidity Sharing	No cross-market liquidity	Hub-level shared liquidity
Governance	Single governance layer	Hub governance + spoke-level parameters
Risk Isolation	Complete (single asset)	Partial (spoke-level, multi-asset within spoke)

Key difference: Compound V3 achieves isolation through extreme specialization (one collateral asset per market). Aave V4 achieves isolation at the spoke level while maintaining multi-asset functionality within each spoke, providing better user experience with comparable safety.

Morpho Comparison

Feature	Morpho	Aave V4
Architecture	P2P matching layer on existing pools	Native hub-and-spoke design
Base Layer Dependency	Depends on Aave/Compound pools	Self-contained protocol
Efficiency	Optimization on top of inefficiency	Native capital efficiency
Risk Inheritance	Inherits base protocol risk	Own isolated risk model

Key difference: Morpho is an optimization layer that peer-matches lenders and borrowers within existing Aave/Compound pools. Aave V4 builds this optimization natively into the protocol architecture rather than bolting it on top.

Other Competitive Landscape

Euler V2: Uses isolated lending markets similar to Compound V3
Spark Protocol: Fork of Aave with some modifications
Radiant Capital: Cross-chain Aave fork (omnichain model)

5. Governance Implications

Hub-Level Governance

AAVE token holders govern hub parameters
System-wide caps and risk parameters controlled through governance
Emergency procedures and upgrade mechanisms

Spoke-Level Parameterization

Spokes have independent module settings
Risk parameters can be set per-spoke
Active status managed per-spoke

Integration and Developer API

Aave V4 provides comprehensive SDK support:

@aave/react: React hooks for hub, spoke, reserve, and hub asset queries
GraphQL API for custom queries
TypeScript interfaces for all data structures
Solidity integration patterns

Available React hooks:

useHubs / useHub – Fetch hub lists and individual hubs
useHubAssets / useHubAssetInterestRateModel – Hub asset management
useSpokes / useSpoke – Spoke discovery and details
useReserves / useReserve – Reserve management with filtering
useBorrowApyHistory / useSupplyApyHistory – Historical rate data
useHubSummaryHistory – Historical hub data

Query flexibility:

By chain ID, hub ID, spoke ID
By token/asset
By user address
By time window (day, week, month)
By currency (USD, EUR, etc.)
Filter by: supply, borrow, collateral categories

Upgradeability

Hub-level upgrade mechanisms
Timelock procedures for parameter changes
Individual spoke deployment/retirement without affecting other spokes

Strengths of Hub-and-Spoke Design

Contagion isolation: Problems in one spoke don’t cascade to others
Capital efficiency: Hub-level liquidity sharing reduces fragmentation
Specialized risk: Each spoke can have tailored risk parameters
Governance flexibility: Hub governance with spoke-level parameterization
Developer-friendly: Comprehensive SDK with React hooks and TypeScript

Potential Concerns

Complexity: Multi-layer architecture (hub → spoke → reserve) is more complex than V3’s monolithic pool
Hub single point of failure: If hub infrastructure fails, all spokes are affected
Integration overhead: Developers need to understand three architectural layers
Liquidity depth: Hub-level pooling may not be as deep as V3’s unified pool in edge cases