Babylon Labs has provided more detail on how its Trustless Bitcoin Vaults would work if native BTC is onboarded as collateral on Aave V4, with a particular focus on pause controls, governance powers and upgrade safeguards.
The proposal is built around the idea that Bitcoin could be used in Aave without wrapping, bridging or handing assets to a custodian. Babylon argues that this would let holders keep BTC in a vault on Bitcoin while still using it to secure borrowing on Aave.
How the collateral model is designed to work
According to the proposal, Aave V4 would use a dedicated Babylon Spoke to isolate native BTC within its own risk perimeter. A separate BTC Vault Swap Spoke is intended to give liquidators a path to resolve positions tied to an asset whose settlement takes days rather than minutes.
Babylon said demand for its broader system has already been demonstrated, noting that more than 100,000 BTC has been activated since 2024. It argues that bringing that bitcoin into Aave as collateral would open a segment of the market the protocol has not been able to access so far.
The commercial structure described in the proposal would also direct revenue to the Aave DAO. The first $500,000 in annual revenue would go to Aave, while revenue above that level would be shared with the DAO retaining the majority portion. Part of that revenue is also slated to be used to buy AAVE.
What happens if the system is paused
Babylon addressed a key risk question directly: a pause does not let anyone move or release the BTC collateral. If the integration is paused, depositors cannot withdraw or redeem their assets, meaning the bitcoin remains locked in the vault and continues to back any debt opened on Aave.
At the same time, a pause also blocks repayments and liquidations. Babylon said this is why both pause and unpause powers are immediate rather than subject to delay. In its explanation, a delayed pause would be ineffective during an exploit, while a delayed unpause would unnecessarily keep users from restoring normal exit paths once an incident is resolved.
The company also said Aave DAO will receive its own pauser role over the TBV Aave integration contracts, including the adapter and related supporting contracts. That would allow the DAO to halt the integration independently of Babylon-side governance if it identifies a problem.
The multisigs behind the controls
The TBV contracts are governed by two separate multisigs. Interim Governance is a 4-of-7 Safe with seats held by Babylon, OZ21 of Informal Systems, DSRV, Xangle, Hashkey, B14G and Cradle. The Emergency Guardian is a 3-of-5 Safe whose listed members are Aave Labs, LlamaRisk, Babylon, BedRock and one seat still marked as to be determined.
Babylon said neither pause nor unpause actions are subject to a timelock, and both multisigs can trigger those actions immediately. However, it also argued that Interim Governance cannot keep the system closed on its own because the Emergency Guardian has an independent right to unpause.
That means if Interim Governance were to pause the system without a valid incident, or failed to lift a pause after the issue had been resolved, the Emergency Guardian could reopen it without needing Interim Governance's approval. Babylon specifically noted that Aave Labs and LlamaRisk sit on that Emergency Guardian multisig.
Timelocks, admin powers and the next formal step
Outside emergency actions, the proposal says all TBV contract upgrades and configuration changes would be delayed by a five-day timelock. During that window, the Emergency Guardian would be able to cancel any queued proposal before it takes effect.
On Aave's own side, the DAO would fully control the Babylon Spoke and the Hubs, including upgrades, parameter changes, pause, freeze and unpause functions. For the BTC Vault Swap Spoke, Aave DAO would remain the admin with upgrade rights, although configuration authority is planned to be delegated to a 2-of-3 multisig made up of Aave Labs, LlamaRisk and Babylon Labs.
Babylon said the final multisig membership, along with all Safe addresses, timelock addresses and contract addresses, will be included in the eventual Aave Improvement Proposal. That filing is the next confirmed step for turning the framework described in the discussion post into a formal governance package.
Source: governance.aave.com