Do you know that only 1% of Bitcoin is using DeFi?

Decentralized finance (DeFi) is a superior financial system compared to its centralized and traditional counterpart in terms of transparency, efficiency, and accessibility. As a result, it offers many benefits, such as higher yield, lower borrowing costs, faster settlement times with 24/7 availability, etc.

However, unlike most other crypto assets, only 1% of Bitcoin is using DeFi, which is a pity for both Bitcoin and DeFi. Why so low?

In this article, we unfold the problem behind this low engagement and introduce Babylon’s solution to this problem: a trustless BTCVault protocol that allows native Bitcoin to use DeFi in a self-custodial and trustless way. With this protocol, using Bitcoin for DeFi becomes as safe as using ETH for DeFi.

The article is organized into relatively independent sections. Please feel free to jump to the sections that interest you.

1. Trustlessness: The Wall Between Bitcoin and DeFi

Decentralized finance (DeFi) is more transparent, efficient, and accessible than its centralized and traditional counterpart. A defining feature of DeFi is that it eliminates the need for a trusted counterparty.

For example, when you use ETH in a DeFi product on the Ethereum chain, you only need to trust:

1. the Ethereum chain,
2. the smart contracts of the DeFi product, which use code to define how your ETH will be used, and
3. in certain DeFi products, on-chain oracles (such as a price oracle).

There is no trusted counter-party that can bypass the above and seize your ETH.

The same trust can be assumed for almost all crypto assets, with one exception: Bitcoin.

The Bitcoin chain itself is neither programmable enough nor performant enough to host DeFi products for Bitcoin the asset, so Bitcoin holders should participate in DeFi elsewhere. For this to work, they will need to trust:

1. the Bitcoin chain
2. the DeFi chain (say Ethereum)
3. the smart contracts of the DeFi product and associated oracles
4. a Bitcoin bridge or wrapper, which custodizes the Bitcoin for the Bitcoin holder and issues a synthetic Bitcoin for the Bitcoin holder on the DeFi chain for DeFi usage. This custodian could be one entity (Bitglobal, Coinbase, etc.), or a set of entities (under different names such as validator set, committee, or consortium).

“Wait a second”, you might have already noticed, “I am totally fine with 1-3, but what the heck is 4? The custodian can bypass 1-3 and seize my Bitcoin!”

You are exactly right, no one likes this extra trust. It is like trusting a gift card issuer.

Unfortunately, this has been a necessary trust due to the lack of programmability of the Bitcoin chain. To use DeFi, Bitcoin holders have to surrender their native Bitcoin in exchange for a programmable synthetic Bitcoin issued by a custodian on the destination chain. The custodian has full control of the native Bitcoin, including its redemption.

Due to this extra trust, Bitcoin’s participation in DeFi is extremely low at only ~1%.

To increase Bitcoin’s DeFi participation, we have to eliminate this trust and come up with a trustless protocol for Bitcoin holders. But how?

2. The Key to Trustlessness: Programmable Transfer of Bitcoin

Finance is about assets changing hands following certain rules. For example, in lending, the collateral asset is returned to the borrower if the borrower repays the loan on time, or is transferred to a liquidator in case of liquidation. For another example, an insurance payout is made if and only if a claim is verified.

Smart contracts can eliminate trust in DeFi because they use codes (instead of a trusted party) to programmably specify and verify these conditions and enforce the transfer accordingly.

Therefore, to achieve trustlessness for Bitcoin DeFi, the key is to allow the ownership transfer of native Bitcoin to be programmable through smart contracts on the DeFi chain.

The Babylon trustless BTCVault protocol makes this a reality.

3. What Is a Vault?

We start the introduction of Babylon trustless BTCVault (TBV) from the definition of a vault.

“Does this need a dedicated section? Vault is common concept, right? It is a safe device that I can put my precious in. I have the sole control of it.” You may ask.

Not, it is not common. If you ask a DeFi expert, their answer will be very, very, different:

“A vault is an on-chain capital pool that allows people to deposit crypto into. The vault runs DeFi strategies to (hopefully) help the depositors earn yield.”

Very different, indeed opposite definitions: it is segregated vs. co-mingled.

Babylon trustless BTCVault is akin to the former. More specifically:

1. The bitcoin is locked in a Bitcoin script created by the Bitcoin holder, just as you would put your precious in a physical vault. There is no bridging or wrapping of the asset into another asset.
2. Bitcoins in different vaults are segregated, i.e., no pooling or fungibility, just as you would never share your physical vault with strangers.
3. The bitcoin in the vault can only be used in and controlled by the DeFi product that the Bitcoin holder specifies. No one can rehypothecate the bitcoin, just as you would never allow the content in your physical vault custodized in a bank to be used by the bank as its own collateral.

4. A Technical Premier of Babylon Trustless BTCVault

The Babylon trustless BTCVault protocol allows smart contracts on a DeFi chain to control the collateralization and transfer of native Bitcoin on the Bitcoin chain. It is built upon several cryptographic primitives and Bitcoin script.

“Errr … I am not technical. May I excuse myself?”

For sure. Please feel free to skip this section and head into the next section about TBV’s product features. This section explains the technical reasons behind these features to curious geeks.

4.1 The Buidling Blocks

At the abstract level, what the Babylon trustless BTCVault protocol does is translation. It translates what has happened on a DeFi smart contract to something simple enough that the Bitcoin chain can understand and react to.

The key technical enablers are:

1. SNARK (Succinct Non-Interactive Argument of Knowledge), which enables succinct proof verification of the execution of any program. We use it for the verification of state transitions of TBV-related smart contracts (which decide the ownership of the bitcoin in each vault) on the DeFi chain.
2. Garbled circuits, which can reduce the proof verification of an arbitrary program into secret revelation. We use it to encode the SNARK verifier such that evaluating the garbled circuit on a proof reveals a specific secret label if the proof is valid. This secret label is simply a text string that the Bitcoin chain is capable of processing.
3. Lamport signature, which is a one-time signature scheme whose verification can be implemented using Bitcoin script. We use Lamport signature to allow the Bitcoin chain to verify disputes in case there is one.
   More specifically, we use Lamport signature to encode the inputs for garbled circuits evaluation, and upload the signature to the Bitcoin chain, so that in case of dispute, the garbled circuits' inputs can be put on the Bitcoin chain and verified by the Bitcoin chain.
4. Bitcoin script, which is the Bitcoin chain’s built-in programming language with limited programmability. In particular, we rely on:
   1. Hash lock, which allows a UTXO to be spendable only if the pre-image (which is a text string) of a given hash is provided. We use it with garbled circuit’s secret revelation to control the transfer of Bitcoin;
   2. Time lock, which allows a UTXO to be spendable only after a certain time period has passed. We use it to create the time buffer needed by the protocol participants to verify and dispute the SNARK proofs.
   3. Taproot address: which allows one UTXO to have multiple spending paths through Merkle tree encoding.

4.2 Putting Them Together

We use SNARK (more precisely, Groth16), garbled circuits, and Lamport signature to reduce DeFi smart contract execution results and their disputes into the revealing of different text strings on the Bitcoin chain. This reduction allows the Bitcoin holder to lock Bitcoin in a Bitcoin script (a vault), and then use Bitcoin script and this revelation mechanism to construct a transaction graph for the locked bitcoin, such that:

1. Every withdrawal claim of the locked bitcoin is disputable through challenging;
2. In case the claim is challenged, whether the locked bitcoin can be withdrawn by the claimer depends on whether the proof is valid or not.

This way, the transfer of the locked bitcoin is fully decided by the DeFi smart contracts, without needing any trusted third party.

Most computations and communications occur off-chain, including SNARK proof generation, garbled circuit setup and evaluation, etc. On-Bitcoin-chain footprint is minimized to data and signature commitment and secret revelation.

TBV has two constraints inherented from the techniques used:

1. pre-set participants: both the set of claimers of the bitcoin and the set of challengers have to be pre-defined. This is because a garbled circuit can only allow pairwise dispute resolution. Therefore, to make sure every claim is challengeable, the identity (i.e., Bitcoin address) of all the claimers and challengers has to be determined when a vault is created.
2. claim delay: since the protocol relies on challenges to prevent malicious claims, a configurable challenge period (can be a few hours to 1 to 2 days) is needed to give challengers enough time. In other words, the claim of bitcoin comes at a delay instead of being instant.

4.3 A Toy Example of TBV

For a toy example, Alice could create a TBV with one bitcoin and specifies that:

1. If a roll-a-dice smart contract on the Ethereum chain rolls 1-3, Alice’s Bitcoin address can claim this bitcoin,
2. If this smart contract rolls 4-6, Bob’s Bitcoin address can claim this bitcoin.

Then, in case the smart contract rolls 1-3, Alice can claim her bitcoin back. In case Bob falsely claims the bitcoin, Alice can block Bob by challenging him on the Bitcoin chain. To be unblocked, Bob will have to submit the SNARK proof of a valid claim to the Bitcoin chain, which he does not have. Thus, Bob can never steal the bitcoin from Alice.

Under this set up, the bitcoin ownership transition conditions are fully programmed, and Alice only needs to trust:

1. the Bitcoin chain and the Bitcoin script written by herself.
2. the Ethereum chain
3. the roll-a-dice smart contract

No one can bypass the above and seize the bitcoin from Alice. The protocol is therefore trustless to Alice.

Acknowledgement: The Babylon trustless BTCVault protocol is heavily influenced by the BitVM3 technology. The Babylon Labs team keeps evolving the protocol through open-source collaborations in both the industry (such as with BitVM Alliance) and the academia.

5. A Product Intro of Babylon Trustless BTCVault

TBV itself is not a DeFi product. Rather, it is a primitive that enables endless DeFi product possibilities with Bitcoin. In this section, we will describe the product characteristics of TBV. Then in the next section, we will showcase a few TBV-enabled DeFi products for inspiration.

At the high level, TBV is applicable to any DeFi products where:

1. the asset (bitcoin) is collateralized, and
2. who will own and claim this collateral is decided by smart contracts.

Diving deeper, TBV has a few special features and constraints:

1. Pre-set claimer: The set of parties that could claim and withdraw the bitcoin from a vault must be defined when the vault is created. Claiming from anyone not in this set is not allowed.
2. Pre-set target DeFi product: The smart contract that can decide the bitcoin ownership is pre-defined when the vault is created. As a result, each vault is exclusively used for the DeFi product associated with this smart contract. Other DeFi products have no direct access to this vault.
3. No pooling. Bitcoins locked in different vaults are segregated and not co-mingled.
4. A configurable claim delay (minimum a few hours): This is to give the vault participants enough time to dispute malicious claims. Consequently, a legitimate claimer will only receive the bitcoin after this delay.

In other words, TBV turns Bitcoin into a universal programmable collateral for any DeFi. The collateral bitcoin is not bridged/wrapped/pooled/fungible, nor can it be rehypothecated.

In terms of applicable DeFi chains, TBV works with any blockchain/rollup that has a ZK light client.

6. Examples of TBV-Enabled Products

In this section, we showcase a few DeFi products that can leverage TBV. We will provide greater details to the first product (lending) to demonstrate an end-to-end system, and will keep the remaining ones high-level.

6.1 Bitcoin-Backed Lending

Lending is the most intuitive DeFi product that can leverage TBV.

In its basic form, a Bitcoin holder who wants to borrow USDC on Ethereum can create a vault, where:

• they lock some bitcoins in this vault as the collateral,
• they set the claimers of this vault to include themselves and the USDC lending pool’s liquidators,
• they specify that the final owner of the locked bitcoins depends on the lending smart contract’s execution result on Ethereum:
  • if the Bitcoin holder pays off the loan on time, then they retain the ownership of the collateral bitcoins.
  • In case of default or Bitcoin price falls too low, the liquidator that liquidates this loan position becomes the owner of the collateral bitcoins.

This basic lending has several limitations:

1. No partial liquidation. The collateral can only be liquidated as a whole.
2. Permissioned liquidator set. But ideally, the liquidation should be permissionless to maximize its success rate and minimize bad debts.
3. Capital front-loading and price risk: Due to the challenge period, there is a gap between when a liquidator pays back the loan and when they get the collateral bitcoin and sell it. This means that the liquidator needs to reserve capital for the future liquidation (which has opportunity cost) and is also exposed to Bitcoin price volatility during the challenge period. This issue is particularly problematic for lending products where atomic liquidation (i.e., complete the entire liquidation flow in one block) is preferred.

Partial liquidation can be achieved by simply allowing a Bitcoin holder to use multiple vaults to create one loan position.

The permissioned liquidator set issue and the capital front-loading issue can be solved together by implementing a proxy liquidation asset pool such as wBTC. More specifically, take BTC-USDC lending for example, there will be two lending pools:

1. a USDC lending pool, which accepts TBV as collateral, and has permissionless liquidators as usual.
2. a wBTC lending pool, which accepts TBV as collateral, and has the set of claimers of the TBV as its permissioned liquidator set.

Then in case of liquidation, anyone can execute the following transactions within one block to achieve permissionless and atomic liquidation of the USDC loan:

1. borrow wBTC from the wBTC pool
2. sell wBTC on spot and get USDC
3. use this USDC to repay the loan and obtain controllership of the corresponding vault
4. pledge this vault for the wBTC pool

A liquidator of the wBTC lending pool will then liquidate this wBTC loan by claiming native Bitcoin from the vault (it can because it is a claimer of the vault) and convert it to wBTC to repay the wBTC loan. Such liquidators can arbitrage and earn native BTC yield as long as the wBTC borrowed is less than the size of the vault. Such liquidators are thus called arbitrageurs.

This solution enables permissionless liquidation for the USDC loan. It also solves the capital front-loading issue because in large lending protocols such as Aave, there is already a large wBTC pool that is mostly idle and not receiving any meaningful yield (thus very cheap to borrow). This solution also eliminates the BTC price volatility risk because the loan existing during the challenge period is wBTC-BTC.

6.2 Bitcoin-Backed Stablecoin

TBV enables Bitcoin to serve as first-class collateral for collateralized debt position (CDP)–based stablecoins without requiring BTC to be bridged, wrapped, or rehypothecated. Rather than prescribing a single stablecoin design, TBV provides a standardized, programmable vault layer that stablecoin issuers can integrate directly into their own minting and risk frameworks.

Each TBV vault represents a segregated, non-custodial Bitcoin position with explicit ownership, withdrawal conditions, and liquidation logic. Stablecoin protocols can reference these vaults as collateral sources, enforce protocol-specific collateralization ratios, and trigger liquidations when risk thresholds are breached — all while the underlying BTC remains verifiably locked and economically isolated.

As a result, TBV allows multiple CDP-based stablecoins — including USD-pegged, multi-currency, or synthetic asset designs — to be backed by Bitcoin simultaneously, without shared risk, balance-sheet entanglement, or protocol-level exclusivity.

6.3 Bitcoin Options

Bitcoin holders can collateralize their Bitcoin and sell call options using TBV to generate revenue. Their bitcoin will only be programmatically transferred to the buyer of the call option if the Bitcoin price exceeds the threshold set by themselves and the buyer exercises the option.

6.4 Insurance / Reinsurance with BTC as the Cover Asset

TBV enables Bitcoin to function as a native reserve and payout asset for on-chain insurance and reinsurance markets. Rather than relying on fragmented capital pools or synthetic guarantees, insurance protocols can lock Bitcoin into segregated TBV vaults that explicitly underwrite defined risk exposures.

Insurance buyers — including DeFi protocols, bridges, and infrastructure providers — pay premiums into insurance contracts backed by Bitcoin reserves. These premiums accrue to BTCVault participants as yield, while coverage terms, claim conditions, and payout logic are enforced programmatically.

In the event of a covered incident, Bitcoin locked in the relevant vaults can be programmatically released to satisfy claims, according to predefined rules. Reinsurance providers can similarly allocate Bitcoin to higher-layer coverage pools, absorbing tail risk across multiple insurance markets while remaining fully collateralized and transparently accounted for.

This structure separates risk underwriting from Bitcoin custody, allowing insurance issuers to design differentiated products — such as smart contract failure coverage, oracle risk, or protocol insolvency protection — while relying on TBV for secure collateralization and deterministic claim settlement.

Bitcoin holders can allocate capital across multiple insurance and reinsurance products, selecting distinct risk–return profiles based on coverage scope, duration, and loss probability. The result is a capital-efficient, Bitcoin-native insurance stack that transforms BTC from a passive asset into programmable risk capital without compromising security or custody guarantees.

7. Business Opportunities

TBV brings Bitcoin holders to the DeFi world for safe yields. There are various types of business opportunities available.

7.1 Sourcing Bitcoin

Bitcoin holders do not have to use any Babylon “official” frontends to create TBV and use TBV DeFi products. Rather, Babylon Labs provides all the necessary SDK, tooling, and API for anyone to create their own frontends to access the protocol.

This way, entities with Bitcoin customers (such as custodians and exchanges) can create their own frontends for their clients to create TBV and use TBV DeFi products. This could allow them to charge fees from both the vault creation/closure and the DeFi usage via the frontends.

7.2 Building/Integrating DeFi Products With TBV

TBV works for any DeFi product that wishes to use bitcoin as a collateral asset. In the last section, we have shared a few possible applications (lending, stablecoin, options, insurance), but there’s no limit to the technology’s potential.

From the development perspective, the TBV protocol is designed with a modular architecture. A dedicated TBV manager contract handles the complexity of interacting with Bitcoin, BitVM, zero-knowledge proofs, and cryptography. This allows DeFi projects to focus on what they do best: building DeFi products and logic through smart contracts, without needing to manage Bitcoin-level technical details.

More specifically, the TBV manager smart contract serves as a gateway between the TBV protocol on Bitcoin and DeFi products. It provides a standardized interface that:

• Handles all Bitcoin-related functionality, including vault registration, vault verification, and the secure redemption of the vault’s contents.
• Allows DeFi projects to apply for access to TBV, specifying both technical parameters and fee models.
• Enables DeFi products to define the redemption rules for the vaults integrated with them, supporting arbitrary programmability over redemption conditions.

DeFi projects could freely choose between:

• building a brand-new DeFi product tailored for Bitcoin, which directly interacts with the TBV manager;
• integrating TBV with an existing DeFi product by developing a proxy program in the middle.

7.3 Provide Infra and Capital Service

The TBV protocol involves tech-savvy operations by multiple parties, such as the creation and verification of Bitcoin scripts, garbled circuits, ZK proofs, claims, as well as 24/7 monitoring of the system and generating challenges. Therefore, there is an opportunity to provide vault-keeping service to improve the efficiency and robustness of the protocol:

• Bitcoin holders could pay third-party vault keepers (instead of running one themselves) for the creation and maintenance of vaults, so that their own engagement remains light at the wallet signature level. Note that vault keepers cannot steal Bitcoin from the Bitcoin holder, because the claim destination and claim conditions of the bitcoin are both set by code.
• Certain DeFi products require a set of vault keepers to enforce the settlement of the bitcoin, such as the arbitrageur set in the lending application mentioned above. Such vault keepers can make money from liquidation and arbitrage opportunities.

There are also public good services such as universal vault challengers that the system could subsidize.

Due to the claim delay of TBV, for DeFi products where fast (or even atomic) liquidation of the collateral is needed, market makers with sufficient capital could be the liquidator and make profit.  

7.4 Offer Downstream DeFi Products to Bitcoin Holders

By using TBV-integrated DeFi products, Bitcoin holders will acquire stablecoins and other digital assets. They could then further deploy such assets to other DeFi products such as yield products to potentially amplify their returns according to their risk appetite. The TBV system provides a convenient interface for such integrations to bring a smooth and comprehensive experience for Bitcoin holders.

7.5 Wrap Bitcoin DeFi Products

Being decentralized, the end-to-end TBV-enabled Bitcoin DeFi product flow is publicly accessible and thus can be white-labeled. This allows entities (such as neo banks and custodians) to wrap the entire system or a subset of it into customized products. For many Bitcoin holders, the ultimate product is a one-click yield product.

8. Future Outlook

The crypto industry has invented amazing products for the world, such as DeFi, stablecoin, and RWA (real-world-asset) tokenization. The future of finance is on-chain.

Babylon trustless BTCVault protocol brings this exciting future to Bitcoin. It enables native Bitcoin to use DeFi and other on-chain products trustlessly and self-custodially. Using native Bitcoin will become as safe and convenient as using ETH.

Over time, Babylon trustless BTCVault protocol will become Bitcoin’s main gateway to the on-chain world.

‍