Babylon, HashKey Cloud Plan Native Bitcoin Borrowing Through Aave

Babylon Labs and HashKey Cloud are planning an Aave v4 integration that would let users borrow against native Bitcoin (BTC), connecting Bitcoin-based collateral to decentralized lending without wrapping the asset or placing it with a centralized custodian.

HashKey Cloud will integrate Babylon’s Trustless Bitcoin Vaults, which lock BTC in a dedicated Bitcoin UTXO while maintaining a corresponding record on Ethereum. Supported borrowing assets include USD Coin (USDC), Tether (USDT) and Wrapped Bitcoin (WBTC).

The service is not yet a production lending product. Native Bitcoin-backed borrowing is available on the Aave v4 public testnet with test assets, while no commercial launch date has been announced. Further partnership and rollout details are expected in the coming months.

The structure addresses a central challenge for Bitcoin use in decentralized finance: BTC operates on the Bitcoin network, while many lending markets run on other blockchains. Existing models often use wrapped tokens, bridges or custodial arrangements to make Bitcoin usable in those markets.

Babylon’s vault system keeps BTC on its native network and uses cryptographic proofs and a challenge process to connect Bitcoin-side collateral events with Ethereum applications. Within Aave, the collateral is represented by vaultBTC, an internal, transfer-restricted ERC-20 accounting unit. It is not designed to trade or transfer like a conventional Bitcoin wrapper.

HashKey Cloud clients are expected to borrow stablecoins against their Bitcoin and deploy the borrowed assets in yield strategies. Specific yield strategies, projected yields, fees and borrowing limits were not disclosed.

Borrowing would use Aave v4’s variable market-based rates. Additional protocol, vault-provider and network fees may apply, and positions could be liquidated if their health factor falls below the applicable threshold.

The proposed architecture includes a lending Spoke and a BTC Vault Swap Spoke. Aave DAO would control parameters and caps, and the integration remained subject to further governance stages, including an ARFC discussion and an Aave Improvement Proposal vote.