Aave has posted a governance temperature check proposing a Babylon-powered "spoke" that would bring native BTC borrowing into the protocol's forthcoming V4 architecture, according to a proposal surfaced by The Defiant.

The proposal would create a dedicated spoke, one of the modular deployments connected to the V4 hub, designed specifically to support borrowing against native Bitcoin. Unlike wrapped-asset designs such as wBTC or cbBTC, native BTC borrowing would let depositors post Bitcoin directly without relinquishing custody to a centralized bridge issuer.

What does a "spoke" mean in Aave V4?

Aave's V4 design replaces the monolithic single-pool model with a hub-and-spoke topology. The hub holds the core liquidity layer and shared risk parameters; spokes are satellite deployments tailored to specific assets, chains or collateral frameworks. Each spoke connects back to the hub for settlement and risk aggregation, but can operate with bespoke parameters for its collateral type.

A native BTC spoke would therefore be configured to handle Bitcoin-specific custody assumptions, oracle configurations and liquidation mechanics, rather than retro-fitting those features onto an EVM-centric pool.

Where Babylon fits

Babylon is a protocol designed to extend Bitcoin's security guarantees to other chains through self-custodial, slashable staking. In the proposed structure, Babylon's covenant-based staking model would underpin the custody logic of the BTC collateral held by the spoke, giving depositors a verifiably native route rather than a wrapped representation.

The arrangement matters operationally because wrapped BTC solutions concentrate risk in a small set of custodial or federated issuers. A Babylon-secured spoke would attempt to internalize the security model at the protocol layer, aligning collateral custody with the underlying Bitcoin network's own economic security.

Why a temperature check, not a vote?

Aave governance proceeds through staged signaling. A temperature check is the earliest filter, posted to the Aave Snapshot forum, where delegates indicate whether the proposal warrants a full ARFC (Aave Request for Change) review and, ultimately, on-chain voting. A negative read typically ends the proposal; a positive read moves the draft into the protocol's formal change-management pipeline, including code review by the Aave Labs team and risk-parameter evaluation by Gauntlet or the relevant risk steward.

The current proposal is therefore at the earliest gating stage, with no executable code, no on-chain vote and no committed deployment timeline. Readers should treat the spoke as a conceptual direction subject to revision through the forum process.

What market structure changes if it ships?

If the spoke moves past temperature check and is eventually deployed, it would mark Aave's first attempt to onboard native, non-EVM-native Bitcoin collateral at the hub level rather than via an ERC-20 wrapper. The implication for liquidity routing is direct: BTC-denominated borrowing demand, currently serviced by isolated wrapped-asset markets, could flow through Aave's unified liquidity layer.

The proposal remains subject to delegate feedback on the Aave forum. A standard temperature check runs for roughly three to five days before sentiment is tallied and the proposer is invited to next move.