# Technical Diagram Verifiable Bitcoin Accounts (VBA) combine three layers: the institution's existing custody, Threshold Network's distributed signer infrastructure, and pre-approved onchain deployment venues. Bitcoin Script enforces all spending conditions at the consensus layer.
## Layer 1: Custody Compatibility Any key management system that can sign Bitcoin transactions and produce BIP-174 (PSBT) compatible partial signatures can participate as depositor (D), custodian (C), or signer (S). ``` +--------------------------------------------------------------------------+ | CUSTODY COMPATIBILITY | +--------------------------------------------------------------------------+ +----------------------+ +----------------------+ +----------------------+ | QUALIFIED CUSTODIAN | | THRESHOLD MPC | | SELF-CUSTODY | | (holds key C or D) | | (holds key S) | | (holds key D) | | | | | | | | - Any regulated | | - tECDSA threshold | | - HSM-based signing | | custodian that | | signing (e.g., | | - Hardware wallets | | supports PSBT | | keep-core nodes) | | - MPC wallets | | - MPC or HSM-based | | - Produces single | | | | key management | | aggregated pubkey | | | | | | for Bitcoin Script | | | +----------------------+ +----------------------+ +----------------------+ | | | +-------------------------+-------------------------+ | v +-----------------------------------------+ | PSBT SIGNING INTERFACE | | (BIP-174 Compatible) | | Each party signs independently | | and contributes partial signature | +-----------------------------------------+ | v +--------------------------------------+ | FINALIZED BITCOIN TRANSACTION | | Broadcast + SPV-proven to Ethereum | +--------------------------------------+ ``` #### Template-to-role mapping
TemplateRoles presentRequired signers per path
qc_v1D + C + SCOOPERATIVE: D+C+S; MIGRATION: S+C; EARLY_EXIT: D+C; LAST_RESORT: D
self_v1D + S (no C)COOPERATIVE: D+S; MIGRATION: S; LAST_RESORT: D
**Key principle:** No asset migration is required. The custody relationship that the institution already maintains continues to govern the asset throughout the VBA's lifecycle. *** ## Layer 2: Multi-Party Control Model ``` +---------------------------------------------------------------------------------+ | MULTI-PARTY CONTROL FLOW | +---------------------------------------------------------------------------------+ +-----------------------+ +------------------------+ +----------------------+ | INSTITUTION | | SIGNER NETWORK | | CUSTODIAN | | Signing Key D | | Signing Key S | | Signing Key C | | (depositor) | | (single aggregated key | | (qc_v1 only) | | | | may be tECDSA-managed | | | | | | off-chain) | | | +-----------------------+ +------------------------+ +----------------------+ | | | | | | +-----------------------------+-----------------------------+ | v +-------------------------------------------------------+ | PATH SELECTION | | | | COOPERATIVE: D + C + S (3-of-3 CHECKMULTISIG) | | MIGRATION: S + C (2-of-2 CHECKMULTISIG) | | EARLY_EXIT: D + C (2-of-2 CHECKMULTISIG) | | LAST_RESORT: D only (1-of-1 CHECKSIG) | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | SBT CONSTRUCTION (BIP-174) | | | | Each signer adds partial sig to PSBT independently | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | PSBT FULLY SIGNED | | | | Broadcast to Bitcoin network | +-------------------------------------------------------+ | v +-------------------------------------------------------+ | SPV PROOF SUBMITTED | | | | CovenantBitcoinTxProofVerifier | | validates proof on Ethereum | | CovenantAuthority updates reserve state | +-------------------------------------------------------+ ``` **Enforcement:** The quorum threshold is encoded in the Bitcoin Script governing the UTXO. Any transaction below the threshold is rejected by the Bitcoin network at the consensus layer. *** ## Layer 3: Bitcoin Script Enforcement Spending conditions are written directly in Bitcoin Script and validated by every Bitcoin full node. ``` +-------------------------------------------------------------------------------+ | BITCOIN SCRIPT ENFORCEMENT MODEL (qc_v1) | +-------------------------------------------------------------------------------+ VBA UTXO (P2WSH with embedded witness script) | +-> SPENDING PATH 1: COOPERATIVE -- Unanimous authorized movement | | | +-- 3-of-3 OP_CHECKMULTISIG (D + C + S all required) | +-- No locktime constraint | +-- No destination restriction in Bitcoin Script * | +-> SPENDING PATH 2: MIGRATION -- Post-maturity signer-led move | | | +-- 2-of-2 OP_CHECKMULTISIG (S + C) | +-- OP_CHECKLOCKTIMEVERIFY: locktime = maturityHeight | +-- No destination restriction in Bitcoin Script * | +-> SPENDING PATH 3: EARLY_EXIT -- Pre-maturity depositor + custodian | | | +-- 2-of-2 OP_CHECKMULTISIG (D + C) | +-- OP_CHECKLOCKTIMEVERIFY: locktime = maturityHeight - beta | +-- No destination restriction in Bitcoin Script * | +-> SPENDING PATH 4: LAST_RESORT -- Solo depositor recovery | +-- OP_CHECKSIG: single signature (D only) +-- OP_CHECKLOCKTIMEVERIFY: locktime = maturityHeight + delta2 +-- Activates if all other parties are unavailable ``` Destination address constraints are enforced by Covenant Authority on Ethereum, NOT by Bitcoin Script. Bitcoin Script only checks signatures and timelocks. *Validated by: Every Bitcoin full node (script validity only)* #### self\_v1 Template (Self-custody, no custodian) ``` +-----------------------------------------------------------------+ | BITCOIN SCRIPT ENFORCEMENT MODEL (self_v1) | +-----------------------------------------------------------------+ Keys: D = depositor, S = signer (no custodian in this template) +-> SPENDING PATH 1: COOPERATIVE | +-- 2-of-2 OP_CHECKMULTISIG (D + S) | +-- No locktime | +-> SPENDING PATH 2: MIGRATION | +-- OP_CHECKSIG: single signature (S only) | +-- OP_CHECKLOCKTIMEVERIFY: locktime = maturityHeight | +-> SPENDING PATH 3: LAST_RESORT +-- OP_CHECKSIG: single signature (D only) +-- OP_CHECKLOCKTIMEVERIFY: locktime = maturityHeight + delta2 ``` **No external dependencies:** The rules governing each VBA do not rely on application-layer software, smart contracts on other chains, or proprietary policy engines. *** ### Liquidation & Migration Path When a position is liquidated in an approved venue, Threshold signers automatically execute the predefined migration path. ``` ┌──────────────────────────────────────────────────────────┐ │ LIQUIDATION & MIGRATION FLOW │ └──────────────────────────────────────────────────────────┘ ┌──────────────────────┐ │ ONCHAIN VENUE │ Liquidation event triggered │ (Aave, Morpho, │ (e.g., LTV breach, oracle price) │ Curve, Yield Basis) │ └──────────┬───────────┘ │ ▼ ┌──────────────────────┐ │ THRESHOLD SIGNERS │ Independent verification │ │ of onchain state │ • Direct read of │ │ contract state │ │ • No external oracle │ │ • No off-chain │ │ coordination │ └──────────┬───────────┘ │ ▼ ┌──────────────────────┐ │ QUORUM EVALUATION │ Threshold signers reach │ │ quorum agreement │ Each signer verifies │ │ conditions are met │ └──────────┬───────────┘ │ ▼ ┌──────────────────────┐ │ PRE-CONSTRUCTED │ Migration PSBT signed │ MIGRATION PSBT │ by quorum │ │ │ Destination: │ │ Pre-defined at │ │ account setup │ └──────────┬───────────┘ │ ▼ ┌──────────────────────┐ │ BROADCAST TO │ │ BITCOIN NETWORK │ └──────────┬───────────┘ │ ┌────┴────────────────────────────┐ ▼ ▼ ┌──────────────────────┐ ┌───────────────────────────┐ │ THRESHOLD BRIDGE │ │ PRE-APPROVED │ │ (Default) │ │ COUNTERPARTY ADDRESS │ │ │ │ (Where venue settlement │ │ │ │ requires it) │ └──────────────────────┘ └───────────────────────────┘ ``` **Critical property:** The migration destination is whitelisted at account setup. Signers do not exercise discretion about where capital goes. They verify a predefined condition and execute a predefined action. *** ### Recovery Architecture Every VBA includes layered recovery paths that operate without requiring counterparty cooperation. ``` +-----------------------------------------------------------------------+ | RECOVERY ARCHITECTURE | +-----------------------------------------------------------------------+ FAILURE SCENARIO 1: Signer network disrupted | +-- Recovery Path A: Joint depositor + custodian recovery (EARLY_EXIT) | | | +-- Threshold signers NOT required | +-- Depositor key (D) + custodian key (C) sign | +-- 2-of-2 OP_CHECKMULTISIG on Bitcoin Script | +-- REQUIRES a timelock: locktime = maturityHeight - beta | (activates BEFORE full maturity, but still time-gated) +-- Reserve state must be in EXITING on Ethereum (CovenantAuthority) FAILURE SCENARIO 2: Both signer network AND custodian are unavailable | +-- Recovery Path B: Depositor solo recovery (LAST_RESORT) | | | +-- Only the institution's key (D) required | +-- OP_CHECKSIG (not multisig -- single signature) | +-- Enforced by OP_CHECKLOCKTIMEVERIFY | +-- Locktime = maturityHeight + delta2 | (longest timelock, set at account creation) +-- Activates automatically when the timelock expires ``` #### Enforcement Mechanism: Recovery paths encoded in Bitcoin Script (P2WSH). However, the reserve state machine lives on Ethereum: CovenantAuthority.reserveStates is the canonical record. IBitcoinRelay must be live for freshness check, Attester quorum (CovenantOracle) required for state advances, Bitcoin txs must be SPV-proven back to Ethereum *** ### Complete Lifecycle Summary A complete view of how a VBA progresses from setup through operation to potential recovery. ``` ┌────────────────────────────────────────────────────┐ │ VBA LIFECYCLE │ └────────────────────────────────────────────────────┘ PHASE 1: SETUP ┌────────────────────────────────────────────────────┐ │ • Quorum structure defined │ │ • Whitelisted venues selected │ │ • Recovery paths configured with timelocks │ │ • Bitcoin Script encoded │ │ • PSBTs pre-constructed │ │ • Optional ACA executed │ └─────────────────────┬──────────────────────────────┘ ▼ PHASE 2: FUNDING ┌────────────────────────────────────────────────────┐ │ • Institution funds VBA from existing custody │ │ • UTXO created with embedded Script conditions │ │ • Account verified and operational │ └─────────────────────┬──────────────────────────────┘ ▼ PHASE 3: DEPLOYMENT ┌────────────────────────────────────────────────────┐ │ • Capital deployed into whitelisted venues │ │ • Multi-party authorization on every movement │ │ • All transactions verifiable on Bitcoin L1 │ └─────────────────────┬──────────────────────────────┘ ▼ PHASE 4: ACTIVE OPERATION ┌────────────────────────────────────────────────────┐ │ • Threshold signers monitor venue activity │ │ • Yield accrues to the account │ │ • Standard reporting generated │ │ • Quarterly reviews with coverage team │ └─────────────────────┬──────────────────────────────┘ ▼ PHASE 5: EXIT (one of three paths) ┌────────────────────────────────────────────────────┐ │ Path A: Normal Exit │ │ Multi-party quorum unwinds positions │ │ Capital returns to the institution's custod │ │ │ │ Path B: Liquidation-Triggered Migration │ │ Pre-defined migration path executes │ │ Capital settles on the whitelisted destination │ │ │ │ Path C: Recovery (Counterparty Failure) │ │ Recovery path activates per Script conditions │ │ The institution recovers capital independently │ └────────────────────────────────────────────────────┘ ``` *** ### Trust Model Summary
ComponentTrust AssumptionEnforcement Mechanism
Spending conditionsNone requiredBitcoin Script + consensus
Quorum thresholdNone required (for Bitcoin Script rules)Bitcoin Script (OP_CHECKMULTISIG); threshold varies by path
Timelock enforcementNone requiredBitcoin Script (OP_CHECKLOCKTIMEVERIFY)
Reserve state machineIBitcoinRelay livenessCovenantAuthority contract on Ethereum (canonical state)
Attestation quorumThreshold attester honesty (threshold-bound)CovenantOracle on Ethereum; ECDSA signature quorum required
Migration executionThreshold signer honesty (threshold-bound)Bitcoin Script path + CovenantAuthority state transition
Recovery activationNone required (Bitcoin Script paths)Bitcoin consensus + OP_CHECKLOCKTIMEVERIFY
Legal enforceabilityCounterparty contractual complianceTripartite Account Control Agreement (optional)
**Net trust model:** The institution does not need to trust Threshold Network for the integrity of the rules governing its capital. It uses Threshold's signer network for operational liveness. If that liveness fails, the recovery path activates without requiring Threshold's participation. *** ### Verification Every condition governing a VBA can be verified independently: * **Spending conditions:** Inspect the Bitcoin Script attached to the UTXO using any Bitcoin full node or open-source script debugger * **Quorum requirements:** Validate the multisig structure encoded in Script * **Recovery paths:** Confirm the timelock parameters and signing requirements * **Onchain state:** Read the UTXO and transaction history directly from any Bitcoin full node * **Deployment activity:** Audit transactions on the relevant chain and reconcile against the VBA's signed PSBT history No proprietary tooling is required for any of this verification. --- # Agent Instructions: Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter: ``` GET https://docs.threshold.network/verifiable-bitcoin-accounts/technical-diagram.md?ask= ``` The question should be specific, self-contained, and written in natural language. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.