Author: Babylon Labs
Date: 14-10-26
Simple Summary
This proposal requests the activation of native BTC as collateral on Aave V4 via the Trustless Bitcoin Vaults (TBV) protocol. The integration deploys two new Aave V4 Spokes, the Babylon Spoke and the BTC Vault Swap Spoke, and lists native BTC as the sole collateral asset of the Babylon Spoke. The first use case is borrowing stablecoins against native BTC. Risk parameters for both Spokes will be provided by Aave’s risk service providers.
In TBV, a depositor locks BTC in a Taproot UTXO on Bitcoin Network. Redemption is governed by on-chain rules (e.g., the depositor repaid their loan) and settles directly to a Bitcoin UTXO controlled by the redeeming party. The deposited BTC is not wrapped, bridged or held by a custodian.
Following the passed Temperature Check on this integration, the ARFC extends
that scope to the integration with the Aave V4 Hub and Spoke architecture, the
BTC vault lifecycle and its trust assumptions, liquidation and arbitrage
mechanics, value accrual, and governance.
Context
Babylon
Babylon was started in 2022 by Stanford University Professor David Tse and Dr. Fisher Yu, with a vision of a Bitcoin-backed crypto economy built on trustless protocols that unlock Bitcoin’s productivity without bridges, wrappers, or custodians.
The project is best known for the Bitcoin staking protocol, which lets BTC holders stake their BTC to secure other chains and rollups to provide economic security and earn staking rewards. The protocol is fully self-custodial: BTC never leaves Bitcoin and is not held by a bridge, wrapper, or signer set. Since the protocol’s launch in August 2024, the protocol has activated over 100,000 BTC cumulatively, reached a peak TVL of 72,000 BTC, and currently holds ~40,772 BTC (approximately $3.37B) staked.
The success of Bitcoin staking demonstrated that BTC holders seek trustless and native ways to put their Bitcoin to work. This motivated the development of Trustless Bitcoin Vaults (TBV), which extends the same trustless and self-custodial principles to general DeFi participation, and is the subject of this proposal.
The Babylon project is backed by approximately $110M+ to date from a16z, Paradigm, Polychain, Hack VC and others.
Trustless Bitcoin Vaults (TBV)
Trustless Bitcoin Vaults (TBV) allows anyone to use their native bitcoins as collateral in supported on-chain applications, without transferring custody to any trusted third party.
TBV achieves this by locking BTC on Bitcoin inside a Taproot script. The conditions under which it can be moved are enforced cryptographically: redemption requires a valid zero-knowledge proof of an event on the host chain (e.g. Ethereum Mainnet), and any attempt to claim BTC without a valid proof can be challenged and stopped by an eligible challenger during a fraud-proof window. The depositor can act as a challenger themselves by operating their own vault provider, so they need not trust any third party to secure their BTC.
Spending conditions are encoded in the Taproot script and pre-authorized by all vault participants, including the depositor. The protocol itself is governed by zero-knowledge proofs through a challenge-based procedure, efficiently enabled by the BaBe protocol, and redemption is native to Bitcoin. The locked BTC moves to a recipient designated by the vault’s spending conditions, which reference events on the host chain.
TBV can be integrated with any application on any supported host chain. Ethereum is the first supported host chain and the one this integration is built on. When BTC is locked in a Taproot script, a corresponding collateral record is created on Ethereum. Each application integration builds on it, optionally via an adapter layer that exposes it through the application’s interface. For the Aave V4 integration, since Aave V4 only accepts ERC-20 tokens as collateral, the adapter contracts represent BTCVaults 1:1 as a transfer-restricted ERC-20 representation token. The full component set is detailed in Architecture Overview.
TBV is built on BaBe (eprint 2026/065), peer-reviewed cryptographic research (to appear in CCS 2026, a top security conference) developed jointly by Babylon Labs and UC Berkeley. BaBe makes SNARK proof verification on Bitcoin approximately 1000x cheaper than prior approaches, making trustless Bitcoin DeFi practical at scale.
Motivation
The Aave V4 integration with Babylon Trustless Bitcoin Vaults protocol enables onboarding of non-custodial native BTC collateral on Aave. Depositors can borrow allowed loan assets against this collateral, with no third-party custodian, signer consortium, or threshold-signature group holding the underlying BTC.
The BTC Vault Swap Spoke enables permissionless liquidation on Aave despite the underlying collateral settling natively on Bitcoin. Any liquidator can settle the position by receiving wrapped BTC for a small premium, while arbitrageurs purchase the escrowed vaults and handle the BTC-side redemption. Mechanism described in Specification.
Every escrowed BTCVault is backed by wrapped BTC borrowed from the Hub, creating new borrow demand for that asset. At launch this is WBTC, Aave’s largest BTC reserve and presently underutilized on the borrow side; the integration can use any other wrapped BTC.
Native BTC as collateral on Aave V4 also serves as a composable primitive for the broader BTC DeFi ecosystem. Other projects can build new BTC-collateralized products on top, extending Aave’s reach into BTC-native DeFi.
Specification
Architecture Overview
The TBV deployment on Ethereum consists of protocol contracts and application contracts. A BTCVault is the protocol’s core primitive, BTC locked in a UTXO on Bitcoin, secured by its pre-signed transaction graph. On Ethereum, each BTCVault is represented by a collateral record carrying its amount, its depositor, its participant set, and its lifecycle state. The protocol contracts track collateral records and enforce the vault lifecycle, from creation through activation to redemption.
The application contracts define how BTCVaults are used inside the integrated application, in this case as collateral for Aave V4 Babylon Spoke. The Aave application layer consists of the adapter contracts, the two new Spokes, and the collateral representation token. Depositors supply their BTCVaults and manage their positions through the adapter, and liquidators call it to liquidate unhealthy positions. The Babylon Spoke is a variant of the standard Aave V4 Spoke, written by Aave Labs and maintained in the Aave V4 repository (Babylon Spoke), while the BTC Vault Swap Spoke introduces custom Spoke code.
Babylon Spoke
On the Babylon Spoke, depositors borrow against native BTC, the Spoke’s only collateral asset, drawing the borrowed assets from an Aave V4 Hub.
The Spoke differs from the standard Spoke in liquidation and collateral registration only. Only the Babylon Aave V4 adapter, configured as the Spoke’s liquidation manager, can liquidate on the Spoke. The standard liquidation entry point is disabled. Each liquidation call targets one BTCVault. The adapter passes the BTCVault’s amount to the Spoke as the maximum collateral to remove, and the Spoke repays only as much debt as that amount covers at the liquidation bonus, instead of repaying toward a target health factor. The Spoke charges no liquidation fee and applies no dust threshold, so the liquidator receives all the collateral removed. A position can use only the native BTC reserve as collateral.
The Spoke exposes the same set of risk parameters as a standard Aave V4 Spoke, with values configured for this Spoke. Because the collateral token cannot be transferred, some parameters are fixed: native BTC is collateral only and non-borrowable, the liquidation fee is zero, and receiving shares on liquidation is disabled. The target health factor has been removed, as each liquidation call seizes a single BTCVault and the liquidator repeats the call until the position is healthy.
A depositor locks BTC on Bitcoin, creating a BTCVault, and supplies it through the adapter. The adapter exposes the standard position-management actions, and the liquidation (both permissionless and permissioned) entry points.
Native BTC Collateral Representation
Aave V4 accepts only ERC-20 tokens as collateral. Native BTC collateral is therefore represented by an ERC-20 token with transfer restrictions. The token is an internal accounting unit, not a BTC wrapper, it cannot be transferred between users, traded, or held anywhere outside the integration.
The token has 8 decimals, matching Bitcoin’s satoshi denomination. Transfers are allowed only between the integration’s Aave contracts, a fixed allowlist made up of the Aave V4 Hub, the adapter contract, and the per-user position proxy contracts that hold each depositor’s position.
There are no risk parameters to configure for this token. The token contract is not upgradeable and has no admin. Its decimals, transfer restrictions, and the Hub and adapter addresses are set at deployment and cannot be changed.
Mint and burn are restricted to the adapter contract. The token is minted at BTCVault activation, directly into the depositor’s position, and burned when a vault leaves a position, whether withdrawn by the depositor or seized in liquidation. No other mint or burn path exists. By design, total supply equals the BTC locked in active positions.
BTC Vault Swap Spoke
A custom Spoke for post-liquidation BTC collateral settlement.
When a position is liquidated by a permissionless liquidator, the liquidator swaps the acquired BTCVaults through this Spoke for wrapped BTC, at the oracle rate minus a sell discount. The wrapped BTC is a BTC-denominated ERC-20 fixed when the Spoke is deployed, WBTC at launch. It is drawn from an Aave V4 Hub and held as interest-accruing debt against the escrowed BTCVaults. Arbitrageurs, a permissioned set with redemption rights, later buy individual escrowed BTCVaults by repaying that debt (principal plus accrued interest) and redeem the BTC on Bitcoin.
The Spoke exists because BTC redemption is restricted to pre-committed actors in each BTCVault’s Taproot script and takes multiple days through the claim challenge window. Decoupling liquidation timing from BTC redemption lets permissionless liquidators settle in wrapped BTC immediately while arbitrageurs handle redemption on Bitcoin’s timeline.
The BTC Vault Swap Spoke moves Hub funds in two ways. The first is the wrapped BTC draw and repayment described above. The second is the deficit path, used when an escrowed BTCVault’s value no longer covers its Hub debt. The BTCVault stays purchasable at its current value. The arbitrageur repays the Hub debt, capped at the BTCVault’s value less a reserved arbitrageur margin. Any shortfall is reported to the Hub as a deficit in the same transaction.
The BTC Vault Swap Spoke has 3 configurable parameters: the sell discount, the minimum profit reserved for the arbitrageur, and the fee recipient.
Governance, Control & Pause States
Both Spokes (the Babylon Spoke and the BTC Vault Swap Spoke) are governed by Aave DAO. Aave DAO lists the collateral asset and the borrowable assets, and sets the Spoke configuration parameters, including supply and borrow caps, interest rate strategy, liquidation parameters, and oracle configuration. It can also freeze or pause each listed asset individually, where freezing stops new supply and borrowing while pausing stops all activity for that asset. Any Hub used for drawing liquidity for these Spokes will also be governed by Aave DAO. A separate role for configuring the BTC Vault Swap Spoke is held by a 2-of-3 multisig of Llama Risk, Babylon Labs, and Aave Labs.
The Babylon TBV contracts are governed by Babylon governance representatives. They manage the TBV protocol configuration and the actor sets, and hold pause and freeze controls over the TBV contracts. A freeze blocks new vault creations and new borrows, while all exit paths keep working. A pause additionally stops the exit paths and is reserved for emergencies. All governance actions on the TBV contracts execute through a public timelock with advance on-chain notice.
Vault Lifecycle & Position Management
Vault Creation
The TBV protocol is trustless. BTCVault creation and redemption need a set of actors that coordinate with each other. The protocol defines three types of actors.
- Vault Provider. An infrastructure operator appointed by the depositor. It sets up and redeems the BTCVault for that depositor and challenges fraudulent claims. The depositor can run it themselves.
- Application Vault Keepers. An application-specific set of actors with claim and challenge rights over that application’s BTCVaults. On Aave V4, they claim BTCVaults that have been liquidated and act as the arbitrageurs.
- Universal Challengers. A global set of actors. They can challenge bad claims on any BTCVault, across every application.
The depositor locks BTC in a Taproot output on Bitcoin and submits a creation request on Ethereum. The vault provider, every application vault keeper, and every universal challenger must acknowledge the request and pre-sign the vault’s transaction graph, the fixed set of Bitcoin transactions through which the locked BTC can ever move. Acknowledgments are given only after the locked BTC is confirmed on Bitcoin. By design, nothing outside the pre-signed graph can spend the vault.
Once all acknowledgments are in, the depositor activates the vault by revealing a secret on Ethereum. If the depositor does not activate, or any actor fails to acknowledge, the request expires and the depositor reclaims the locked BTC unilaterally through a timelocked refund. By design, collateral can never exist without locked BTC behind it. On activation, the BTCVault enters the depositor’s Aave position, and from there the position is managed through the adapter.
Position Management
Every position action goes through the adapter. The depositor never interacts with the Babylon Spoke directly.
Borrowing and repaying follow standard Aave mechanics. On top of Aave interest, the adapter can charge a Babylon interest fee, a percentage of the borrower’s base Aave interest, collected on repayment. Collateral handling is custom, tailored to BTCVaults. A position can hold several BTCVaults. Each one is a single locked Bitcoin UTXO, so collateral moves in whole BTCVaults and never in part. The Babylon Spoke sees only the position’s total collateral amount, while the adapter tracks which BTCVaults make it up. The depositor adds collateral by activating additional BTCVaults into the position and withdraws whole BTCVaults while the position’s health factor stays at or above liquidation threshold. A borrower with multiple BTCVaults can set the order in which a liquidation seizes them.
Vault Redemption
A BTCVault is redeemed when application logic on Ethereum releases it. In the Aave V4 integration this happens in two cases. The borrower withdraws any subset of their BTCVaults while the position stays healthy, or the vault is liquidated and leaves through the liquidation flow. The application contracts define and enforce these rules on Ethereum. Each redemption emits an event naming the BTC keys authorized to claim the vault on Bitcoin.
The claim settles on Bitcoin. Only actors pre-committed in the vault’s Taproot script can claim, and the depositor is always one of them. The authorized claimer posts a Claim backed by a zero-knowledge proof of the Ethereum redemption event. If the proof is invalid, any challenger can stop the Claim during the claim challenge window. Challengers are all of the vault’s participants, the vault provider, every application vault keeper, and every universal challenger. By design, a challenge cannot block a valid claim. After the window passes, the BTC settles to the authorized key. The full timeline from redemption to settlement is multiple days, set by the claim challenge window.
Liquidation
Once a position’s health factor drops below liquidation threshold, anyone can liquidate it through the adapter, one BTCVault at a time. The adapter seizes the first BTCVault in the order the borrower set in advance. The liquidator repays the position’s debt asset. The collateral the Spoke removes is priced at the standard Aave liquidation bonus for the position’s health factor at entry. The Spoke stops once the collateral owed for the repaid debt reaches the BTCVault’s amount. The adapter refunds any repayment input the Spoke did not spend. A position holding several BTCVaults is liquidated through repeated calls. Each call checks the health factor again.
Liquidation always seizes whole BTCVaults. If the borrower’s entire debt is repaid before the BTCVault’s amount is consumed, the liquidator still receives the whole BTCVault and pays the borrower for the remainder in wrapped BTC (WBTC at launch) at the same liquidation-bonus discount. The borrower therefore receives that portion as discounted wrapped BTC instead of native BTC. The liquidator must hold the wrapped BTC and sets a cap on the total it can be charged.
Liquidation runs through two paths (permissioned and permissionless). In the permissioned path, an application vault keeper, which holds redemption rights over the vault, liquidates the position and redeems the seized BTCVault to its own BTC key. No external liquidity is involved.
In the permissionless path, anyone can liquidate. Because redemption is restricted to the pre-committed actors in each BTCVault’s Taproot script, these liquidators cannot redeem the BTCVaults they seize, so the integration introduces liquidation liquidity providers. A venue swaps the seized BTCVaults for a fungible asset immediately, instead of after the multi-day Bitcoin settlement.
The BTC Vault Swap Spoke is the first such venue. It purchases the seized BTCVaults from the liquidator for wrapped BTC drawn as debt from an Aave V4 Hub in the same transaction and holds them in escrow for the arbitrageurs to buy and redeem, as described in Architecture Overview. Additional venues can be added if scale requires.
Aave DAO Value Accrual
On the Babylon Spoke, borrowers pay standard borrow interest on every asset drawn from the Hub, exactly as on any other Spoke. On the BTC Vault Swap Spoke, escrowed BTCVaults accrue wrapped BTC borrow interest to the Hub until an arbitrageur repays the draw. This adds borrow demand on whichever wrapped BTC the integration uses, WBTC at launch, Aave’s largest wrapped BTC reserve and presently underutilized on the borrow side.
Native BTC as collateral on Aave V4 also serves as a composable primitive for the broader BTC DeFi ecosystem. Other projects can build new BTC-collateralized products on top, extending Aave’s reach into BTC-native DeFi.
Revenue Sharing
This proposal includes revenue sharing between Aave DAO and Babylon Foundation.
Babylon Foundation is responsible for the incentive arrangements supporting the
integration, such as borrower incentives and strategic integrations. These do
not guarantee borrower demand, revenue, token purchases or returns.
Revenue sharing applies only to Qualifying Revenue, the protocol-level fees
listed below, not all interest paid by borrowers:
- The Aave Hub’s Liquidity Fee on interest paid by Babylon Spoke borrowers.
- Liquidation fees charged through the adapter and the BTC Vault Swap Spoke.
The first $500,000 of Qualifying Revenue in each year from launch goes entirely
to Aave DAO. Above that, each band’s split applies only to the revenue within
that band, with distributions made monthly.
The token purchase allocation funds open-market purchases of AAVE (85%) and
BABY (15%), with purchased tokens allocated equally to Aave DAO and
Babylon Foundation.
| Annual revenue band | Aave DAO | Babylon | Token purchase allocation |
|---|---|---|---|
| First $500,000 | 100% | 0% | 0% |
| $500,000–$2 million | 78% | 18% | 4% |
| $2 million–$4 million | 72.5% | 22.5% | 5% |
| $4 million–$6 million | 67% | 27% | 6% |
| Above $6 million | 61.5% | 31.5% | 7% |
Audits & Formal Verification
Security audit engagements have been completed across five components, the btc-vault, the vault provers, the smart contracts, the web services, and BaBe. Six firms were engaged, with overlapping scopes so that every component is covered by at least two independent reviews. Coinspect additionally performed a pre-audit of the full protocol before the main engagements. Runtime Verification performed formal verification of the smart contracts. Babylon is running a re-audit of the finalized changes before mainnet deployment, carried out by Coinspect, ABDK and Zellic. The follow-up reports will be shared once finalized.
| Firm | Scope |
|---|---|
| Coinspect | Pre-audit (full protocol) + btc-vault, vault provers, smart contracts, web services audit |
| Sherlock | btc-vault, vault provers, smart contracts, web services, BaBe |
| Zellic | btc-vault, smart contracts |
| ABDK | Vault provers, smart contract cryptography, BaBe (paper and implementation) |
| ZK Security | BaBe |
| Runtime Verification | Formal verification of the smart contracts |
Next Steps
- Seek community feedback and risk analysis
- If community consensus is reached, raise to Snapshot.
- If the Snapshot outcome is positive, submit an AIP, with full risk parameters included, for on-chain governance approval.
Disclaimer
Babylon Labs is the author of this proposal. We have not been compensated by any third party to publish it.
This ARFC has been prepared solely to facilitate community discussion.
Copyright
Copyright and related rights waived via CC0.