Atomic Liquidations for Native Bitcoin Vaults via Onchain Market Making

Introduction

Native Bitcoin vaults enable trust-minimized BTC collateral for DeFi lending, but they face two key challenges:

• Multi-hour or multi-day settlement times break atomic liquidation flows. The longer the time to settle a liquidation, the higher the financial incentive required to attract liquidators and the higher the collateral liquidated from depositors.

• All-or-nothing liquidations pose a significant financial risk to depositors. Depositors will need to borrow at low LTV ratios, leading to comparably low utilization of the deposited BTC, and might still be at risk to lose all collateral during high market volatility.

We present a protocol that restores partial and atomic liquidations. Partial liquidations are achieved through setting up parallel spending routes on native BTC vaults to liquidate portions of a vault. Atomicity is unlocked by decoupling liquidator execution from BTC settlement, using a (onchain) market maker (OMM) that borrows bridged BTC (wBTC, cbBTC, …) against vault claims. Flash loan liquidations execute instantly while BTC settlement occurs asynchronously.

Use Cases

Native Bitcoin vaults can be used primarily in four ways:

1. Enables lending markets to provide native BTC collateral for stablecoin borrowing.
2. Enables CDP protocols to mint stablecoins secured by native BTC.
3. Enables vault issuers to accept native BTC as deposits, access stablecoin liquidity via the above two means, and generate an effective yield on native BTC.
4. Enables exchanges to use native BTC as collateral while operating in an environment not native to BTC (E.g. EVM).

For Lending Markets

Current DeFi liquidators use flash loans for capital-free, atomic execution:

• Borrow USDC → Repay debt → Receive collateral → Sell on DEX → Repay flash loan (single tx)
• ~60% of liquidation volume uses flash loans (though only ~3% by count) → successful BTC vaults will need to support atomic liquidations

For native BTC vaults with delayed settlement (ranging from hours to days), liquidators face fundamentally different economics.

Liquidator Cost Components:

Critical insight: Flash loan liquidators (~60% of volume) are eliminated entirely in non-atomic settlement. The liquidator pool shrinks from ~2,000+ addresses to ~50-200 capitalized entities (market makers, OTC desks, funds).

Required Liquidation Bonus:

Native BTC vaults with delayed settlement require liquidation bonuses multiple times higher than atomic DeFi to compensate for capital lockup and hedging costs.

The goal is to ensure that liquidations can happen atomically so that the liquidation bonuses can stay low (benefitting the depositors) and settlement times are quick (benefitting the liquidators).

Native Bitcoin Vaults Liquidation Engine

Vault Architecture

Native Bitcoin Vaults use an optimistic design where depositors lock BTC into partially signed UTXOs governed by emulated covenants and receive a tokenized representation on an EVM chain for DeFi use. The system involves three roles:

1. Depositors: Deposit BTC on Bitcoin and can trigger withdrawals anytime at their discretion via pre-signed transactions.
2. Operators: Facilitate vault setup, monitor positions, and trigger liquidations on Bitcoin.
3. Adjudicator set: A security council that only activates during disputes and is operated by a set of high-trust institutions, DAOs, and other parties.

In a simplified view (see Figure 1), one can think of Bitcoin vaults as a set of pre-signed UTXOs that act as one Vault with two outputs: Output 0 = withdrawal (spends to the depositor) Output 1 = liquidation (spends to the liquidation engine deposit address)

Figure 1: Simplified overview of Bitcoin Vaults with a BTC deposit and two outputs to either refund the depositor or liquidate the position.

In Phase 1, the adjudicator set operates as an m-of-n multisig executing off-chain verification and committing verdicts on-chain; in Phase 2, this is replaced by BitVM, where ZK proofs determine validity based on on-chain collateral state, with the adjudicator set retained only as an emergency upgrade mechanism for handling bugs.

On the happy path, withdrawals and liquidations execute after timeouts without the involvement of the adjudicator. When disputes arise, e.g., operators object to a withdrawal or depositors contest a liquidation, the BTC moves to an adjudication vault where the adjudicator set decides among three outcomes:

1. BTC remains locked (invalid withdrawal/liquidation),
2. BTC returns to the depositor (valid withdrawal), or
3. BTC goes to the liquidation address (valid liquidation).

Under the hood, the Bitcoin Vault is more complex (see Figure 2). What is the “Bitcoin Vault” in Figure 1 consists actually of multiple UTXOs:

• The Deposit Vault UTXO has as input a funding transaction by the depositor and two outputs. - Output 0: Can be signed by the depositor and forwards the locked BTC into a Withdrawal Request UTXO. - Output 1: Can be signed by 1 of n operators and forwards the locked BTC into a Liquidation Request UTXO.

• The Withdraw Request UTXO has two outputs: - Output 0: A timelock that forwards the BTC to an address owned by the depositor. After the timelock has passed, the depositor can spend the BTC without submitting another transaction on Bitcoin. - Output 1: Can be signed by 1 of n operators to forward the BTC to the Adjudicator Vault UTXO. Operators would use this if they consider the withdrawal request by the depositor incorrect, i.e., they think that the loan is not yet repaid on the lending market.

• The Liquidation Request UTXO has two outputs: - Output 0: A timelock that forwards the BTC to a liquidation deposit address (more details on this later). That means, unless the depositor or any of the other operators challenge the liquidation, the liquidation deposit address automatically receives the BTC. -Output 1: Can be signed by 1 of n operators or the depositor to challenge a liquidation; e.g., if the depositor has not been liquidated on the lending market but an operator submitted a liquidation transaction on Bitcoin, the depositor would challenge it. The BTC is sent to the Adjudicator UTXO.

• The Adjudicator UTXO has two pre-defined outputs and one output that needs to be generated at runtime: - Output 0: A timelock that forwards the BTC to the depositor. If the adjudicator set does not make a decision, the default decision is that BTC is returned to the depositor. - Output 1: The majority of the adjudicator set sign that it was indeed a valid liquidation and forwarded the BTC to the liquidation deposit address. - Output 2: If it was an incorrect liquidation or an incorrect withdrawal request, the depositor and all non-faulty operators create a new Deposit Vault (called Deposit Vault’ in Figure 2). This Deposit Vault’ has the same setup as the previous Depositor Vaults, minus any faulty operators that triggered the liquidation. In the first iteration, generating this new deposit vault is done at runtime when needed.

A representation of the locked BTC is minted as vaultBTC when the BTC is deposited into the Deposit Vault UTXO via a Bitcoin light client SPV proof. The vaultBTC is burned in two ways:

• Withdrawal (happy path): The depositor pays back their loan(s) and submits the BTC transaction to withdraw the BTC. The vaultBTC is burned using a Bitcoin SPV light client proof once the timelock of the Withdrawal Request UTXO expires.
• Liquidation (unhappy path): The liquidation of the loan is triggered. Then, at least one operator triggers the (partial) liquidation on Bitcoin. Once the BTC are in the liquidation deposit address (a part of) the vaultBTC is burned.

Figure 2: Bitcoin Vault connecting UTXOs in detail.

Quantized Splits for Partial Liquidations

Instead of using a single vault for X BTC deposited, we actually split into N parallel vault instances of equal size (X/N) at deposit time, plus one full-amount instance (X) for the depositor's convenience during withdrawals. Each split uses identical adjudicator mechanics, with disputes resolved independently within each vault split.

The idea of splitting the vaults will help with partial liquidations. It is possible to liquidate parts of the vault while the user can still withdraw funds without mixing the UTXOs.

The split vaults liquidate in parallel or sequentially. For example, if 30% of the X BTC needs to be liquidated initially and we split the X BTC across 10 identical vaults, then 3/10 vaults will be liquidated. Should the LTV ratio continue to decline while the 30% liquidation is being processed, additional vaults are liquidated until a safe LTV is reached.

The number of vault splits scales with deposit size as the Bitcoin onchain costs scale with the number of splits: very small deposits = single vault (no splitting), large deposits = many splits. The lending market’s Target Health Factor maps to the nearest split boundary, always over-liquidating to the next highest split.

WIP analysis: The exact parameters for splitting up different deposit sizes are subject to ongoing analysis, taking into account Ethereum and Bitcoin fees.

Liquidation Deposit Address

For the liquidation deposit address that receives the native BTC, we have three options:

1. Fixed liquidators: If liquidators are well-known parties, their BTC addresses can be included during setup of the Bitcoin Vault. Addresses cannot be updated, and liquidators must be able to receive BTC at those addresses. Only pre-defined liquidators can participate in liquidations.
2. Dynamic via TOOP: Instead of using static liquidator addresses, the liquidation address is a form of multisig controlled by a set of keyshare holders. Once a liquidation occurs, all key shareholders transfer their share of the key to the liquidator. This allows dynamic sharing of the liquidator's BTC addresses during liquidation and provides 1/n security: since all keyshare holders must share their keys, the system only breaks if n-of-n keyshare holders collude (similar to BitVM).
3. (This work) Bridge or market maker deposit: Use a bridge deposit address (wBTC, cbBTC...) or market maker. Instead of managing forwarding of BTC to the liquidators on Bitcoin, we can handle this complexity on the EVM side. For this, we need either a (trusted) market maker that acts as a bridge (BTC in, wBTC out), or a Bitcoin bridge that supports static deposit addresses and mints bridged BTC to a smart contract on the EVM side.

This proposed protocol uses option 3 since handling liquidations on the Ethereum/EVM side offers the most flexibility. For an in-depth explanation/analysis, see previous work by the BOB research team on using bridge deposit addresses for fast/atomic liquidations.

Atomic Liquidation via an Onchain Market Maker (OMM)

Native BTC vault liquidations have a timing mismatch:

• Liquidators need: Instant collateral to close the arbitrage (flash loan model)
• Vault provides: BTC after dispute period (a few hours to a few days) plus 10-60 min settlement (Bitcoin confirmation)

If we take a step back, we want to achieve that:

1. Liquidators should be able to use flash loans to deposit, e.g., USDC into the lending market and receive more value of a liquid asset with sufficient DEX liquidity. This enables them to take a flash loan of USDC, liquidate the position, swap the liquid asset to USDC, and retain a profit.
2. Depositors should still be able to withdraw their remaining BTC with a regular Bitcoin transaction if they repay the remaining open loan.

By design, vaultBTC is not a liquid asset. It represents the underlying collateral value and allows withdrawal and liquidation of BTC but is not easily transferable on the EVM side, since this would require updating Bitcoin's ledger for every transfer / change of ownership. This design comes with significant advantages over fully fungible bridge wrappers (self-custody, permissionless withdrawals, no commingling of funds,...) and is a conscious trade-off.

We employ a trick to achieve atomic liquidations without vaultBTC being fungible by introducing a market maker component. The market maker provides liquid BTC wrappers (wBTC, cbBTC, …) for receiving native BTC during liquidations at a profit.

This market maker can take the shape in two ways:

1. Institutional (off-chain) market makers: Each market maker would provide their BTC addresses, which are permanently linked to the native vaults. In advance, they supply wBTC onchain that can be used in case of a liquidation. When a liquidation happens, the wBTC is borrowed from the market maker. On Bitcoin, the native BTC is transferred to the market maker (at a profit), and the wBTC loan is closed. The market maker handles rebalancing of their BTC and wBTC inventory out-of-protocol.
2. Onchain Market Maker borrowing liquidity from the lending market:The market maker can be implemented onchain as well, utilizing wBTC liquidity in the lending market’s hub for this purpose. The OMM is a smart contract that receives vaultBTC as part of a liquidation and uses it as collateral to borrow wBTC via the vaultBTC Spoke - and in turn delivers the wBTC to the liquidator. The wBTC loan is repaid once the Deposit Vault liquidation transaction is processed on Bitcoin by

• depositing the BTC into a bridge such as wbtc.network and minting wBTC (preferred),
• trading BTC for wBTC via BOB Gateway or an OTC desk,
• or a combination thereof depending on the size of the liquidation.

Each liquidation creates an isolated OMM position; there is no shared state. The OMM can be owned/operated by a DAO (Lending Market, BOB, …).

OMM Atomic Liquidation Protocol

Atomic Liquidation Phase (Single EVM Transaction):

1. Liquidator calls OMM contract with flash-borrwed USDC, specifying the target position to be liquidated
2. OMM calls lending market liquidation using the USDC and receives vaultBTC (OMM registered as liquidation handler)
3. OMM borrows wBTC from a dedicated vaultBTC/wBTC pool at ~90% LTV from the Hub (separate from the user's USDC market)
4. OMM transfers wBTC to the liquidator
5. Liquidator swaps wBTC → USDC on a DEX
6. Liquidator repays flash loan, keeps liquidation bonus (~2%) minus gas/slippage/fees

Settlement Phase (Asynchronous): 7. Operator broadcasts pre-signed Bitcoin transaction that withdraws BTC from the Deposit Vault to the 8. Liquidation Deposit Address (e.g. wBTC minting address) wBTC is delivered to the OMM (either minted via BitGo or traded OTC) 9. OMM repays loan + interest; remaining surplus wBTC is returned to the depositor

WIP analysis: Minimum wBTC mint amounts and economics.

Settlement Timing: Operator triggers the BTC settlement immediately to minimize OMM price exposure. Note that the exposure is limited to the BTC/wBTC pair. The process is (semi-)permissionless, where any operator that participated in the setup of this vault (i.e., has a pre-signed Bitcoin transaction) can trigger the liquidation of Bitcoin. Anyone can become an operator but operators are pre-defined per vault setup.

Dispute Handling: Vault adjudicator remains active. If the liquidation is valid, the OMM position will settle. There are two cases if a liquidation is invalid.

1. False-positive liquidation. There was no liquidation in the lending market but a faulty operator triggered the liquidation on Bitcoin: The BTC stays in the vault and the collateral remains untouched. No loss for anyone, and the faulty operator is getting kicked out of the set of operators (a new Deposit Vault’ is created).
2. Protocol failure. The liquidation indeed happened on the lending market but was rejected by the adjudicator set. This represents a protocol failure as it implies that the adjudicator set was compromised/faulty. The OMM position remains open, and the BTC is a protocol loss.

Economics

Multiple Liquidations: If the health factor drops again, another split liquidates independently.

Scaling: Bounded by wBTC liquidity on the lending market (~$350M capacity at $500M supply). If depleted during stress, it falls back to non-atomic. Extensible to other wrapped BTCs (cbBTC, …) if listed on the lending market and supports fixed BTC deposited addresses.

WIP analysis: OMM tail risk. If wBTC drops during settlement, i.e., wBTC depegs, OMM can be liquidated. Loss allocation: (a) protocol reserve, (b) depositor surplus as first-loss, (c) higher buffer. Modelling in progress.

Trust Model

WIP analysis: Merchant/Market Maker SLA. BitGo typically <24h, no guarantee. An enforcement mechanism may be needed.

Comparison

Conclusion

The OMM protocol restores atomic liquidations using the wBTC bridge or market makers to asynchronously settle the liquidation while liquidators receive wBTC synchronously. Liquidators execute via flash loans at ~2% bonus. Tradeoffs: The protocol requires a temporary over-liquidation that is driven by the max LTV of vaultBTC to wBTC (surplus is returned to depositor), there is a constraint in terms of growth on the wBTC liquidity, and the protocol has exposure on invalid liquidations (but this is also the case for any Native BTC Vault construction).

Short-term, the wBTC approach is a good candidate for the first version of Native BTC Vaults: it allows liquidators to maintain an atomic liquidation flow (USDC in, wBTC out of the lending market, and USDC in and USDC out if a DEX is involved). Depositors retain the ability to unilateral withdraw BTC via a BTC transaction and to preserve the UTXO without commingling funds, overcoming shortcoming of existing BTC bridges. As an added benefit, the presented OMM protocol created an additional use case for borrowing wBTC on the lending market, thereby increasing borrowing rates.

Long-term, the wBTC dependency can be alleviated in two directions: (1) Adding more BTC wrappers that support static deposit addresses (cbBTC, …) could be added. (2) Initially, we mentioned that the liquidation engine deposit address can also be a market maker. Market makers accept native BTC for supplying wBTC. This setup can work particularly well also for other wrappers like cbBTC.