# How Zest Protocol brings Bitcoin Collateral Vaults to mainnet
BitVM-verified Bitcoin Collateral Vaults are the endgame. However, BitVM is not production-ready today. Operator choreography is still maturing, proving stacks are stabilizing, and mainnet tooling does not yet exist.
At Zest Protocol, we are not waiting.
Zest Protocol ships Bitcoin Collateral Vaults in two phases.
Phase 1 uses pre-signed Bitcoin transactions that constrain where BTC can go.
Phase 2 replaces the trust layer with full BitVM verification. Active positions from Phase 1 move over from their original verification model towards BitVM verification by default, with no change to how users interact with the protocol.
Phase 1 exists to get the Bitcoin Collateral Vault infrastructure running on Bitcoin mainnet without being constrained by experimental verifier technology like BitVM or zero-knowledge proofs.
In our view, the core engineering challenge behind shipping Bitcoin Collateral Vaults is not the verifier itself, but rather the cross-chain plumbing: vault construction, UTXO management, spend path enforcement, liquidations, and the collateral lifecycle between Bitcoin and the destination chain.
All of this needs to be battle-tested with real positions and real capital before adding an experimental verification layer on top. Layering in BitVM or zero-knowledge verification on top of infrastructure that has not yet proven itself in production compounds risk unnecessarily.
It's perfectly possible to ship a working product today with mature verification stacks. Threshold signing is well-understood and battle-tested, which lets us prove out the full vault and collateral lifecycle now, then swap in BitVM or zero-knowledge verification later, once those stacks are production-ready.
#### Phase 1: Pre-signed Bitcoin Collateral Vaults with Constrained Spend Paths
In Phase 1, each Bitcoin Collateral Vault is a Taproot UTXO on Bitcoin constructed at deposit time. Spend paths for the BTC are constrained: BTC can only move back to the borrower or to an institutional liquidator, nowhere else. Watchtowers decide when which spend path is invoked, and a guardian council acts as an initial trust anchor that can challenge the watchtowers when required.
Watchtowers is a large distributed network secured by threshold signing. At deposit, the watchtowers produce a set of pre-signed transactions called variants (for example, 10 Reclaim brackets sending 10%, 20%, ..., 100% to the depositor, and 10 Seizure brackets sending the same brackets to the named institutional liquidator). Every variant has its destination cryptographically committed at deposit time. The watchtower broadcast the appropriate variant when destination-chain conditions warrant action.
The guardian council is a small set of named, reputable institutional parties. It uses standard institutional multisignature infrastructure, not a threshold signature scheme, so each council member can operate independently with their own security module. The council is the user-facing trust anchor: a small, reputable, accountable set of institutions that the user can point to when deciding whether to trust the system.
The Vault UTXO can be spent in exactly two directions: back to the depositor or to the named liquidator. The watchtowers pre-signed variants are the spend paths for those two directions. There is also a single council emergency path that can spend the Vault UTXO to a hardcoded depositor failsafe address. No other destination is reachable from the Vault UTXO.
**Reclaim Flow**
When a borrower repays their loan on the lending market, the watchtowers broadcast the appropriate Reclaim variant. The Vault UTXO is spent and a Validation UTXO is created. The Validation UTXO carries a timelock. After the timelock expires, the depositor can sweep the BTC.
During the timelock window, the guardian council monitors the destination chain. If the council's automated validator software detects that the loan has not actually been repaid, the council intervenes via the Validation UTXO's emergency path. The BTC is rerouted to the depositor's failsafe address.
**Seizure Flow**
When a position breaches its liquidation threshold on the lending market, the watchtowers broadcast the appropriate Seizure variant. The Vault UTXO is spent and a Validation UTXO is created with a timelock. After the timelock expires, the named liquidator sweeps the BTC and the liquidation completes.
During the timelock window, the guardian council monitors the destination chain. If the council's validator software detects that the position is not actually unhealthy, the council intervenes. The BTC is rerouted to the depositor's failsafe address. The liquidator never receives it.
**The Guardian Council as Optimistic Challenger**
The council does not gate any normal operation. On the happy path, the council does nothing. The watchtowers run everything.
The council acts only when its automated validator software detects a violation of protocol policy. Each council member runs an independent validator node that watches Bitcoin and the destination chain continuously. When a violation is detected (a vault construction that does not match the standard, a variant broadcast that does not match destination-chain reality, anything outside policy), the validator nodes independently sign a contest transaction via their HSMs. The council's threshold is met by these independent signatures, and the contest is broadcast.
Every council intervention has the same outcome: BTC is rerouted to the depositor's failsafe address. There is no separate adjudication step. The council's job is to detect violations and recover funds to the depositor. Loan settlement on the destination chain is handled separately.
The council's emergency path is also available on the Vault UTXO itself, with a deposit-validation window enforced at the script level on every variant. For the first window after deposit, no variant can be broadcast yet, giving the council time to verify that the Vault UTXO's construction is correct. If the watchtowers produce non-standard variants at deposit, the council catches it and recovers funds to the depositor before any variant can act.
This mirrors the trust shape of the BitVM endgame: the system runs optimistically by default, with a credible challenger as the safety mechanism. In Phase 1 the challenger is a small set of named institutions. In Phase 2 the challenger becomes a cryptographic proof. The architecture is the same.
**Partial Withdrawals and Partial Liquidations**
Bitcoin UTXOs are atomic. You spend the whole output or nothing. A naive vault holding all of a depositor's BTC could only be fully reclaimed or fully liquidated.
Bitcoin Collateral Vaults solve this by pre-signing a set of spend variants at deposit time, at fixed percentage brackets. The watchtowers produce Reclaim variants and Seizure variants (the same brackets to the named liquidator). When a partial reclaim or partial liquidation is required, the closest matching variant is broadcast. Slight over-liquidation rounds up to the nearest percentage bracket, with any surplus returned to the depositor at settlement (a pattern already common in standard DeFi lending markets).
Each variant has two outputs: the requested amount goes to a Validation UTXO bound for the depositor or liquidator after the timelock, and the remainder returns to a fresh Vault UTXO at the same vault address. After a partial action settles, the depositor's position continues in the fresh Vault UTXO with the remaining collateral.
The fresh Vault UTXO has no pre-signed variants of its own. To enable further partial actions on the same position, the watchtowers run a refresh ceremony, producing the set of new variants for the fresh vault. The guardian council validates the refresh during a contest window the same way it validates initial deposits. Most positions never need a refresh: a position is either reclaimed in full, liquidated in full, or held without any partial actions.
Because every variant has its destination cryptographically committed at deposit time, the trust property holds end to end: even under post-deposit compromise of the watchtowers, the BTC can only be redirected to the depositor (via the council emergency path) or to the named liquidator (via a Seizure variant). It cannot be sent anywhere else.
**Flash Settlement for Atomic Liquidations**
Bitcoin Collateral Vaults have an inherent timing problem. The seizure flow on Bitcoin takes hours to days (timelock plus Bitcoin confirmation time). DeFi liquidators need instant collateral to close their arbitrage. Without a solution, flash loan liquidators are excluded entirely, the liquidator pool shrinks to a small number of capitalized firms, and liquidation bonuses must increase to compensate for capital lockup and hedging costs. Higher bonuses mean depositors lose more collateral on every liquidation.
Zest Protocol solves this with a Flash Settlement Module: a smart contract on the destination chain that absorbs the time delay between the EVM liquidation and the Bitcoin settlement.
The mechanism works in two stages.
Instant execution (single EVM transaction):
1. A liquidator flash-borrows stablecoins and calls the Flash Settlement Module, targeting a specific unhealthy position.
2. The module repays the position's debt on the lending market and receives the Bitcoin Collateral Vault's collateral claim (vaultBTC).
3. The module posts the vaultBTC as collateral and borrows wrapped Bitcoin (cbBTC, wBTC, or other) from a dedicated pool on the lending market.
4. The module sends the borrowed wrapped Bitcoin to the liquidator.
5. The liquidator swaps the wrapped Bitcoin to stablecoins on a DEX and repays the flash loan, keeping the liquidation bonus minus gas and fees.
Asynchronous settlement:
6. A watchtower broadcasts the seizure transaction on Bitcoin, moving BTC from the Bitcoin Collateral Vault to the liquidation settlement address (a counterparty who uses this BTC to mint the wrapped BTC version that was borrowed in step 3).
7. Wrapped BTC is delivered to the Flash Settlement Module.
8. The module repays its wrapped BTC loan plus interest. Any surplus is returned to the depositor.
Each liquidation creates an isolated position within the Flash Settlement Module. There is no shared state between liquidations. The watchtower triggers Bitcoin settlement immediately to minimize price exposure.
This design preserves standard DeFi liquidation economics (\~2% bonus) instead of the elevated bonuses required when settlement is delayed. Depositors keep more of their collateral. Liquidators keep their existing flash loan tooling.
Two safeguards sit behind this flow. First, the conditions under which the watchtowers may trigger a seizure are deliberately strict: liquidations only translate to Bitcoin seizure when the position is unambiguously unhealthy under multiple oracle confirmations, so the guardian council's contest path is rarely invoked. Second, an insurance fund backstops the wrapped BTC pool against any settlement shortfall, including the corner case where a seizure is contested by the guardian council and rerouted to the depositor failsafe after flash settlement has already executed. Together, these protections keep depositors and wrapped BTC suppliers protected from edge-case failures while preserving the instant-settlement experience for liquidators.
While wrapped BTC is used, the beauty of the system is that borrowers aren’t exposed to wrapped BTC unless their position is liquidated. BTC collateral never has exposure to wrapped BTC on the happy path.
**Collateral Representation**
When BTC is deposited into a Bitcoin Collateral Vault, a non-fungible collateral token called vaultBTC is minted on the destination chain. The mint is authorized by a threshold attestation from the watchtowers confirming that the deposit is final on Bitcoin and that the Vault UTXO is correctly constructed. vaultBTC is not a fungible bridge token. It represents a specific vault's collateral position and grants its holder the right to trigger a reclaim or be subject to seizure. It cannot be freely transferred like wBTC or cbBTC because each token is bound to a specific set of Bitcoin UTXOs with specific spend paths.
This is a deliberate design choice. vaultBTC preserves self-custody, unilateral withdrawal rights, and full segregation of funds. The Flash Settlement Module is the mechanism that bridges the gap between non-fungible Bitcoin Collateral Vault claims and the liquid collateral that flash loan liquidators require.
#### Phase 2: Full BitVM Verification
Phase 1's two groups (watchtowers and guardians) were the operational and trust scaffolding we needed to ship on Bitcoin mainnet today. The Phase 1 architecture was specifically designed to mirror the BitVM endgame trust shape so the upgrade is structurally continuous: same optimistic execution by default, same credible challenger, same contest window, same end destinations.
Phase 1 does the heavy lifting that Phase 2 inherits. By the time BitVM verification is swapped in, the cross-chain plumbing has been battle-tested with real positions and real capital: vault construction, UTXO management, partial liquidations and refresh ceremonies, the Flash Settlement Module, the lending market integration, oracle confirmation logic, and insurance fund sizing.
Phase 2 changes only the verifier. Everything around it is already proven in production, which is why Phase 2 ships as an upgrade rather than a relaunch. New deposits land on a system whose collateral lifecycle, liquidator network, and operational tooling are mature on day one. The verifier swap is also de-risked by Phase 1 itself: every operational edge case the guardian council catches in production becomes a labelled test vector for the BitVM circuit before activation.
In Phase 2, we replace both watchtower and guardian groups.
The guardian council is replaced by BitVM. The challenger role moves from a small institutional backbone to anyone who can construct a valid fraud proof. The watchtowers’ role of producing pre-signed variants drops away because BitVM proof verification gates the vault's spend paths directly; no pre-signing or threshold signing is required to authorize a spend.
When a reclaim or seizure is triggered, the initiating party submits a cryptographic proof that the corresponding event (loan repayment, liquidation breach) occurred on the lending market. The proof is verified via BitVM's optimistic challenge protocol on Bitcoin: the claim is posted, any party can challenge it within the contest window, invalid proofs are caught with mathematical certainty. The depositor can serve as their own challenger, so trustlessness does not depend on any external party's liveness.
The user-facing flow is the same as Phase 1: a claim is made, a window passes, the action settles. What swaps is what is inside the contest mechanism, not the shape of the flow itself.
The trust assumption collapses to Bitcoin consensus, destination-chain consensus, and the standard BitVM assumption that at least one honest challenger is online during the challenge window.
vaultBTC, the Flash Settlement Module, and the lending market integration remain unchanged. Phase 1 deposits continue to operate under their original verification model (watchtowers producing variants, guardian council watching as challenger) until they naturally settle and refresh into Phase 2 Bitcoin Collateral Vaults. New deposits from Phase 2 onward use BitVM verification by default, with no change to how users interact with the protocol.
The guardian council is retained as an emergency fallback during the early period after BitVM activation, then phased out entirely as the system proves itself in production.
\
---
# Agent Instructions: Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.
Perform an HTTP GET request on the current page URL with the `ask` query parameter:
```
GET https://docs.zestprotocol.com/start/bitcoin-collateral-vaults/how-zest-protocol-brings-bitcoin-collateral-vaults-to-mainnet.md?ask=
```
The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.