How Bitcoin Collateral Vaults work

The production architecture connects three records: the Bitcoin output, the customer-authorized transaction package and the Ethereum lending record. An integration keeps them in agreement through each position change. The deployed demo uses the attested-credit profile described in Deployment reference; the diagram below shows the production proof-based path.

flowchart TB
    V["Bitcoin vault"] --> P["Bitcoin proof verification"]
    P --> A["SPV mint adapter"]
    A --> G["Gateway"]
    G --> R["Reserve: collateral and pending actions"]
    G --> F["Facade: restricted collateral accounting"]
    R --> L["Lending market: debt and health"]
    O["Oracle events"] --> X["Complete pre-signed CET"]
    X --> S["Bitcoin settlement and V2 remainder"]
    W["Independent watchdog"] --> S
    S --> M["Confirmed settlement observations"]
    M --> G

1. Commit the Bitcoin position

The vault combines the customer key with a distributed protocol aggregate key. Its chequebook contains conditional transactions with fixed payouts, including further transactions for partial-liquidation remainders.

Escape and customer-authorized veto paths are committed in the vault’s script tree. The production settlement output adds the fast, delayed and watchdog-reversal paths used to resolve a settlement.

The signed transaction package is stored off-chain, while the vault’s script tree commits to an event-keyed leaf for each cheque. The customer signs that leaf and the fixed transaction. A matching oracle authorization completes the protocol contribution; the protocol key alone cannot bypass it. Cooperative withdrawals use a separate plain customer-plus-protocol leaf.

Oracle commitments bind to the position before funding. Each remainder has its own binding, event commitments and address; its pre-signed transactions reference its exact future outpoint.

2. Recognize collateral and manage debt

The Gateway accepts authorized deposits and claims. The Reserve records collateral outpoints, construction versions and pending settlements. Lending contracts apply borrowing and liquidation rules to those records.

The ZestFacade represents sats in transfer-restricted accounting units. The proof-based deposit route connects Bitcoin verification to collateral credit and cap enforcement.

This boundary makes native BTC collateral usable by Ethereum lending integrations without requiring the BTC itself to leave Bitcoin.

3. Authorize and observe settlement

The signer set holds distributed shares of the protocol key and participates in ceremonies and coverage maintenance. The oracle authorizes defined events. Executors complete and broadcast pre-signed transactions.

The Guardian Council performs independent watchdog duties. Release and debt-bucket stamps use a mixed open roster rather than exclusive signer-set permission.

No new customer Bitcoin liquidation signature is required at execution. Chain observation, broadcast, fee funding and Ethereum settlement still require functioning services.

4. Reconcile the resulting position

The vault outpoint, construction, signed payouts, oracle event and Ethereum account must describe the same position.

Two-sided finality requires finalized Ethereum reads and at least six confirmations for Bitcoin-derived actions. Pending-settlement gates prevent collateral already committed to an action from supporting conflicting new borrowing.

Production renewal keeps coverage aligned with the loan. A changed outpoint requires coverage for that exact new output before it can be exposed.

See Independent oversight, Ethereum integration and Verify your position. Rollout evidence is maintained separately in Demo status.

Explore the protection model

What your signature authorizes explains customer control. Guardian protection explains independent enforcement. Continue with Keeping coverage current, Recovery and Trust assumptions for the conditions of a continuing position.