# Permissionless BTC-secured loans

krane and jesse · November 21, 2024 · Bedlam Research
https://bedlamresear.ch/posts/permissionless-btc-secured-loans/

> Exploring the design space for permissionless loans against bitcoin

_A big thank you to [rajiv](https://x.com/rajivpoc) 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)](https://companiesmarketcap.com/assets-by-market-cap/). 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:

<blockquote class="twitter-tweet tw-align-center"><p lang="en" dir="ltr">Permissionless protocol, deposit BTC, borrow stables<br><br>Who is building this?</p>&mdash; Erik Voorhees (@ErikVoorhees) <a href="https://twitter.com/ErikVoorhees/status/1857494039089787307?ref_src=twsrc%5Etfw">November 15, 2024</a></blockquote>

The product elicited by Erik sounds simple but the specifics were somewhat left to interpretation – some interpreted it as [MakerDAO for bitcoin](https://x.com/matthuang/status/1857494595879449021), while others thought it was sufficient to [allow borrows against wrapped BTC](https://x.com/Teleport_DAO/status/1857520023662920102), to which [Erik disagreed](https://x.com/ErikVoorhees/status/1857523063614747084). Regardless, there is no clear winning “shape” for permissionless bitcoin-secured borrowing.

Out of the [$43b in onchain lending TVL](https://defillama.com/protocols/Lending), 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 –** This 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:

> Figure: **Idyllic BTC-secured lending.** Two BTC held on Bitcoin are joined through a validating bridge to two BTC inside a rollup; one of the two lines is an arrow pointing back to Bitcoin. On the rollup the BTC go into the CDP Vault of the protocol, the vault feeds Accounting, and Accounting issues Bitdollars, three green B$ coins held outside the protocol.

1. *Collateral.* Bitcoin's consensus rules do not recognize any asset other than bitcoin, so the BTC is collateralized on the Rollup.
2. *Borrowed asset.* In the Protocol the BTC sits in the CDP Vault, and Accounting issues the borrowed asset against it: an overcollateralized stablecoin pegged to the US dollar. Since the minting authority is a protocol, it is truly trustless.
3. *Bridge.* The defining innovation in rollups is the validating bridge. With proof verification occurring directly on Bitcoin, users can unilaterally exit the rollup by submitting force withdrawal transactions.
4. 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.
In our opinion, this design achieves best-case security across each axis 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 withdrawal).  
**Collateralization 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 forced 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, it’s 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:

> Figure: **Lending on independent smart contract platforms.** BTC in an operator controlled address on Bitcoin is minted by a bridge operator into a blue bitcoin-representation on another blockchain, and redeemed back the same way. On the blockchain the wrapped BTC goes into the protocol's Collateral Pool and on to Accounting, which an Oracle also feeds; Accounting pays out USDT to Borrow. A Bank funds the stablecoin issuer address, which fills the Lending Pool with USDT.

1. *Bridge.* The bitcoin is directly secured by a third-party bridge operator, which mints a bitcoin-representation on the Blockchain against the BTC held in its operator controlled address on Bitcoin.
2. Anyone holding the bridged bitcoin can only claim the underlying bitcoin if they are approved to redeem through the operator; the underlying BTC cannot be accessed by users in case the operator goes down.
3. *Collateral.* The bitcoin collateral is managed by the Protocol on the destination blockchain. Specifically, the collateral lives in a collateral pool managed by smart contracts; the Oracle feeds the protocol's Accounting.
4. *Borrowed asset.* The borrowed asset is a centralized stablecoin: USDT, issued based on dollars in an offchain Bank account operated by the stablecoin issuer, supplies the lending pool.
5. The borrower takes USDT against the wrapped BTC, and benefits from the large amount of liquidity and social acceptance of USDT.
As in the previous example, let’s go through each of the 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 is 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](https://x.com/ErikVoorhees/status/1857523063614747084) 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:

> Figure: **Intermediate system with collateralization on bitcoin.** Two BTC on Bitcoin are locked into two Collateral UTXOs, which both feed a Position Management System (Accounting) that an Oracle also feeds. The system points into the protocol's Lending Pool on another blockchain, which a Bank-funded stablecoin issuer address fills with USDT, and the pool pays out USDT to Borrow.

1. *Collateral.* BTC is collateralized on the bitcoin network: it is locked in a UTXO on Bitcoin, so the user does not have to worry about consensus on another blockchain or a bridge operator.
2. *Position management.* A dedicated Position Management System, an intermediating oracle & accounting system, is responsible for monitoring positions and taking actions when relevant, such as updating borrow limits for users and enabling liquidations.
3. It manages the BTC collateral and the pools of borrowable assets on the other Blockchain, USDT in this example.
4. *Borrowed asset.* In this example the borrow asset is a centralized stablecoin, which the stablecoin issuer supplies to the lending pool; however, any other asset can be supported.
5. Users must only deposit BTC collateral on bitcoin but can borrow on any chain the protocol supports, and can pay back their loan on any supported chain.
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 blockchains (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. However, escape hatches can be designed for borrowers in case of prolonged inactivity from the system. The oracle in the figure supplies the BTC price this system uses to check collateralization.  
**Borrowed Asset –** In the above example, we use a centralized stablecoin as the borrow asset; however, any other asset can be 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:

| **Factor**                   | **System 1**                   | **System 2**                        | **System 3**                          |
| ---------------------------- | ------------------------------ | ----------------------------------- | ------------------------------------- |
| **Bridge Security**          | Validating bridge              | Bridge managed by third party       | Bitcoin + Position Management System  |
| **Collateralization Domain** | Rollup (with forced exits)     | Independent smart-contract platform | Bitcoin                               |
| **Borrow Domain**            | Rollup (with forced inclusion) | Independent smart-contract platform | Independent smart-contract platform   |

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.