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 with fixed destinations at deposit.

Phase 2 replaces the verification layer with BitVM proofs. Active positions migrate to BitVM verification with a single approval and 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.

The vault's key path requires two independent keys: the depositor's and the protocol's. Neither can open it alone, and the protocol's half is itself split across a distributed operator set, so no single party ever holds it whole. No operator, no threshold of operators, and no coalition of all of them can move a depositor's BTC. Any such attempt is missing the depositor's key.

Alongside that lock, every way the vault can settle is pre-signed at deposit with its destination cryptographically committed: BTC can only move back to the depositor or to a registered liquidator, nowhere else. Watchtowers publish the destination-chain conditions that activate a settlement, and a guardian council acts as the trust anchor that can challenge them when required.

The watchtowers are a distributed set of independent operators secured by threshold signing, with a supermajority required for any action. They hold the protocol's half of every vault and co-sign the pre-signed settlement set at deposit. Critically, they exercise no discretion at settlement time: they publish the observed destination-chain state, and the transaction that becomes valid is one the depositor authorised at deposit.

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 — and each member's key is restricted so that it can only ever route funds back to the depositor's vault, never to any other destination. 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 registered 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 settlement paying them is activated and the Vault UTXO is spent into a Validation UTXO. The Validation UTXO has two paths: the depositor sweeps immediately once the guardian council confirms the repayment (a mechanical check against the lending market's own records), or the depositor sweeps unconditionally after a one-day timelock if the council is unresponsive.

The result is that no operator can prevent a repaid borrower from leaving. Release does not depend on any single party's cooperation, and the timelock path holds even if the entire council is offline or hostile.

Liquidation Flow

When a position breaches its liquidation threshold on the lending market, the matching seizure settlement is activated and the Vault UTXO is spent into a Validation UTXO with a timelock. After the timelock expires, the registered 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 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 (at most waving clean settlements through early). 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 settlement that does not match destination-chain reality, anything outside policy), the validator nodes independently sign a contest transaction via their HSMs, 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 for the depositor. Loan settlement on the destination chain is handled separately.

Deposits are protected before they ever enter the vault. Incoming BTC rests in a staging output whose refund path returns it to the depositor unilaterally if activation never completes, and the vault's construction is a deterministic function of public inputs. As a result, the depositor's wallet, any council member, or any third-party auditor can independently recompute what is being signed and compare it before approving. A vault that does not match the standard is caught before it can hold anything.

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, and ultimately anyone who cares to run a node. 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 committing the full space of possible settlements at deposit time, at exact amounts rather than all-or-nothing. When a partial reclaim or partial liquidation is required, the matching settlement executes.

Each settlement 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.

Fresh Vault UTXOs are re-provisioned by a routine refresh ceremony, which also keeps every open position's settlement terms tracking its live debt as interest accrues. The refresh is batched across positions, funded by the protocol, and invisible to users (no action of any kind on the depositor's part). The guardian council validates each refresh the same way it validates initial deposits.

Because every settlement has its destination cryptographically committed at deposit, the trust property holds end to end: even in a worst case scenario the BTC can only be redirected to the depositor (via the council emergency path) or to a registered liquidator. 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:

1. The seizure settles 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).

2. Wrapped BTC is delivered to the Flash Settlement Module.

3. 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 record called vaultBTC is created on the destination chain. The mint is authorized by a Bitcoin light client verifying the deposit directly on the destination chain: a proof that the Vault UTXO exists, is correctly constructed, and is confirmed to the required depth.

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 record is bound to a specific set of Bitcoin UTXOs with specific spend paths. For compatibility with lending markets that read collateral as a token balance, vaultBTC is exposed through a transfer-restricted representation that moves only between authorized protocol contracts — it is an accounting device, never a tradable claim.

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 initial state: BitVM Verification with guardrails

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 settlement backstop 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, the watchtowers stop deciding when a liquidation may proceed. That authority moves to a cryptographic proof of the lending position's state, verified on Bitcoin via BitVM's optimistic challenge protocol: a claim is posted, any party can challenge it within the contest window, and invalid proofs are caught with mathematical certainty. The watchtowers remain only as co-signers of the vault's two-key lock and as operators of the routine refresh. Those roles hold no discretion over outcomes.

The guardian council's liquidation-review role retires with that change. The council remains as the challenger of record for releases and as the backstop against faults in the proving stack itself, and its scope narrows further with each construction version as the proving system demonstrates maturity in production. Guardian council retirement is a mechanism with measurable conditions.

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.

vaultBTC, the Flash Settlement Module, and the lending market integration remain unchanged. Existing positions continue under their original verification model until they migrate — and migration is a single approval, surfaced in the app, never a withdraw-and-redeposit cycle. New deposits use BitVM verification by default, with no change to how users interact with the protocol.

Phase 2 end state: Full BitVM verification

In the end state, the challenger role opens to everyone. Anyone can post a bond, run a node, and defend the protocol: lenders can guard their own capital, and borrowers can guard their own positions. Releases become self-service assertions that settle unless someone proves them false. The named institutional guardian council dissolves into a permissionless network, and the trust assumption collapses to Bitcoin consensus, destination-chain consensus, and the standard assumption that at least one honest challenger is online during the challenge window.

For further technical details and integration opportunities with Bitcoin Collateral Vaults, contact the Zest Protocol team.