This post consolidates the Hub-and-Spoke configuration discussions that have already begun in recent V4 risk and design analyses posted to the governance forums, as well as conversations together between @Aave Labs, @TokenLogic, @ChaosLabs, and @LlamaRisk. The intent is to provide the DAO consolidated reference before the formal ratification prior to V4 deployment and activation. A candidate Hub and Spoke setup is presented to illustrate what an optimized configuration looks like before any selection proposal.
Hub-and-Spoke topologies discussed so far
There are three top-level architectural models. These are not mutually exclusive. They should be read as configuration families that can be mixed, with trade-offs that are easiest to reason about when stated as “what becomes the unit of risk.”
Model A: Monolithic Hub (V3-style core, V4 controls)
A single Hub concentrates liquidity, with multiple Spokes connecting to it. Spokes are bounded by per-spoke add caps and draw caps, while assets continue to share a single utilization curve and rate environment. New Spokes can attach to existing liquidity depth without requiring separate pool bootstrapping.
The trade-off is shared solvency. If a collateral listing performs worse than anticipated by its liquidation design, resulting bad debt is realized against the same Hub liquidity, regardless of which Spoke originated the position. As a result, collateral eligibility and conservative draw caps become the primary containment mechanisms. Risk premiums, dynamic risk configurations, and Spoke-level caps play a more prominent role because the topology itself does not introduce a hard solvency boundary.
This model maximizes liquidity depth and rate stability but requires conservative assumptions across the entire venue.
Model B: Risk-profiled Hubs (separate venues, separate solvency)
Multiple Hubs exist, each with its own liquidity pool and accounting. Losses in one Hub are intended to remain contained within that Hub.
Rates and liquidations become Hub-local. Utilization is measured per Hub, so smaller venues react faster to the same borrow and can have thinner liquidation depth. The main governance levers are Hub-level inventory and caps, including collateral eligibility, while add caps and draw caps prevent a higher-risk market from scaling into an implicit second core. In practice, supplying liquidity becomes an explicit choice of which solvency boundary a user is underwriting.
This model improves risk isolation but introduces liquidity fragmentation and bootstrapping considerations.
Model C: Asset-centric Hubs (venue boundary aligned to a domain)
A Hub is dedicated to a specific asset family or strategy domain. Collateral and borrowable sets are chosen to reflect that domain rather than mirror a general-purpose Core.
Where collateral shares correlated tails, liquidation thresholds and incentives must incorporate additional buffers. The same governance levers - eligibility, borrowable set, add caps, draw caps, and Hub-level pause rights - are applied to keep the venue containable without affecting the Core.
This model fits partner-driven or domain-specific markets that require a hard perimeter to scale. The primary trade-off is higher concentration of tail risk and increased operational complexity.
| Family | Unit of risk isolation | Liquidity depth | Primary risk containment | Primary operational cost |
|---|---|---|---|---|
| Monolithic Hub | Spoke rules inside a shared balance sheet | Highest | Pricing, caps, shared backstop assumptions | Conservative listings |
| Risk-profiled Hubs | Hub boundary | Lower due to fragmentation | Hub-level segregation, hub-specific coverage | Bootstrapping multiple venues |
| Asset-centric Hubs | Hub boundary aligned to domain | Lower, more concentrated | Category containment | Complexity and concentrated tail-risk |
How V4 Infrastructure Composes These Models
Aave V4 does not lock the DAO into a single Hub layout. Liquidity can remain concentrated in a Hub while different risk profiles are expressed through Spokes, and the isolation boundary can tighten over time because position rules and exposure routing are configurable.
A market can begin as a Spoke inside a shared Hub, with containment enforced using familiar levers: collateral eligibility, borrowable set, oracle scope, liquidation thresholds and incentives, and per-asset add and draw caps.
If that segment grows to the point where shared solvency is no longer acceptable, it can move into its own Hub so the solvency boundary becomes structural. Any support from Core liquidity is then explicit via credit lines, with a credit line cap acting as the senior exposure limit. Raising the cap scales. Lowering it de-risks. Setting it to zero stops new draws.
Dynamic risk configurations make this manageable in production. Governance can tighten terms for new risk-taking without forcing immediate migration of legacy positions, and it can separate “stop growth” actions (caps) from “reduce leverage” actions (liquidation parameters).
Spokes as Risk Expression
In the V4 analyses so far, Spokes are treated as the place where the DAO encodes borrowing intent. They let the protocol keep one liquidity venue per Hub while still separating behaviors that unwind differently under stress (general borrowing, ETH/BTC leverage lanes, stable-driven strategies, etc.). That separation is what makes caps, liquidation tuning, and oracle scope feel targeted instead of “one size fits all.” When the boundary needs to be harder than configuration alone, the separation moves up to the Hub level, and any cross-Hub support is made explicit via credit lines with a cap that governance can raise, lower, or set to zero.
Initial V4 Hub and Spoke Configuration Candidate
This configuration reflects the common ground across the service provider inputs to date. It translates the risk and market-design feedback from @ChaosLabs, @LlamaRisk, and @TokenLogic into a Hub and Spoke setup that can be parameterized and operated in production. The table below defines the initial wiring. The rationale beneath it explains why this wiring was chosen, without implying a final recommendation.
| Core Hub | |||
|---|---|---|---|
| Spoke | Collateral | Borrowable | |
| Main Spoke | wETH, wstETH, weETH, wBTC, cbBTC, USDT, USDC, LINK, AAVE | wBTC, cbBTC, wETH, USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC, cUSDE | |
| Lido Spoke (e-Mode) | wstETH | wETH | |
| EtherFi Spoke (e-Mode) | weETH | wETH | |
| Kelp Spoke (e-Mode) | rsETH | wETH | |
| Lombard BTC Spoke (e-Mode) | LBTC | wBTC, cbBTC | |
| Gold Spoke | XAUt | USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC | |
| Forex Spoke | USDT, USDC, EURC | USDT, USDC, USDG, RLUSD, frxUSD, GHO, EURC |
| Prime Hub | |||
|---|---|---|---|
| Spoke | Collateral | Borrowable | |
| Bluechip Spoke | wETH, wstETH, wBTC, cbBTC | USDT, USDC, GHO, cUSDT, cUSDC, cUSDG, cRLUSD, cEURC |
| Plus Hub | |||
|---|---|---|---|
| Spoke | Collateral | Borrowable | |
| Ethena Ecosystem Spoke | PT-sUSDe, PT-USDe, sUSDe, USDe | USDT, USDC, USDe, GHO, cUSDT, cUSDC, cfrxUSD, cRLUSD | |
| Ethena Correlated Spoke | PT-sUSDe, PT-USDe, sUSDe, USDe | USDe |
The three-Hub layout is a solution to an observed operating constraint in V3. When every borrowing intent shares one solvency boundary, new growth areas compete for the same cap budget and force conservative defaults across the whole venue. Core remains the default rate environment and routing venue. Prime exists to serve suppliers who want a venue where their ETH/BTC is not borrowable. Plus exists so strategy-heavy stablecoin use can scale behind its own caps and pause conditions instead of pushing Core-wide limits that are set for general-purpose usage.
Credit lines are used to make cross-venue exposure explicit and bounded. The most operationally significant credit line in this initial configuration runs from Core Hub to the Plus Hub’s Ethena Ecosystem Spoke. Rather than requiring Plus to bootstrap its own independent stablecoin supply at genesis, Core’s existing deep stablecoin pools are made available to Ethena borrowers via a governed credit line cap. This credit line is the principal mechanism enabling Ethena strategy growth within the Plus Hub. When Prime or Plus needs stablecoin depth without bootstrapping a separate stablecoin liquidity venue, the exposure is expressed as a credit line cap that governance can move up or down. In the tables, borrowables prefixed with “c” (e.g., cUSDT, cUSDC, cfrxUSD) refer to this routed inventory rather than a local supply market in that Hub. For instance, the Ethena Ecosystem Spoke specifically, cUSDT, cUSDC, cfrxUSD, and cRLUSD represent inventory drawn from Core Hub under a defined cap. However, these credit lines are not the only source of stablecoin liquidity in the spoke: users can also supply stablecoins directly into the Plus Hub’s Ethena Ecosystem Spoke. The credit line caps govern the ceiling on Core-routed inventory specifically, and sit alongside whatever direct supply the spoke attracts on its own. This means the total borrowable depth in the spoke reflects both organic direct supply and the governed credit line allocation from Core. Spoke-level draw caps then control how much of that routed inventory can be consumed. This keeps “support” measurable and reversible without merging solvency boundaries.
Single-asset e-Mode-like spokes are chosen to avoid coupling parameters across collateral types and to keep controls granular. A combined correlated lane inherits the weakest liquidity and oracle assumptions in the set and forces one cap posture across multiple assets. Splitting the lanes keeps LTV, liquidation bonus, oracle scope, and caps adjustable per collateral, and it makes it straightforward to clamp one asset without reshaping the rest of the ETH leverage flow.
Prime’s non-borrowable collateral posture is designed around one operational promise: withdrawal availability and predictable behavior for suppliers. If collateral is borrowable, supplier experience is downstream of utilization and borrower demand. If collateral is not borrowable, supplier experience is dominated by the Hub’s own rules and the credit line limit governing any imported stablecoin inventory. Once isolated spokes are available, this configuration may be adapted in the future.
Stablecoin-only isolated spokes are deferred at genesis to keep the control surface small. They can improve collateral factors in narrow cases, but they add venues that each require their own caps, liquidation settings, oracle assumptions, monitoring, and pause decisions. The initial wiring prioritizes fewer moving parts, with the option to add stable-only lanes later if the incremental headroom is worth the operating load.
The separation between Ethena Ecosystem Spoke and Ethereum Correlated Spoke is primarily about isolating USDe borrowing to enable better parameters for that lane. Keeping them in separate spokes allows distinct draw caps, liquidation settings, oracle scope, and pause conditions to be applied independently, without constraints in one lane affecting the other.
Primary sources consolidated here
Hubs & Spokes in Aave V4: A Risk-Centric Analysis (@LlamaRisk): Hubs & Spokes in Aave V4: A Risk-Centric Analysis
Aave V4: New Features and Risk Parameter Analysis (@Chaos Labs): Aave v4: New Features and Risk Parameter Analysis
Aave V4: A Design Framework for Pooled and Isolated Bluechip Collateral Markets (@Chaos Labs): Aave v4: A Design Framework for Pooled and Isolated Bluechip Collateral Markets
Hubs & Spokes in Aave v4 (@TokenLogic): Hubs & Spokes in Aave v4
Aave Labs explainers
Understanding Aave V4’s Architecture: Understanding Aave V4’s Architecture | Aave
Aave V4 Risk Premiums: Aave V4 Risk Premiums | Aave
How Aave V4 Handles Risk Isolation Without Fragmenting Liquidity: How Aave V4 Handles Risk Isolation Without Fragmenting Liquidity | Aave
Aave V4 Public Testnet and Code Release: Aave V4 Public Testnet and Code Release | Aave
Official docs and repos
Aave V4 Documentation: https://aave.com/docs/aave-v4
Aave V4 Technical Documentation: https://github.com/aave/aave-v4/docs
Aave V4 Repo (core contracts): GitHub - aave/aave-v4: Aave V4 · GitHub
Aave V4 SDK: GitHub - aave/aave-v4-sdk: The official SDK for Aave V4 👻. · GitHub
Implementation status threads
Aave V4: Testnet and Codebase are Live: Aave V4: Testnet and Codebase are Live
Aave V4 Development Update: Aave V4 Development Update