Skip to main content

Phase 5: Bitcoin — Taproot 2-of-2 and Honest Scope

· 5 min read
OrcaRail
OrcaRail
Crypto payment rails for web2 apps

April 20, 2026 — Bitcoin is the chain where we have to be honest. The L1 script surface does not have the expressiveness of EVM or Solana, so the "payment-link contract that splits atomically" pattern does not translate. What we can do is reduce custody from "OrcaRail holds the xpub" to "two-signer multisig with a merchant signer and a pre-signed refund," and push recurring payments to a future Lightning path.

TL;DR​

  • Every BTC payment link becomes a 2-of-2 taproot multisig: one merchant signer, one platform signer. Platform cannot move funds unilaterally.
  • Every deposit gets a pre-signed refund PSBT stored off-chain so the payer is recoverable if the merchant disappears.
  • Master xpubs move off the API server to an HSM or MPC service (e.g. Lit, Turnkey). No mnemonic on disk.
  • Recurring payments on BTC are out of scope until Lightning BOLT12 is production-ready. Today, Auto-charge already states BTC is not supported for auto-charge — that stays true.

What this phase changes​

Today, BitcoinHotWalletService in api/src/withdrawals/services/bitcoin-hot-wallet.service.ts derives a unilateral p2wpkh address from a server-held mnemonic and sweeps it via bitcoin-withdrawal-transfer.service.ts. That is a single key we control.

After Phase 5:

No single party can spend. No server holds a unilateral seed.

What we are shipping​

  • Descriptor wallet per link: wsh(multi(2, merchant_pubkey, platform_pubkey)) or a taproot equivalent (tr(NUMS, {pk(m), pk(p)}) with MuSig2 for a single-sig-looking output — nice for privacy and fees).
  • Merchant key lives in the merchant's browser or mobile extension. Merchant onboarding flow prompts for an xpub; per-link keys derive from it.
  • Platform key lives behind an HSM or MPC service. The API server never sees the private material.

2. Pre-signed refund PSBT​

When a deposit is detected:

  1. API assembles a PSBT that returns the deposit minus gas to the payer's address (captured at pay-link creation when payer wallet is known; fallback is sendback policy).
  2. Both signers sign the refund PSBT immediately and store it (encrypted) in the database.
  3. Merchant can broadcast the refund at any time with one click; no further signing needed.

This is the BTC analog of an on-chain refund() function.

3. MPC key rotation​

  • Master xpubs for platform keys rotate annually.
  • All derived per-link keys roll with rotations — old links keep working because their multisig is already on-chain with the specific pubkey.
  • Rotation is logged in the same audit trail as the multisig deploys from Phase 0.

What we are not shipping​

  • BTC subscriptions / auto-charge. No credible design on L1 today. The existing Auto-charge docs already exclude BTC; that stays correct.
  • On-chain atomic splits for BTC. Splits happen in the merchant-signed settlement PSBT. The split is still deterministic and visible in the broadcast transaction, but it is not enforced by script.
  • Fedimint or statechains. Interesting research; not in this phase.

Lightning as the future path​

Recurring BTC payments have one realistic option: Lightning BOLT12 offers + recurrence extension. That would give us a BTC subscription story comparable to ERC-20 approve + pull. We track it as a future phase:

  • Depends on mature BOLT12 recurrence implementations in LND and CLN.
  • Depends on Lightning wallet support (Phoenix, Zeus, Blink) for BOLT12 recurrence.
  • Requires an LN node fleet with sufficient liquidity; probably via a partner (Voltage, Greenlight).

We will post a dedicated design doc when the upstream tooling is ready. Until then, BTC stays one-shot.

Deprecations​

  • BitcoinHotWalletService — keeps its interface, but the key provider moves to HSM/MPC. The unilateral p2wpkh deposit address stops being generated for new links.
  • Legacy BTC deposit addresses stay settleable until their expiry via the old sweep path.

Migration plan​

  • New BTC payment links: 2-of-2 multisig addresses. UI unchanged; address format updates to taproot.
  • Existing open BTC links: legacy unilateral addresses remain active until expiry; we do not force migration.
  • Merchants without a configured BTC signer: fall back to a platform-only multisig for now, with a mandatory onboarding step to attach a merchant key within 30 days. This preserves the refund path and avoids blocking existing BTC volume.

Risks and mitigations​

  • Merchant loses their key. Mitigation: merchant onboarding asks for two xpubs (primary + backup); the backup is optional but heavily encouraged.
  • Platform HSM outage. Mitigation: HSM is redundant across regions; emergency key recovery via multisig ceremony documented in the runbook.
  • Refund PSBT storage compromise. Mitigation: refund PSBTs encrypted at rest with a separate KMS key; they are still useless without the merchant's signature being re-signed for a different destination (the destination is fixed in the pre-signed PSBT).
  • MuSig2 maturity. Mitigation: v1 ships with explicit 2-of-2 wsh(multi(...)); MuSig2 comes later once tooling is widely audited.
  • Fee market spikes. Mitigation: settlement PSBTs include a CPFP hook the merchant can bump; keeper monitors mempool and warns merchants when settlement gas exceeds a threshold.

Status checklist​

  • Taproot descriptor template finalized
  • HSM / MPC provider selected (Lit vs Turnkey vs in-house HSM)
  • Merchant xpub onboarding flow in dashboard
  • Per-link descriptor derivation and storage
  • Pre-signed refund PSBT generation + encrypted storage
  • Settlement co-sign UI (one-click merchant sign)
  • Runbook for HSM failover and merchant key loss
  • Canary cohort of merchants on BTC 2-of-2

What is next​

Optional decentralization of the keeper via EigenLayer: Phase 6.

Reference docs: Phase 5 status · Bitcoin considerations · Security model