Skip to main content

Protocol architecture

The Trustless Bitcoin Vault (TBV) protocol has three layers: Bitcoin scripts and transactions, Ethereum contracts, and off-chain participant software. For the trust model, see Safety & trust assumptions.

Protocol architecture: Bitcoin Taproot vaults, Ethereum coordination and integration contracts, and off-chain participants

System components​

On Bitcoin​

A vault's BTC sits in a Bitcoin Taproot output. Its spending paths cover the outcomes agreed at vault creation: redemption after withdrawal, redemption after liquidation, and challenge responses. Before BTC reaches the vault output, it sits briefly in a Pre-PegIn HTLC output. That output gates activation on the depositor revealing a hashlock secret on Ethereum. It also includes a timelocked refund path, so the depositor can recover BTC unilaterally if activation never completes.

The vault output is locked by a pre-signed transaction graph. Every legitimate spend path is constructed and signed by the required participants at vault creation. After creation, no party can invent a new spend; Bitcoin will accept only the paths already encoded and signed.

On Ethereum: protocol contracts​

The core protocol contracts manage vault accounting and shared infrastructure:

  • Vault registry: tracks each vault's lifecycle, depositor hashlock, and WOTS commitment. Emits protocol notifications that off-chain participants watch.
  • Metadata registry: publishes Vault Provider RPC endpoints for peer discovery.
  • Protocol parameters: stores versioned protocol parameters: timelocks, confirmation depth, actor sets, Security Council keys, and off-chain parameters.
  • Application registry: lists DeFi applications approved to receive vaults. Currently only the Aave v4 adapter is registered.
  • Cap policy: enforces per-application and per-address BTC exposure caps at vault activation.
  • Fee escrow: collects the peg-in fee and distributes it to the Vault Provider, Universal Challengers, and Application Vault Keepers.

On Ethereum: application integration contracts​

Each registered application adds its own integration layer. For the Aave v4 integration:

  • Aave adapter: user-facing entry point for the integration. Translates user actions such as borrow, repay, and withdraw into vault operations.
  • Vault swap: default Liquidation Liquidity Provider (LLP) for the Aave integration. It is registered as its own Aave Hub spoke for WBTC liquidity, distinct from the Babylon Core Spoke for vault collateral.

A new application needs its own contracts and governance registration. A vault is created for one application and cannot be moved to another application later. For the full lending stack, see Aave v4 integration.

Off-chain​

Off-chain refers to participant software and protocols, not custody.

  • Protocols. The BABE cut-and-choose protocol establishes garbled circuit instances between claimer-challenger pairs at vault creation. Signature exchange assembles the transaction graph. The SP1 proof pipeline generates the proofs needed for peg-out claims.
  • Participants. The Vault Provider, Application Vault Keepers, and Universal Challengers each run vault management software. Per-actor responsibilities are on Protocol actors.
  • Storage. Participants store the artifacts needed for proof verification and challenge flows. The depositor receives their own claimer artifacts plus a WOTS keypair file; both are required for the self-claim fallback.

Peg-in mechanism​

Peg-in registers a vault on Ethereum and locks BTC on Bitcoin. The flow runs through four phases. Total latency to Active is approximately two hours on signet, dominated by the wait for Bitcoin confirmations.

Phase 1: initiation​

The depositor:

  1. generates a 32-byte secret and the hashlock;
  2. submits the peg-in request to the vault registry, including the depositor's Ethereum address, Bitcoin public key, BIP-322 proof of Bitcoin key possession, the chosen Vault Provider, and the WOTS public key hash commitment;
  3. broadcasts the Pre-PegIn Bitcoin transaction, which locks the BTC into the HTLC Taproot address committed to the hashlock.

The app may broadcast a batched Pre-PegIn transaction with multiple outputs, one per vault, for multi-vault peg-ins. This saves on Bitcoin fees and gives those vaults the same Bitcoin confirmation history.

Phase 2: cryptographic setup​

While confirmations accumulate on Bitcoin:

  • Depositor authentication. The depositor authenticates to the Vault Provider using a challenge-response anchor.
  • WOTS keypair setup. The depositor generates a Winternitz One-Time Signature (WOTS) keypair. The public key hash is committed in the vault's on-chain record.
  • BABE setup. The Vault Provider, Application Vault Keepers, and Universal Challengers run the BABE cut-and-choose protocol to establish garbled-circuit instances for the claim and challenge paths.

Phase 3: signatures and acknowledgments​

  • Transaction graph creation. Participants construct and pre-sign every spend path. Each also signs the PegIn input, which spends the Pre-PegIn HTLC.
  • PegIn signature availability. The Vault Provider posts collected PegIn input signatures on-chain. This keeps the signatures available even if the Vault Provider later goes offline.
  • Depositor payout signatures. The depositor signs the payout transactions, which fix the Bitcoin destinations available to the vault's release paths.
  • Acknowledgment collection. Each participant signs an on-chain acknowledgment. Once all are collected, the vault is ready for activation. If this does not happen before timeout, the vault expires and the peg-in fee is refunded.
  • Artifact distribution. Garbled circuit artifacts are exchanged out-of-band. The depositor receives their own copy of the claimer artifacts plus their WOTS keypair file, required for the self-claim fallback.

Phase 4: activation​

The contract verifies the hashlock, then notifies the registered application. For the Aave v4 integration, this deploys the depositor's position proxy if this is the first vault, mints internal vaultBTC accounting for the vault's BTC amount, and supplies it as collateral to the Babylon Core Spoke.

Any party, typically the Vault Provider, observing the activation notification can construct the final PegIn witness using the revealed secret and the collected on-chain signatures, then broadcast the PegIn transaction on Bitcoin. Once confirmed, the BTC is in its vault output. The PegIn transaction also produces a small depositor claim output, controlled solely by the depositor's key, that anchors the self-claim path.

Peg-out mechanism​

Peg-out releases the BTC on Bitcoin after a vault is redeemed on Ethereum. The Bitcoin side knows only "redeem"; the application layer translates user actions into the redeem call. Two common Ethereum-side triggers start redemption:

  • The depositor calls the application's withdrawal function, on the Aave adapter, after repaying outstanding debt.
  • An application-specific liquidation seizes one or more vaults. For the Aave v4 integration, this is either the direct BTC redemption path for registered arbitrageurs or the permissionless LLP-routed path that escrows the seized vault in BTCVaultSwap to receive WBTC.

The protocol identifies the authorized claimers for the Bitcoin-side redemption path. The Vault Provider drives the standard path. The depositor has a parallel self-claim path using the WOTS keypair and claimer artifacts saved at peg-in.

Redemption proof​

To claim BTC on Bitcoin, the claimer, typically the Vault Provider, generates a zero-knowledge proof that the corresponding Ethereum redemption event occurred on the finalized Ethereum chain. The proof is built in four stages:

  • Beacon finality. Proves a specific Ethereum beacon chain block has been finalized by the consensus layer.
  • Execution finality. Links the beacon block to the execution block containing the redemption transaction.
  • Receipt inclusion. Proves the relevant redemption log exists in the receipt of that block.
  • Groth16 compression. Aggregates the previous three stages into a compact Groth16 proof.

Generation runs on an SP1 prover, locally or via an external prover service, typically on GPU hardware.

Bitcoin-side claim flow​

With the proof generated, the claimer follows the Bitcoin-side flow:

  • Claim transaction. Spends from the vault's Taproot output through the redemption claim path.
  • Assert transaction. Commits to the proof using WOTS signatures. It is broadcast within the assert window (432 BTC blocks, approximately 3 days on the public testnet).
  • Challenge window. During the challenge window, a Universal Challenger, relevant Vault Keeper, or the depositor using their artifacts can dispute an invalid proof.
  • Payout. If no valid challenge succeeds within the window, the pre-signed payout path releases BTC to the destination fixed at vault creation. For normal withdrawal this is the depositor's Bitcoin address, minus the Vault Provider's commission. For liquidation this is the authorized liquidation claimant's Bitcoin address.

If a challenge is raised, the flow moves to dispute resolution.

If the Vault Provider goes offline​

The depositor can act as the claimer using the WOTS key plus the locally stored claimer artifacts. The same Claim, Assert, and Payout sequence is followed, but the depositor drives the Bitcoin transactions instead of the Vault Provider.

Challenge and dispute resolution​

Bitcoin's native scripts cannot directly verify ZK proofs. Verification happens through the BABE construction, which uses pre-committed garbled circuits and WOTS commitments to enforce proof correctness using only Bitcoin's existing script primitives. Two cases matter: an invalid claim and an invalid challenge.

Block an invalid claim​

  • The claimer broadcasts the Claim and Assert transactions. The Assert transaction commits WOTS signatures of an invalid proof.
  • A Universal Challenger, relevant Vault Keeper, or the depositor detects the invalid proof and replays it under the BABE input labels established during peg-in. They broadcast a challenge transaction on Bitcoin.
  • The claimer cannot reveal a refuting secret because no valid proof exists. They cannot post a wrongly challenged transaction.
  • After the disprove timelock (108 BTC blocks, approximately 18 hours on the public testnet) expires, the challenger broadcasts a no-payout transaction, finalizing the dispute. The claimer's bond is forfeited and the invalid claim is blocked.

Block an invalid challenge​

  • The claimer extracts the witness from the challenge transaction and decrypts the output label.
  • The claimer broadcasts a wrongly challenged transaction revealing the recovered label. This is only possible if the claim was valid; the garbled circuit construction makes it computationally infeasible otherwise.
  • After the assert timelock expires, the claimer broadcasts the Payout transaction. The BTC is released as expected. The challenger's bond is forfeited.

Timelock parameters​

Two timelocks govern the dispute window. The total claim-to-payout wait is approximately three days.

  • Challenge window: 432 BTC blocks (about 3 days). Window for a challenge to be submitted.
  • Claimer disprove time: 108 BTC blocks (about 18 hours). Window for the claimer to disprove a challenge via a wrongly challenged transaction.

Both are versioned off-chain parameters. Existing vaults retain the values from when they were created.

  • Protocol actors: who runs the off-chain roles and what each is trusted to do.
  • Aave v4 integration: the lending application stack built on this protocol.
  • How it works: the conceptual peg-in and peg-out walkthrough.
  • Glossary: definitions of the protocol-specific terms used here.