Skip to content

🔐 dVaults: Programmable Bitcoin Vaults

A dVault is a Bitcoin Taproot UTXO (BIP341) whose spend conditions are committed via MAST/Tapscript (BIP342).

  • Taproot commits multiple spend conditions into a single address.
  • MAST (Merkelized Alternative Script Tree) enumerates independent spending conditions, allowing funds to be spent by satisfying any single script. Each script is a leaf in a Merkle tree, and only the executed leaf is revealed during spend. Any unused branches remain hidden.

Surge uses dVaults as its collateral engine and BTC always remains on Bitcoin, only moving when one of the pre-committed spend conditions is satisfied.

How dVaults are Programmed?

Each dVault locks BTC under a single encoded public key (PT2R) with multiple predefined spend paths:

  • Repayment path activated when the borrower's repayment is attested by the Execution State Machine (ESM) and Authorized by the borrower and Decentralised Custody Network using threshold Schnorr signatures from Coinbase cb-mpc. This is the normal closure condition that releases BTC once the loan is settled.
  • Liquidation path activated when collateral ratio falls below the minimum threshold and signed by the DCN. The DCN, following oracle validation, can execute liquidation to settle outstanding debt by transferring discounted BTC to the market.
  • Timelock Exit a long-term unilateral exit path that activates after a defined CLTV delay, guaranteeing non-custodial control even if all signers fail.

All three branches are committed at vault creation. Only the executed path is revealed during a spend.

dVault Taproot UTXO

dVault Taproot UTXO

Script Structures

1. Repayment Path (Ledger Validated Unlock)

# Requires depositor + decentralised signer set key &
# Valid only if repayment is attested by the ESM
OP_CHECKSIG(user_pubkey),
OP_CHECKSIGADD(lin22_signer_set_key)
OP_2

2. Liquidation

# Signers key can spend BTC if CR < MinCR
OP_CHECKSIG(lin22_signer_set_key),
OP_CHECKSIGADD(oracle_attestation_signature),

3. Timelock Exit

# Depositor regains unilateral control after CLTV expiry
OP_CHECKLOCKTIMEVERIFY,
OP_DROP,
OP_CHECKSIG(user_exit_key)

Vault Operation Flow

  1. Deposit - User locks BTC to the Taproot address.
  2. Borrow - Execution environment issues stablecoins against the attested deposit.
  3. Monitoring - BTC/USD oracle updates CR, state commits, debts, and liquidity pool (variable and fixed market) balances.
  4. Liquidations - If CR < MinCR, signers spend via the liquidation leaf. The spend MUST produce:
    • LP pool exchange - discounted BTC transferred to the pool in exchange for proportional stablecoin debt cancellation.
    • Relock - re-locked into the dVault under the borrower’s control.
  5. Repayment/Full Closure - Once repaid, signers co-sign the key-path spend, moving BTC as per user instructions.

Each spend path is covered in detail in its own section:

Security Anchors

All dVaults derive from Bitcoin’s native enforcement logic. Every spend path is cryptographically pre-committed in Taproot, validated by threshold Schnorr signatures, and ultimately sovereign through the Timelock Exit. The Execution State Machine and signer set coordinate off-chain attestations, but Bitcoin remains the only enforcement layer.