Skip to main content

Protocol actors

The Trustless Bitcoin Vault (TBV) protocol has one user role, the depositor, and four operator groups: Vault Providers, Application Vault Keepers, Universal Challengers, and a transitional Security Council. None of the operator groups has custody of a depositor's BTC. They coordinate setup, generate proofs, monitor claims, settle liquidations, or provide an emergency backstop. The depositor's recovery paths do not depend on trusting any single operator. This page describes what each actor does at the protocol level.

What is a Vault Keeper?​

"Vault Keeper" refers to the application-scoped participants that co-sign vault transaction graphs and operate the redemption mechanics for vaults they helped create:

  • Vault Provider (VP). Coordinates each vault's lifecycle for the depositor. One VP is chosen per vault at peg-in and is fixed for that vault's life.
  • Application Vault Keeper (AVK). Application-scoped operator. In the Aave v4 integration, AVKs act as arbitrageurs during liquidation settlement.

Universal Challengers are separate protocol-level fraud monitors. They participate in the challenge mechanism across applications, but they are not application-scoped Vault Keepers.

Depositor​

The depositor is the BTC holder who creates a vault and uses it in an application such as Aave v4. The depositor chooses the application and Vault Provider at vault creation, signs the depositor-controlled Bitcoin release paths, and keeps the local artifacts needed for recovery.

What the depositor does​

  • Vault creation. The depositor starts peg-in, proves control of their Bitcoin key, broadcasts the Pre-PegIn Bitcoin transaction, and later reveals the activation secret on Ethereum.
  • Application use. In the Aave v4 integration, the depositor uses active vaults as collateral to borrow, repay, withdraw, or manage liquidation risk.
  • Artifact custody. The depositor stores their WOTS keypair file and claimer artifacts. These are required for the self-claim fallback.
  • Recovery and challenge. If the Vault Provider is unavailable during redemption, the depositor can drive the Bitcoin claim themselves. If an invalid claim is posted, the depositor or a delegated operator can use the saved artifacts to challenge it.

Vault Provider​

The Vault Provider coordinates the lifecycle of a vault. It drives peg-in setup, posts required data on-chain, and generates the zero-knowledge proofs used during redemption on Bitcoin.

What the Vault Provider does​

  • Peg-in coordination. When a depositor submits a vault creation request, the Vault Provider detects the on-chain event and constructs the pre-signed transaction graph with the Application Vault Keepers and Universal Challengers committed to that vault.
  • PegIn input signature collection and posting. The Vault Provider collects the PegIn input signatures from every party and posts them on-chain in batched form. This keeps the signatures recoverable from Ethereum even if the Vault Provider later goes offline.
  • ACK submission. The Vault Provider collects acknowledgments from every participant and submits them on-chain. ACK submission requires verification that the Pre-PegIn transaction is confirmed to at least the configured depth on Bitcoin.
  • PegIn transaction broadcast. After the depositor reveals the activation secret on Ethereum, the Vault Provider constructs the full PegIn witness using the collected signatures and the revealed secret, then broadcasts the PegIn transaction on Bitcoin.
  • ZK proof generation. When a vault is redeemed, the Vault Provider generates an aggregated SP1 proof of the corresponding Ethereum redemption event. The proof is compressed to a Groth16 form and verified on Bitcoin through the BABE construction.
  • Bitcoin claim management. The Vault Provider broadcasts the Claim, Assert, and Payout transactions on Bitcoin during redemption and monitors for challenges.

What the depositor can do instead​

If the Vault Provider becomes unresponsive during redemption, the depositor can drive the Bitcoin claim themselves using the WOTS keypair and claimer artifacts held since peg-in, via a command-line tool the protocol ships. The Vault Provider is an operational service, not a custodian. See Withdraw & redeem for the self-claim path.

Commission​

Each Vault Provider sets its own commission, taken in BTC at peg-out from the redemption payout. The commission rate is embedded in the pre-signed Payout transactions at vault creation; the depositor signs off on the exact amount before any BTC moves, and the rate cannot change for that vault.

The portal surfaces VP commission rates to depositors before they create a vault.

Registration​

Vault Providers register on-chain by submitting an Ethereum address, a Bitcoin x-only public key, and a Bitcoin proof of possession, usually a BIP-322 signature proving control of the Bitcoin key. A VP registers for one specific application; the same VP needs separate registrations to serve multiple applications.

Application Vault Keeper (AVK)​

Application Vault Keepers are application-scoped participants. In the Aave v4 integration, AVKs act as arbitrageurs during liquidation settlement. That role is specific to the Aave application's design and may differ in future integrations.

What the AVK does​

  • Transaction graph participation. During vault creation, each AVK constructs its own transaction graph and cross-signs with the Vault Provider. This gives multiple independent parties the pre-signed transactions needed for vault outcomes.
  • PegIn input signing. Each AVK signs the Pre-PegIn HTLC spend as part of the off-chain protocol.
  • ACK submission. Each AVK submits an on-chain acknowledgment confirming graph setup, signature collection, and verification of the Pre-PegIn confirmation depth.
  • Aave-specific liquidation settlement. The Aave integration routes permissionless liquidation through a Liquidation Liquidity Provider (LLP); BTCVaultSwap is the default LLP. Liquidators receive instant WBTC liquidity from the LLP, while the seized vault enters escrow until a registered arbitrageur acquires it and finalizes BTC redemption on Bitcoin. Only registered AVKs can acquire escrowed vaults, because they must have pre-signed the vault's transaction graph at creation.
  • Challenge participation. As holders of pre-signed transaction graphs and relevant artifacts, AVKs can participate in the challenge mechanism if they detect an invalid claim against a vault they co-signed.

Registration​

AVKs are registered per application through the vault registry. Each application maintains a versioned set of AVK key pairs (Ethereum + Bitcoin). A set version is immutable once active: rotation produces a new version that applies only to vaults created after the rotation. Vaults already in flight retain the set version live at their creation.

Universal Challenger​

Universal Challengers are protocol-level fraud monitors. Their role is to detect and challenge invalid proof submissions during vault redemption, regardless of which application a vault belongs to.

What the Universal Challenger does​

  • Fraud monitoring. The Universal Challenger watches claim transactions posted on Bitcoin and verifies the associated proof against Ethereum state. A claim that does not correspond to the required Ethereum redemption state cannot be backed by a valid proof.
  • Challenge execution. When fraud is detected, the Universal Challenger broadcasts a challenge transaction within the assert timelock. The challenge transactions verify the claimer's WOTS signatures against the garbled-circuit instances established at peg-in. If the claim cannot be defended, the challenger broadcasts the no-payout transaction after the disprove timelock expires; the claimer's bond is forfeited.
  • Peg-in setup. Where required by the protocol setup, Universal Challengers participate in the vault-specific commitments that make later challenge transactions valid on Bitcoin. The commitment is bound to the vault's specific Pre-PegIn HTLC output, which prevents cross-vault replay.
  • Vault-specific commitment. The Universal Challenger set active at vault creation is committed into that vault's Bitcoin-side transaction graph and challenge paths. This is what allows their challenge transactions to be valid on Bitcoin.

What the depositor can do instead​

If an invalid claim is posted and no Universal Challenger picks it up, the depositor, or any party they delegate, can compose and broadcast a challenge using the BABE artifacts received at peg-in. The protocol's safety does not depend on any specific Universal Challenger being honest or online; the depositor also has a challenge path.

Set composition and registration​

Universal Challengers are registered at the protocol level rather than per application. They are stored as a versioned array of Ethereum and Bitcoin key pairs. Each vault records the Universal Challenger set version active at its creation; that set is fixed for the vault's lifetime.

The Universal Challenger set is a closed registry. It is not planned to open up to permissionless participation; expansion happens through governance adding additional vetted operators.

Security Council​

The Security Council is a quorum of off-chain signers whose Bitcoin public keys are committed in the protocol's versioned off-chain parameters. The council is an emergency backstop for situations the standard mechanism cannot resolve. On the current public testnet, the council has 5 keys with a 3-of-5 quorum. It is a transitional safety net intended to be retired as the protocol matures.

What the Security Council does​

  • Emergency intervention. If the standard challenge mechanism fails to prevent a fraudulent payout, or if a critical protocol issue requires immediate action, the council can act.
  • Produce council no payout transactions by quorum, blocking payout on a specific vault. The council cannot direct BTC to any address; it can only prevent release.
  • Operational pause states. The council can place the protocol into a soft pause or a full pause. Pauses affect Ethereum-side application actions, but they do not affect Bitcoin-side depositor recovery paths that are already available, such as the Pre-PegIn refund path or WOTS self-claim.
  • Off-chain depositor-recovery support. If a depositor loses both their WOTS keypair file and their claimer artifacts, and the Vault Provider is also unresponsive, an off-chain recovery procedure can be initiated. The Security Council's role is to use its council no payout power to block any unauthorized payout while that procedure runs.

Permissioned and permissionless participation​

The protocol mixes permissioned and permissionless entry points:

  • Fraud monitoring. Anyone can monitor for invalid claims by running a watcher and checking Ethereum-side state. Broadcasting a Bitcoin-side challenge is not a generic public call; it requires the vault-specific challenge path and artifacts available to the relevant Universal Challengers, Vault Keepers, and the depositor. The Universal Challenger registry is governed at the protocol level.
  • Liquidation triggering. Calling liquidateWithLLP on the Ethereum side is permissionless: any address can call the function once a position's health factor drops below 1.0. The direct-redemption variant liquidate requires being a registered AVK with a Bitcoin redeem key. Permissionless liquidation helps positions get liquidated promptly regardless of which dedicated operators are online.