Bitcoin-focused developer Babylon Labs has submitted a new integration proposal to connect native BTC collateral to Aave borrowing—specifically enabling users to borrow stablecoins on Aave against locked Bitcoin, without wrapping or bridging BTC to Ethereum. The move targets one of DeFi’s biggest frictions: relying on custodial wrapped tokens for Bitcoin exposure in lending markets.
The proposal, which is currently at the Aave Request for Comment (ARFC) stage, outlines a system where users lock BTC in vaults on the Bitcoin network and represent that locked collateral on Ethereum via a non-transferable token. Borrowing would occur on Aave, while the BTC remains on its native chain.
Key takeaways
- Babylon Labs wants to let users use native BTC as collateral for stablecoin loans on Aave, using Bitcoin network vaults rather than wrapped BTC tokens.
- The design keeps BTC on its native blockchain and uses a non-transferable Ethereum token to reflect locked collateral.
- The integration would direct Aave DAO’s first $500,000 in qualifying annual revenue from the setup to the DAO treasury, per the proposal.
- Aave’s process is ongoing: the plan is still in ARFC, with potential community discussion and further voting steps only after feedback and risk analysis.
- Aave already supports loans against tokenized Bitcoin (including WBTC and cbBTC), but those options depend on custodians—an issue this proposal aims to reduce.
How Babylon’s native BTC collateral would work
Under the terms described in Babylon Labs’ proposal, users would lock their BTC into vaults on Bitcoin. Instead of moving or converting BTC for use on Ethereum, an Ethereum-side non-transferable token would stand in for the locked collateral and allow the Aave lending protocol to account for it.
This architecture is intended to avoid the typical trade-offs associated with wrapped Bitcoin. In earlier Aave collateral models, BTC exposure is commonly provided through assets such as Wrapped Bitcoin (WBTC) and Coinbase Wrapped Bitcoin (cbBTC), which involve custodians holding the underlying BTC. That structure introduces counterparty risk tied to the custodial arrangement.
In contrast, Babylon’s approach is designed so that the borrowing position is collateralized by BTC that never leaves the Bitcoin network. The Ethereum token functions as a representation mechanism for Aave’s collateral logic, not as a replacement of BTC via a wrapped transfer.
Why Aave’s existing wrapped-BTC model matters
Aave already supports tokenized Bitcoin collateral through products like WBTC and cbBTC. While these assets have enabled Bitcoin liquidity inside Ethereum DeFi, they also concentrate risk in the custody layer—meaning users depend on operators to maintain the peg between the wrapped token and the underlying BTC.
Babylon Labs’ proposal explicitly targets that dependency by aiming to bring BTC lending utility without relying on wrapped token custody. For Aave users, this matters because collateral reliability is central to how liquidations, borrowing capacity, and risk controls function across DeFi lending markets.
For the broader ecosystem, native collateralization could also be seen as part of a continuing shift toward minimizing “trust in middle layers.” However, as with any cross-chain system, the practical security profile will depend on how the vault mechanism and Ethereum representation token are implemented and audited.
Governance timeline: from ARFC to potential onchain vote
As of Thursday, the proposal remains in the ARFC stage, where the Aave community can review the plan, scrutinize risks, and respond with feedback. This matters because Aave governance does not treat new collateral types as routine additions; it typically subjects them to structured discussion and analysis before any contract-level authorization.
If community consensus forms, the proposal can move to a three-day offchain Snapshot vote. A threshold must be met: at least 320,000 AAVE-equivalent votes in favor are required for the process to advance. That figure is tied to Aave’s governance rules.
After the Snapshot phase, the next step would be a formal onchain vote. The proposal would still need to satisfy quorum and approval requirements set by Aave governance.
The proposal also follows earlier milestones. Babylon Labs says it initially submitted a related “temp check” on May 25, with a preliminary community vote passing on June 10, prior to the Wednesday submission that is now under ARFC review.
Revenue sharing and what it signals
Beyond the technical design, Babylon’s filing includes a financial allocation for the Aave DAO. According to the proposal text, the DAO would receive the first $500,000 in qualifying annual revenue generated by the integration.
That kind of revenue share is notable because it links the incentives of the integration provider with the governance body of the lending protocol. It also suggests that the proposal is not just about expanding collateral options, but about building a longer-term economic alignment between new infrastructure and the protocol’s treasury.
Investors and protocol participants may view this as a pragmatic governance approach: if the community approves the integration, Aave could capture value tied to the collateral onboarding and borrowing activity, rather than relying purely on community goodwill.
What to watch next
Readers should watch the ARFC feedback closely for concrete details on risk assumptions, the security model behind the Bitcoin vaults, and how the Ethereum non-transferable token enforces the collateral relationship. The next key inflection point will be whether discussion yields sufficient support to trigger a Snapshot vote and, ultimately, an onchain decision.
Be the first to comment