[TEMP CHECK] Babylon Trustless BTC Vault Integration on Aave V4

[Babylon]

Author: Babylon Labs

Date: 25-5-26

Simple Summary

This Temperature Check seeks community input on the deployment of two new Aave V4 Spokes (Babylon Core Lending Spoke and BTC Vault Swap Spoke) to onboard native BTC as collateral, via the Trustless Bitcoin Vaults protocol. In TBV, a depositor locks BTC in a Taproot UTXO on Bitcoin. 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. No wrapping, no bridging, no custodians.

Background

Babylon

Babylon was started in 2022 by Professor David Tse (Stanford) 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 its trustless Bitcoin staking protocol, which lets BTC holders stake their BTC to secure other chains and rollups 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 launch in August 2024, the protocol has activated over 100,000 BTC cumulatively, reached a peak TVL of 72,000 BTC, and currently holds ~51,000 BTC (approximately $4B) 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.

Babylon developments are backed by approximately $100M+ to date from a16z, Paradigm, Polychain, Hack VC and others.

Trustless Bitcoin Vaults (TBV)

Trustless Bitcoin Vaults (TBV) allows anyone to use their native Bitcoin 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 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 is always eligible to act as a challenger themselves, so they need not trust any third party to secure their BTC.

The protocol introduces no third-party custodian, signer consortium, or threshold-signature group with discretionary control over the underlying BTC. Spending conditions are encoded in the Taproot script and governed by zero-knowledge proof verification through a challenge-based procedure 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. When BTC is locked in a Taproot script, a corresponding BTC vault record is created on the host chain (e.g. Ethereum). Each application integration builds on the BTC vault record, 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 BTC vault records 1:1 as a transfer-restricted ERC-20 token called vaultBTC. The full component set is detailed in Specification.

TBV is built on BaBe (eprint 2026/065), peer-reviewed cryptographic research (to appear in CCS 2026, the 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.

Why Aave V4

Aave V4’s Hub-and-Spoke architecture provides an isolated environment in which integrations can deploy both standard and custom Spokes without affecting other assets on the Hub. This is what makes V4 the right venue for the integration.

Two Spokes will be deployed: a lending Spoke (Babylon Core Lending Spoke) in which allowed loan assets are borrowed against native BTC collateral, and a custom BTC Vault Swap Spoke built to swap seized BTC collateral to WBTC and support permissionless liquidations. Both are detailed in Specification.

Aave DAO retains full control over all parameters and caps on both Spokes. V4’s programmability is what makes this kind of integration possible while preserving that governance oversight.

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 ensures liquidation on Aave remains permissionless despite the underlying collateral settling natively on Bitcoin. Any liquidator can settle the position by receiving WBTC for a small premium, while arbitrageurs purchase the escrowed vaults and handle the BTC-side redemption. This adds borrowing demand for WBTC on Aave, the largest BTC reserve on the platform (~$5B supplied) and presently underutilized on the borrow side. Mechanism described in Specification.

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

This Temp Check is scoped to integration architecture. Risk parameters, oracle configuration, supply and borrow caps, interest rate strategy, and full trust-assumption and challenger-economics details will be presented in the follow-up ARFC. Audits are being performed by Coinspect, Sherlock, Zellic, ABDK, and ZK Security across the protocol stack, with formal verification by Runtime Verification ongoing. The integration deploys new Spokes and adapter contracts only. Adapter contracts are user-facing entry points that integrate BTC vaults on Ethereum into Aave V4 Spokes. The Babylon Core Lending Spoke uses Aave V4’s standard open-source Spoke implementation; while the Bitcoin Vault Swap Spoke introduces custom Spoke code.

The integration introduces two new Spokes on Aave V4 (Ethereum Mainnet) and one new collateral asset listed inside them:

1. Babylon Core Lending Spoke

The lending Spoke. Use Aave V4’s standard open-source Spoke implementation, with vaultBTC as the sole collateral asset and supported borrowable assets (stablecoins, wrapped BTC …) drawn from an Aave V4 Hub.

A depositor locks BTC on Bitcoin; the corresponding BTC vault record on the host chain is translated into vaultBTC and supplied as collateral on the Spoke through adapter contracts. The same adapter contracts give depositors all standard position-management actions: adding collateral by providing additional BTC vaults, withdrawing one or more BTC vaults from a position, borrowing and repaying. Permissionless partial liquidations are also supported.

2. vaultBTC

vaultBTC is an internal accounting unit required to integrate with Aave V4’s ERC-20 collateral interface, not a tradable or transferable BTC wrapper. It is a transfer-restricted ERC-20 whose destinations are limited to a fixed allowlist: the Aave V4 Hub, the Babylon Core Spoke, and the integration’s adapter contract. Transfers to any other address are not allowed.

Mint and burn are restricted to the adapter contract. vaultBTC is minted only when a BTC vault is added to a user’s position as collateral, and burned only when a BTC vault is withdrawn from a position. No other mint or burn path exists. Total supply always equals the BTC locked in active positions.

3. 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 BTC vaults for WBTC through this Spoke at a small premium, with the WBTC drawn from an Aave V4 Hub and held as debt against the BTC vaults. Arbitrageurs, a permissioned set with redemption rights, later buy individual escrowed BTC vaults by repaying the WBTC 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 BTC vault’s Taproot script and takes multiple days through the fraud-proof challenge window. Decoupling liquidation timing from BTC redemption lets permissionless liquidators settle in WBTC immediately while arbitrageurs handle redemption on Bitcoin’s timeline.

The only direct fund-flow touchpoint between the Hub and the BTC Vault Swap Spoke is the WBTC drawn at liquidation, which is repaid when arbitrageurs purchase the escrowed BTC vault.

Disclaimer

Babylon Labs is the author of this proposal. We have not been compensated by any third party to publish it.

This TEMP CHECK has been prepared solely to facilitate community discussion.

Next Steps

1. Temperature Check: Gather community feedback and assess sentiment towards the deployment of two new Aave V4 Spokes (Babylon Core Lending Spoke and BTC Vault Swap Spoke) and the listing of vaultBTC as collateral to onboard native BTC as collateral via the Babylon Trustless Bitcoin Vaults (TBV) protocol. The vaultBTC listing would be added either to an existing V4 Hub or to a new Hub deployed for this integration.

2. ARFC: If the Temperature Check Snapshot indicates positive sentiment, proceed to the ARFC stage for further discussion, risk parameter evaluation, audit review, and finalization of the proposal.

3. AIP: If the ARFC stage Snapshot is successful, submit the proposal as an AIP for voting and on-chain governance approval.

Copyright

Copyright and related rights waived via CC0.

[simo]

Writing this as someone who comes from the Bitcoin world.

For years the standard answer for “BTC in DeFi” has been only one: wrap it.

WBTC works, but ~115k BTC sitting behind a custodial wrapper has always been the awkward compromise the ecosystem learned to live with.

Especially for the bitcoiners.

This could represent the first at-scale deployment of native BTC as productive collateral without that compromise. Babylon’s staking protocol already shows there’s real demand for the trustless model. ~52k BTC ($4B) staked natively, almost half of the entire WBTC supply, with BTC never leaving Bitcoin.

Extending that same self-custodial approach from staking to lending is the logical next step, and Aave V4’s Hub and Spoke Design is the perfect match.

The WBTC angle is also worth highlighting: Aave is the largest BTC reserve in DeFi (~$2.5B WBTC supplied, historically underutilized on the borrow side). Routing post-liquidation settlement through WBTC turns this integration into actual borrow demand for an asset already used in size within Aave Protocol.

Supportive at Temp Check.

[stani]

Great to see the Aave V4 spoke ecosystem to take off. Strong start by enabling real Bitcoin as collateral on Aave. Excited to see this proposal moving forward, and will be supportive of the temp check.

[nicopei]

Writing this as someone who works closely with institutional borrowers — two of the main reasons we consistently hear for choosing off-chain borrowing solutions over Aave are:

1. They want to keep BTC native

2. They want fixed-rate borrowing

Having native BTC as productive collateral on Aave v4 is instrumental for growth. BTC is one of the largest and most institutionally held assets in crypto, but today a meaningful portion of that balance sheet remains underutilized in DeFi due to the lack of native collateral support and predictable borrowing costs.

Supportive at Temp Check

[BlockEnthusiast]

The depositor is always eligible to act as a challenger themselves, so they need not trust any third party to secure their BTC.

A) Why aren’t challenges permissionless? Is it expected that each borrower runs their own challenge infra?

B) Does Aave have challenge power? If yes is this limited to the Spoke or the Labs, or the DAO? How does that work?

It says any protocol can be integrated so I assume there is governance over the zk proofs to enable coverage.

Spending conditions are encoded in the Taproot script and governed by zero-knowledge proof verification

C) so clearly they are not solely governed by zk-proofs, but by some additional layer, can you explain more about what that layer looks like?

is this limited to adding chain support on the tap root side and than chain governance like transfer restrictions and swap vaults are governed more heavily?

can a chain integration be revoked? Can the taproot script be upgraded?

What are the real limitations of TBV governance?

For the Aave V4 integration, since Aave V4 only accepts ERC-20 tokens as collateral, the adapter contracts represent BTC vault records 1:1 as a transfer-restricted ERC-20 token called vaultBTC. The full component set is detailed in Specification.

D) why are transfers restricted? This limits the potential liquidity available and shoehorns a service provider to route all liquidations. Why not simply be a bridge?

It reads to me like your not a bridge because you reserve the right to deny bridge crossings sort of like how Ethena doesn’t actually deposit in CEXs. You could shut down swap liquidity by removing the swap vaults, or add higher fees to swap w/o competition.

Perhaps the purpose is to strengthen borrowers positions against Aave’s contracts, by “not being exposed to exploits transferring from AAVE” but then who actually determines if a liquidation is valid? Aave or TBV’s governance or emergency service providers?

What does this mean for AAVE to not be the ultimate authority of what constitutes as valid?

E) Is there some legal agreement needed w/ AAVE to enforce its agreements are honored? Much like how Ethena is bound by various courts to the CEX’s it witholds deposit from.

F) What happens to LPs of a swap vault if its delisted. Will they be able to redeem their TBV half of their positions? Are there even LPs, or are these swap vaults AMO like, where TBV provides both sides?

[MconnectDAO]

Great to see a Temp Check to bring native BTC to Aave V4 via TBV and the spoke architecture. To help delegates assess the integration, a few extra details would be very useful:

• Please share preliminary risk parameters (LTV, LT, caps, liquidation bonus) for vaultBTC and some WBTC hub stress scenarios (e.g. BTC crash + delayed redemption).

• Clarify the trust and challenge model end‑to‑end: who are challengers, what is their incentive design, and what are realistic failure modes if challenge participation is low or colluding?

• Expand on governance boundaries and control: which components (TBV upgrades, Taproot script templates, arbitrageur allowlists, relayers) are governed by Aave vs Babylon, and what veto/exit levers Aave has.

• Provide more color on the permissioned arbitrageur set and fee flows (vault fees, redemption fees, spreads) so the community can evaluate centralization risks and economic alignment @Babylon

[bee_b14g]

From the perspective of working directly with both long-term BTC holders and stablecoin yield seekers, we see clear demand for BTC-native collateral and agree with the points raised in the Temp Check discussion**.**

However, infrastructure alone is not sufficient. Adoption will be driven by products that solve the operational and risk constraints of both BTC holders and stablecoin suppliers.

Key requirements from BTC holders:

- Sustainable borrowing economics while maintaining native BTC exposure

- Stablecoin borrowing strategies that create arbitrage and capital efficiency opportunities

- Automated risk management to minimize liquidation exposure, as long-term BTC holders generally do not want their BTC rehypothecated or force-liquidated

Key requirements from stablecoin suppliers:

- Reliable withdrawal liquidity at all times, especially during the early phase where v4 capacity remains constrained

- Sustainable yield generation rather than short-term incentive-driven APY

Supportive from b14g.

[TamasXin]

Hi everyone! Is it possible to do this in such a way that the AAVE treasury isn’t affected at all in the event of a massive and rapid BTC price crash?

[0xAleksaOpacic]

Hey, thanks for the questions! I work as Lead Solution Engineer at Babylon Labs, let me try to address questions.

The Temp Check is scoped to integration architecture. Risk and configuration parameters, the supporting risk analysis, and the specific Arbitrageurs and Universal Challengers will be presented in the follow-up ARFC, prepared in collaboration with Aave DAO risk providers.

TBV has multiple actors, each with their own incentive to act as a challenger. Challengers monitor every claim in real time, and any one of them can block an invalid one during the fraud-proof window.

• Vault Provider (VP). A service that handles vault creation, vault claims and challenges. It can be run by the depositor or delegated to an external operator for a commission, with a fallback redemption path always available. The incentive is protecting their BTC (when self-run) or earning a commission (when delegated).
• Arbitrageur. A permissioned set with redemption rights. Arbitrageurs buy vaults from the BTC Vault Swap Spoke and redeem them for a margin. Their incentive to challenge is preventing wrongful claims, since they could otherwise have captured the same vault.
• Universal Challenger (UC). A permissioned set with challenge-only rights, acting as a protocol-level fallback. UCs monitor every claim and challenge invalid ones. The set is composed of entities aligned with the protocol’s long-term success.

Both Spokes (Babylon Core Lending Spoke and BTC Vault Swap Spoke) and the V4 Hub that provides their liquidity will be governed by Aave DAO. This means Aave DAO controls all Spoke parameters, including risk parameters, Hub liquidity allocation, pause and freeze, and listing decisions. On the Babylon side, Babylon governance representation governs the TBV protocol, integration contracts, and the addition of permissioned actors, with specific participants and parameters to be disclosed in the ARFC.

[0xAleksaOpacic]

Thanks a lot for reviewing the temp check and for the thoughtful questions.

Many of your questions: why challengers are pre-defined, why vaultBTC is transfer-restricted, why this is not a general-purpose bridge, whether integrations can be revoked, whether Taproot scripts can be upgraded, etc. point to the same core design principle behind TBV:

TBV achieves native, trustless Bitcoin collateral by deliberately constraining the action space of each BTC vault upfront.

Take a conventional BTC bridge such as wBTC as a comparison. Because wBTC is fungible, the bridge must support arbitrary redemptions: any holder, any amount, at an unpredictable time. Given Bitcoin’s limited programmability, supporting that model typically requires pooled native BTC controlled by a bridge operator or custodian. That is where the trusted counterparty enters.

TBV makes a different tradeoff. It gives up general fungibility in exchange for native BTC custody, cryptographic verifiability, and application-specific programmability.

When a TBV vault is created, its action space is pre-defined, including:

• Who can redeem the native BTC: a pre-defined set of BTC addresses eligible to redeem the native Bitcoin from that vault
• How much can be redeemed: the vault is redeemed as a whole, not through arbitrary partial redemptions
• Which external program controls redemption rights: a pre-defined program on a pre-defined chain determines who is entitled to redeem the native BTC. In this proposal, that program is the Babylon-Aave integration smart contract on Ethereum.
• Who can challenge invalid claims: a pre-defined challenger set can challenge malicious or invalid redemption claims.

Once a vault is created, this action space is fixed. The Taproot script cannot be upgraded, the controlling program cannot be swapped, and the vault cannot be redirected to a different integration. This is a core security property, not an administrative limitation.

With that context, direct answers below.

A) Why aren’t challenges permissionless? Is every borrower expected to run challenge infra?

Explained above.

A borrower can choose to run a vault provider (explained here) infra, which will allow it to challenge by itself, if it does not want to count on other challengers.

B) Can Aave have challenge power?

Yes, if Aave is included in the challenger set.

Whether that role is exercised by Aave Labs, the DAO, or designated service providers is an integration/governance design choice. TBV supports it.

C) Is spending governed only by ZK proofs? Can integrations be revoked? Can Taproot scripts be upgraded?

The taproot is not “another layer”, it is the native Bitcoin script where the BABE ZK-system and action space is written. Unlike Ethereum smart contract, Bitcoin script has no upgrade or governance feature.

New integrations can be supported by new vault types, but existing vaults cannot be repointed by governance.

D) Why are transfers restricted? Why not simply be a bridge?

Explained above. It is to achieve trustlessness, self-custodian, and programmability. Not about administrative denying power, which is irrelevant.

E) Is a legal agreement needed with Aave to enforce the outcome?

The security model should not rely on legal enforcement.

The goal is for BTC redemption to follow the pre-defined script, proof system, and Aave smart contract state. I cannot comment on Ethena/CEX legal arrangements, but TBV’s design goal is different: cryptographic and on-chain enforcement, not legal recourse against a custodian.

F) What happens to LPs of a swap vault if it is delisted? Are there LPs?

Not sure what do you refer to as “a swap vault”. There is only one type of vault, the TBV on the Bitcoin chain, which locks native Bitcoin as collateral for Aave V4. The swap spoke is introduced to enable permissionless liquidations on the Babylon Core Lending Spoke, by making each liquidation atomic despite Bitcoin’s slow settlement. This means that:

• time- and price-sensitive positions on the Core Spoke can be liquidated permissionlessly and on time, so no bad debt accrues
• the same vaultBTC collateral ends up backing a WBTC loan instead, which is not time- or price-sensitive

Throughout the process, each loan is fully backed by native Bitcoin collateral in the vault. Apart from wBTC liquidity, there is no special liquidity needed.

The swap spoke is just the first liquidation liquidity venue. Additional venues could be added so that liquidations are not solely reliant on WBTC and the Hub’s available liquidity.

Hope this clarifies the core design tradeoff. TBV is not a general-purpose BTC bridge; it is designed to make native BTC usable as trustless and self-custodian collateral with application-specific programmability.

ARFC would provide more detail on the Babylon-Aave integration design, including roles, parameters, and operational assumptions.

[MconnectDAO]

Thank you for the detailed explanation so far. I have a few additional questions to better understand the risk and governance assumptions of this integration:

1. What is the exact fraud‑proof window, and how was it calibrated against BTC settlement and Aave liquidation timelines?

2. Beyond economic incentives, is there any bonding or slashing mechanism for challengers to ensure honest behavior?

3. How are collusion and liveness risks for Vault Providers, Arbitrageurs, and Universal Challengers modeled under stress scenarios?

4. In the event an invalid claim is not challenged in time, how are potential losses distributed between Aave LPs, borrowers, and TBV users?

5. How are conflicts between Aave DAO governance and Babylon governance expected to be resolved in practice ( around permissioned actors or parameter changes)…?

[AaveLabs]

Aave Labs is supportive of this TEMP CHECK moving forward.

The meaningful change Babylon is proposing is a way for native BTC to be used as collateral while the BTC remains on Bitcoin and the Aave-side representation stays constrained to this integration.

BTC collateral demand is real, and a significant segment of BTC holders has avoided DeFi because the usual path requires accepting bridge, wrapper, or custodian assumptions. If this design can support borrowing against native BTC without introducing unmanaged settlement or liquidation risk, it could open a new collateral base for Aave V4.

Aave Labs is supportive of advancing this to snapshot for continued governance discussion.

[Abel189]

Generally supportive of this direction.

One of the largest untapped opportunities in DeFi remains native BTC capital, and Babylon’s approach is particularly interesting because it seeks to avoid the custodial and bridge-related assumptions that have historically limited Bitcoin participation in onchain lending markets.

Aave V4’s Hub-and-Spoke architecture seems well suited for this type of experimentation, allowing the DAO to isolate risks while evaluating real-world demand for BTC-backed borrowing.

That said, the integration introduces significant technical complexity compared with traditional collateral assets. Before progressing to later stages, I would like to see additional detail regarding:

• Liquidation efficiency during periods of market stress.
• Economic incentives for challengers and arbitrageurs.
• Potential bottlenecks created by redemption timelines on Bitcoin.
• Oracle design and valuation methodology for vaultBTC.
• Worst-case scenarios if arbitrage participation becomes limited.

Overall, I view this as a potentially important step toward bringing native Bitcoin liquidity into Aave, but the operational and economic assumptions will be just as important as the underlying cryptographic design.

[CalvinBedrock]

We at Bedrock are glad to express our support for this proposal.

Babylon’s Trustless BTC Vault is a meaningful step forward for BTCFi — trust-minimized, cryptographically secured, and a clear improvement over custodial wrapped BTC solutions. Integrating TBV into Aave V4 unlocks better capital efficiency and stronger security guarantees for BTC holders.

Bedrock is actively building products on top of this primitive and sees TBV as a key building block for next-generation BTCFi. We look forward to collaborating with the Babylon and Aave teams as this moves forward.