Skip to content

⚙️ Execution State Machine

The Execution State Machine (ESM) functions as the canonical ledger for BTC-backed liabilities.
It connects Bitcoin vaults, signer sets, and stablecoin issuance through deterministic state transitions, ensuring BTC collateral can only move when programmatic conditions are satisfied.

The ESM defines authorization logic for Bitcoin spends, while the actual spend construction and signing occur in the Deterministic Liquidation module.

Canonical Ledger for BTC-Backed Liabilities

The onchain State maintains the single source of truth for:

  • Collateral ratios and liquidation thresholds.
  • Active liabilities (stablecoin denominated debt).
  • Signer sets composition and epoch rotations.

It prevents rehypothecation by ensuring every Bitcoin UTXO is represented exactly once in system state, binding liabilities directly to on-chain BTC collateral.

Bitcoin Aware State

The ESM is natively coupled to Bitcoin:

  • Oracle Feeds: Medianized BTC/USD prices from trusted providers update collateral ratios in real time.
  • Bitcoin Attestations: Inclusion proofs for Taproot UTXOs and spends confirmations are submitted to ESM, ensuring the on-chain record mirrors actual Bitcoin state.

This guarantees that liabilities within the application always correspond to native Bitcoin collateral, never synthetic or wrapped assets.

State Root Commitments

A confirmed state transition finalizes a state root that encodes:

  • Vault positions and collateral ratios.
  • Active signer set and epoch key.
  • Marketplace balances (variable pool and fixed markets) and stablecoin liabilities.

BTC spends from a dVault are only valid if the signer set signs under the aggregate threshold Schnorr key bound to this state root. This creates a cryptographic anchor, BTC collateral cannot move unless the Execution Program has verified and authorized it.

Oracle Integration

The ESM depends on a Native Oracle Hub to monitor BTC/USD prices and enforce collateralization rules.

  • Medianized prices across trusted feeds are used for CR enforcement.
  • Liquidation events are emitted when CR < MinCR, binding signer permissions to liquidation spends.
    All oracle attestations are verifiable and time-bounded, no single oracle can trigger a liquidation unilaterally.

Distributed Custody Network Enforcement

Distributed Custody operations are strictly deterministic and event-driven:

  • Distributed Custody Enforcement: Coinbase cb-mpc distributed signing rounds for Taproot vault keys.
  • Contract-Gated Authorization: Distributed Custody members can only sign if the ESM has emitted a valid event.
  • No Rogue Signing: Distributed Custody members do not decide when BTC can move - the ledger enforces it.

This guarantees programmatic enforcement of BTC custody, BTC moves only when the cryptographic and economic conditions encoded in Surge’s Execution State Machine are met.