How Zest Protocol brings Bitcoin Collateral Vaults to mainnet

BitVM-verified Bitcoin Collateral Vaults are the end state. Introducing that verification layer requires a production-qualified proving system, challenge protocol and operator tooling for this vault construction.

Zest Protocol is not waiting for that end state to launch Bitcoin Collateral Vaults.

The rollout follows two stages:

• Phase 1: customer-authorized Bitcoin transactions with fixed amounts and destinations, activated by event attestations and protected by independent guardians.
• Phase 2: BitVM proofs replace more of the current verification layer once the technology is production-ready.

The central engineering challenge is broader than verification alone. Bitcoin Collateral Vaults require vault construction, UTXO management, constrained settlement paths, liquidations and a collateral lifecycle connecting Bitcoin with the destination chain.

Those systems need to be tested with real positions and capital before an experimental verification layer is added. Threshold signing provides a mature foundation for operating and testing that lifecycle. BitVM-based verification can then be introduced once its proving systems and tooling are 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 cooperative spending path requires two independent signing sides: 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. No operator, no threshold of operators, and no coalition of all of them can invent a depositor’s vault spend. Any spend requires the depositor’s live signature or a transaction they authorized in advance.

Alongside that lock, conditional settlements are pre-signed with exact amounts and destinations, including protected payouts, remaining collateral and depositor surplus. Each transaction is bound to its oracle event. Attesters publish the conditions that activate it, and the Guardian Council acts as the independent trust anchor that can reverse an invalid settlement.

The protocol signers are a distributed set of independent operators secured by threshold signing. They hold shares of the protocol signing side and co-sign the conditional settlement set. Attesters separately publish the observed price and lending-position events. Release and debt-state stamps come from an open, mixed roster of signer, guardian and liquidity-provider participants, with the attester also checking its own finalized observation. The transaction that becomes valid is one the depositor authorized.

The Guardian Council is a small set of named institutional parties in the production design. It uses standard institutional multisignature infrastructure, so each member can operate independently with their own security module. A reversal requires the payout recipient’s pre-signed return transaction and a council quorum. That return fixes the destination to the prescribed vault. The council is the user-facing trust anchor: an accountable set of institutions independently enforcing settlement policy.

The permitted vault transactions fix where the BTC can move. Conditional settlements allocate BTC to protected customer or liquidator payouts and, where applicable, a fresh remainder vault. A separate customer-only escape becomes available after its Bitcoin timelock. The council emergency path uses a bounded set of customer-pre-signed re-vault transactions and the configured delay; it does not grant unrestricted spending authority.

flowchart LR
    U["Customer authorization"] --> V["Bitcoin Collateral Vault"]
    P["Distributed protocol signing"] --> V
    E["Event attestations"] --> T["Pre-authorized settlement"]
    V --> T
    T --> S["Protected payout"]
    T --> R["Remainder vault where applicable"]
    G["Independent Guardian Council"] --> S

Reclaim Flow

When a borrower fully repays their loan on the lending market, finalized debt-zero evidence and the matching event authorization activate the release settlement. The Vault UTXO is spent into a protected Settlement UTXO. The depositor can sweep early with guardian acknowledgment or use the delayed customer path after the contest window, currently one Bitcoin block, if that payout remains unspent.

The result is that a clean payout does not depend on guardian acknowledgment. Once the payout exists, its delayed path remains available without council cooperation. A separate customer-only vault escape provides recovery after its own timelock when normal services are unavailable.

flowchart LR
    D["Repayment finalized"] --> E["Release event authorized"]
    E --> V["Pre-signed release"]
    V --> S["Protected customer payout"]
    S --> A["Early guardian acknowledgment"]
    S --> T["Customer sweep after Bitcoin delay"]
    S --> R["Guardian reversal of invalid payout"]
    R --> B["Return to prescribed vault"]

Liquidation Flow

When a position meets a covered liquidation condition on the lending market, the matching pre-signed settlement becomes usable. Its fixed allocation goes to a protected Settlement UTXO. A partial liquidation also creates a fresh vault for the remaining BTC. After the settlement timelock expires, the registered recipient can sweep the payout if it remains unspent.

During the timelock window, the Guardian Council checks the settlement against independent evidence. If the position does not justify liquidation, a council quorum completes the pre-signed return transaction. A confirmed reversal returns the contested BTC to the prescribed vault and prevents the liquidator from collecting that payout.

The Guardian Council as Optimistic Challenger

The council does not need to approve each normal vault spend. It continuously reviews settlement activity, can acknowledge clean payouts early and intervenes when its independent checks identify an invalid settlement.

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 validate and sign the prescribed return transaction through their signing infrastructure. Once the required quorum is assembled, the reversal is broadcast.

Protective council interventions return BTC to the prescribed vault through a transaction authorized in advance. The council cannot redirect that signed return. Its job is to detect violations and protect the depositor’s Bitcoin; lending-market accounting is reconciled separately. The quorum, evidence and contest-window requirements are explained in Trust assumptions.

The production deposit flow protects funds before vault activation. 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. These checks validate the intended vault before activation.

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, challengers use cryptographic proofs, and participation ultimately opens to anyone who runs the required infrastructure. The collateral lifecycle and independent challenge remain the foundations.

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 supported range of settlements before execution, at exact amounts rather than all-or-nothing. When a partial reclaim or partial liquidation is required, the matching settlement executes.

A partial settlement directs its fixed allocation to a protected Settlement UTXO and the remainder to a fresh Vault UTXO with its own position binding and address. Follow-on liquidation coverage is prepared against that exact remainder before the parent transaction becomes usable. After the partial action settles, the position continues with the remaining collateral.

Fresh vaults require transaction coverage for their remaining collateral and debt. A partial withdrawal includes customer signing of the withdrawal and replacement coverage before broadcast. Production renewal can batch and fund previously authorized transitions, while new outcomes or an exhausted authorization horizon require a customer signing update. Partial repayment reduces live debt first; additional borrowing beyond existing coverage establishes new coverage before funds are released.

Because every settlement has its amounts and destinations cryptographically committed before execution, customer authorization holds throughout the lifecycle. Guardians can reverse an invalid protected payout through its pre-signed return, while valid partial settlement preserves a native BTC remainder.

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.

The production design addresses this with a Flash Settlement Module and Liquidation Liquidity Pool: 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.

flowchart LR
    L["Eligible liquidation"] --> F["Flash Settlement Module"]
    Q["Liquidation liquidity"] --> F
    F --> W["Liquidator receives wrapped BTC on Ethereum"]
    L --> C["Pre-authorized Bitcoin settlement"]
    C --> P["Protected Bitcoin payout"]
    G["Guardian review and reversal"] --> P
    P --> R["Confirmed realization replenishes liquidity"]
    R --> Q

Asynchronous settlement:

6. 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).
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. Settlement obligations are tracked separately, while available liquidity is a pool-level resource. Executors initiate Bitcoin settlement promptly to limit price exposure.

This design aims to preserve competitive liquidation economics while letting liquidators keep their flash-loan tooling. Bonuses, funding costs and available liquidity depend on the market and its settlement terms.

Two safeguards sit behind this flow. First, guardians independently verify settlements and can return invalid payouts to the prescribed vault during the contest window. Second, the production liquidity system must fund and qualify its shortfall backstop, including a guardian reversal that prevents an expected Bitcoin payout. Capitalization, fees, price exposure and loss allocation are part of that qualification.

Wrapped BTC serves the settlement-liquidity process. The borrower’s vault collateral remains native BTC on Bitcoin and does not become wrapped BTC merely because the borrower opens a loan.

Collateral Representation

When BTC is deposited into a Bitcoin Collateral Vault, a position-specific collateral record called vaultBTC represents it on the destination chain. The production mint path uses a Bitcoin light client to verify inclusion and confirmation depth. The mint adapter checks the exact output, beneficiary binding and registered vault construction; complete signed coverage remains a separate activation requirement.

vaultBTC is not a fungible bridge token. It represents a specific vault’s collateral position and participates in release and liquidation accounting. Holding the record does not replace the customer’s Bitcoin signing authority. 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 signing, attestation and guardian roles provide the operational and trust foundation for the first production stage. 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, defined contest windows and customer-authorized destinations.

Phase 1 does the heavy lifting that Phase 2 inherits. Before BitVM verification is introduced, the cross-chain plumbing is intended to be 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 the verification layer while preserving the collateral lifecycle. The aim is an upgrade to a mature lending system with an established liquidator network and operating history. Operational edge cases observed by the guardians inform testing of the BitVM construction. The proving system, challenge transactions and migration still require their own qualification.

In Phase 2, proof-based verification replaces event attestations as the basis for establishing a liquidation condition. 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 claims can be disproved under the chosen construction’s cryptographic assumptions. Protocol signers remain as co-signers of customer-authorized transactions and operators of the lifecycle. Those roles cannot invent new payouts or bypass customer authorization.

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 retains the broad shape of 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 are intended to retain their roles. Existing positions continue under their original verification model until they migrate. Migration is surfaced in the app and requires customer authorization for the new Bitcoin construction and its coverage. It is designed to preserve the lending position without requiring the borrower to close and reopen the loan. New deposits use BitVM verification once that construction is activated.

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, at least one honest challenger able to act during the challenge window, and the selected construction’s cryptographic, setup and data-availability assumptions.

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