Aave highlights Babylon’s native Bitcoin collateral proposal

A proposal for borrowing against bitcoin

Aave announced on 14 October 2026 that a proposal would bring native bitcoin collateral to Aave V4 through Babylon’s Trustless Bitcoin Vaults. Collateral is an asset committed to secure a loan. If approved, bitcoin holders could lock their BTC on the Bitcoin blockchain and borrow supported assets against it. The proposed route matters because the collateral would remain on Bitcoin while supporting borrowing in Aave. The announcement opens a discussion; it does not activate a customer deposit product.

Keeping the bitcoin on Bitcoin

Babylon Labs introduced the underlying design in its May temperature-check proposal, an earlier discussion of the integration. It describes vaults whose bitcoin is locked under predetermined spending conditions. An application on Ethereum records the vault and controls when its collateral can be released. A proof of an allowed Ethereum event is then used in the Bitcoin redemption process, with an opportunity for designated challengers to stop an invalid claim.

The Ethereum representation would serve as internal accounting for the lending application. It would not be a freely transferable token that a borrower could send to another wallet or sell on an exchange. This distinction matters when following the proposed route: locking bitcoin creates collateral for a particular application, rather than issuing a general replacement for BTC. Babylon’s earlier design supplies background for the new proposal; it does not establish that the integration has launched.

Why Aave V4 uses separate lending modules

Aave’s architecture documentation explains V4 using two components. A Hub holds liquidity, meaning the assets available for lending. A Spoke is a connected module that handles particular supplying and borrowing rules. The Hub controls which assets a Spoke can access and how much it can draw; the Spoke manages positions, collateral and price information.

This separation helps explain how a specialised Bitcoin integration could use an existing source of loan assets without giving every lending market identical collateral rules. Access to shared liquidity still has limits. A proposed Spoke would need permission and configuration before drawing funds. The architecture supports different collateral arrangements, but its general design alone says nothing about the amount an individual bitcoin holder could borrow under Babylon’s proposal.

Bitcoin redemption and liquidation have different timings

Babylon Labs’ October proposal pairs a lending Spoke with a separate settlement Spoke. If a loan becomes eligible for liquidation, collateral can be seized to repay debt. The settlement design lets a liquidator receive WBTC, a wrapped bitcoin token, while authorised participants handle the later redemption of the underlying bitcoin. Babylon says that Bitcoin settlement takes multiple days because of its claim challenge window.

The proposal also specifies whole-vault liquidations. Where the seized vault exceeds the debt being repaid, the borrower’s remaining portion would be paid in discounted WBTC, rather than native BTC. That is a practical difference between ordinary withdrawal and forced settlement. Borrowers would pay Aave interest, and the adapter could add a Babylon fee calculated as a percentage of that interest. A final numerical fee, borrowing limit and launch date are not supplied.

The borrowing terms still depend on risk settings

Aave’s risk documentation describes the controls that make specialised Spokes possible: caps on supplying and borrowing, separate collateral settings, and functions that can freeze or pause activity. It also explains that borrowing costs can combine a liquidity-based base rate with a premium reflecting the collateral used.

For someone considering a Bitcoin-backed loan, the relevant questions therefore extend beyond whether BTC stays on Bitcoin. The collateral configuration affects borrowing capacity, and the interest configuration affects the cost of keeping debt open. Shared liquidity is not a promise of unlimited credit or a fixed rate. These are explanations of V4’s framework, not a quotation for the proposed Babylon integration or independent verification of its safety.

Discussion must lead to approval and execution

The October document is an Aave Request for Final Comments, or ARFC. Aave’s governance documentation describes this as the stage where contributors examine a proposal in more detail before a formal Aave Improvement Proposal, or AIP. Snapshot voting and on-chain approval are distinct steps in that process. A successful discussion does not itself execute a change.

An AIP carries the contract instructions needed to implement an approved decision. It must pass the applicable voting requirements and execution process. For a prospective borrower, that separates interest in the design from an available service: a forum proposal, a favourable vote and an operational borrowing route are different milestones.