Permissionless BTC-secured loans

Written by: krane, jesse (Asula)

A big thank you to rajiv for reviewing the piece on short notice.

Introduction

Bitcoin is one of the world’s few trillion dollar assets (its market cap at the time of writing is ~$1.9T). Given this, financial infrastructure available to BTC holders is also maturing rapidly. The launch of bitcoin ETFs has made a lot of traditional financial infrastructure available to bitcoin holders. However, ETFs wrap BTC with trusted third-parties making these products somewhat antithetical to the philosophy that gave birth to the asset class. Moreover, there is clearly demand for permissionless financial infrastructure for bitcoin as seen by the virality of Erik Voorhees’ tweet last week:

Permissionless protocol, deposit BTC, borrow stables

Who is building this?

— Erik Voorhees (@ErikVoorhees) November 15, 2024

The product elicited by Erik sounds simple but the specifics were somewhat left to interpretation – some interpreted it as MakerDAO for bitcoin, while others thought it is sufficient to allow borrows against wrapped BTC, to which Erik disagreed. Regardless, it is no clear winning “shape” for permissionless bitcoin-secured borrowing.

Out of the $43b in onchain lending TVL, we estimate <20% of it is bitcoin-secured, this is despite bitcoin being the largest cryptoasset accounting for nearly 60% of all crypto market cap. Despite demand for bitcoin-secured lending and the prevalence of the asset, permissionless bitcoin-secured loans seem to have low adoption relative to other crypto assets.

In this piece, we’ll outline different designs for permissionless bitcoin-secured loans and evaluate their benefits and drawbacks.

Setting the stage

Bitcoin’s consensus rules do not recognize any asset other than bitcoin. This is essential to internalize for our discussion because any asset borrowed against bitcoin would thus, have to live on another domain (a domain could be a blockchain, an exchange or the real-world).

In each of our examples we will explain how features can diverge across the following factors:

• Bridge Design – Since the borrow domain is always external to bitcoin, there is naturally a need for a bridging system or a cross-chain message passing system to do bitcoin-secured loans.
• Collateralization Domain – This refers to where the bitcoin collateral is managed for the duration of the loan. This can be bitcoin itself or a bridged version of bitcoin on another domain.
• Borrowed Asset – Refers to the type of asset being borrowed against bitcoin. For stablecoins this can be either traditional stablecoins (e.g. USDT, USDC) or overcollateralized stables (like DAI).

System 1: The Ideal Design

Given borrowing against BTC isn’t really possible natively on the bitcoin network, we consider a ZK rollup with an overcollateralized stablecoin as the best permissionless design for bitcoin-secured loans. Let’s unpack this based on the visual in the diagram:

Idyllic btc-secured lending

In our opinion, this design achieves best-case security across each axes we mentioned above:

Bridge Design – The defining innovation in rollups is the validating bridge. Validating bridges allow users to unilaterally withdraw from the rollup (this is often referred to as forced withdraw).
Collateralized Domain – BTC is collateralized on the rollup but transactions on the rollup can be performed using the bitcoin network (using forced inclusion of rollup transactions).
Borrowed Asset – The borrowed asset is an overcollateralized stablecoin which is pegged to the US dollar. Since the minting authority is a protocol, it is truly trustless.

Benefits One of the core purposes for onchain protocols is permissionless access to a full-stack of financial products. A complete rollup design can bring this closer to reality for Bitcoiners.

With proof verification occurring directly on Bitcoin, users can unilaterally exit the rollup by submitting force withdrawal transactions. Additionally, because the rollup data is made available on Bitcoin, any user holding the stablecoin can forcibly include their transactions to close their position and withdraw back to Bitcoin.

Drawbacks
No bitcoin rollups are live today since it is not yet possible to build a validating bridge from bitcoin. This makes the above system purely theoretical (although we’re optimistic that rollups on bitcoin will soon become a reality!). Moreover, even if rollups were live, it is extremely challenging to build liquidity for a stablecoin. Given USDT/USDC have large network effects from liquidity, its possible potential borrowers might only want to borrow those stablecoins.

System 2: Using Other Blockchains

The majority of permissionless bitcoin-secured lending today occurs on smart contract platforms whose security is independent from bitcoin. The process involves bridging BTC to the smart contract platform, collateralizing a wrapped format of BTC on said platform and then borrowing against the wrapped BTC:

Lending on independent smart contract platforms

As in the previous example, let’s go through each of factors affecting the security of the design:

Bridge Security - The bitcoin is directly secured by a third-party bridge operator. The operator controls the minting and redemptions of the bitcoin-representation on the collateralization domain. The underlying BTC cannot be accessed by users in case the operator goes down (NB: the role of the bridge operator can itself be decentralized to somewhat reduce risk, but it is extremely difficult to achieve the same level of security as the bitcoin network).
Collateralization Domain - The bitcoin collateral is managed by the protocol on the destination blockchain. Specifically, the collateral lives in a collateral pool managed by smart contracts.
Borrowed Asset – The borrowed asset is a centralized stablecoin, which is issued based on dollars in an offchain bank account operated by the stablecoin issuer.

Benefits
The largest benefit of this design is the reuse of battle-tested lending protocols on other smart-contract platforms like Ethereum. Moreover, since this example showcases a borrow of USDT against the wrapped BTC, the borrower benefits from the large amount of liquidity and social acceptance of USDT.

Drawbacks
In this design the operator-managed bitcoin address is trusted as a 1:1 backing asset for the bitcoin-representation on the collateralization domain. Anyone holding the bridged bitcoin can only claim underlying bitcoin if they are approved to redeem through the operator. The inherent risks here are not only the operator’s ability to secure the bitcoin, but also whether they will allow the holder to redeem the underlying back on Bitcoin.

This is similar in principle to the inherent risks of centrally issued stablecoins – users are subject to the security of the dollars or bank account that is backing the stablecoin. Furthermore, if the user attempted to redeem the stablecoin offchain (similar to redeeming the BTC on Bitcoin) they would need to orchestrate redemptions through the issuer.

Finally, because all of this activity occurs on an independent blockchain, users are both exposed to the safety of the consensus of that blockchain.

In some ways, this design was diametrically opposite to the one we presented first. It is still somewhat permissionless depending on the bridge and lending protocol used. Users should evaluate the benefits and drawbacks of each design before using one or the other.

However, it is completely understandable to not want to bridge your BTC to another domain. So in the absence of rollups, what can we do?

System 3: Another design? Not *ideal*, but not wrapped

The insight that Bitcoiners don’t want to wrap their BTC leads us to a design that roughly resembles:

Intermediate system with collateralization on bitcoin

In this design, BTC is collateralized on the bitcoin network, allowing users to borrow stables on any other blockchain of their choice. A dedicated “Position Management System” manages the BTC collateral and pools of borrowable assets on other blockchain (USDT in this example).

Bridge/Collateralization Domain – The BTC is locked in a UTXO on Bitcoin. The user does not have to worry about consensus on another blockchain or a bridge operator. If designed correctly, such a system would allow the borrower to get back custody of their BTC as soon as they have no liabilities. In the previously described design, users would additionally have to bridge back to bitcoin to regain full custody of their bitcoin. When the user does have liabilities, they are subject to the security of the Position Management System.
Position Management System – An intermediating oracle & accounting system is responsible for monitoring positions and taking actions when relevant. These actions include updating borrow limits for users and enabling liquidations. When the user has an open position, they are relying on this position behaving correctly. Although, escape hatches can be designed for borrowers in case of prolonged inactivity from the system.
Borrowed Asset – In the above example, we use a centralized stablecoin as the borrow asset howoever, any other asset can supported.

Benefits:

• Users must only deposit BTC collateral on bitcoin but can borrow on any chain the protocol supports.
• The user can pay back their loan on any supported chain (NB: This is useful if one borrowing domain experiences liveness failures).
• Since the users access the system with UTXOs on Bitcoin, unilateral system exits can be enabled for certain events, like liveness failure of the Position Management System.

Drawbacks:

• There is still a reliance on other domains, centralized stablecoins and a Position Management System.
• Users cannot easily tap into liquidity on existing protocols.
• Liquidations are performed cross-domain and are thus, complicated.
• Due to long confirmation times for Bitcoin, the user may have to be patient when opening or closing loans (this would be the same if the user was removing bridge risk in our second design).

The core insight with this design is to give bitcoin holders their desired UX of not having to wrap BTC as they borrow stables.

Moving forward

We can summarize each of the above systems based on how they handle risks from each of our initial factors:

The above protocols apply clear criteria for the current and potential future markets that offer more accessible onchain systems for bitcoin-secured loans. Given the growth of BTC in the traditional financial landscape through the ETFs, crypto-native protocols should aim to build competitive financial infrastructure that outcompetes what is offered by traditional financial systems. The original goal for BTC was not to export a cypherpunk asset to tradfi but was to bring as much of traditional finance onchain as possible.