Skip to main content

Bitcoin considerations

Bitcoin is the chain where we are most explicit about scope. L1 does not have the script expressiveness to replicate the atomic-split payment-link pattern we use on EVM and Solana. So on BTC we do reduced custody, not zero custody, and we leave recurring payments out of scope until Lightning BOLT12 recurrence is production-ready.

This page is the reference for why.

What "reduced custody" means on BTC​

Starting in Phase 5:

  • Every new payment link is a 2-of-2 taproot multisig address.
  • One signer is the merchant, via a key they control (xpub onboarded at merchant setup; per-link derivation).
  • One signer is the platform, via an HSM or MPC service (candidates: Lit, Turnkey, on-prem HSM). The API server does not hold the raw platform key.
  • Settlement requires both signatures; neither party can move funds unilaterally.
  • Every deposit gets a pre-signed refund PSBT stored encrypted off-chain, so the payer is recoverable if the merchant is unreachable.

What this changes from today:

  • No single server-held xpub controls funds. Compromise of the API server does not give attacker spending authority.
  • Merchants are explicitly in the signing loop. They cannot be surprised by a settlement.
  • Refunds are always possible (merchant broadcasts the pre-signed PSBT).

What stays​

  • Split accounting is still done in the settlement PSBT: outputs to merchant, platform, referral, bridge fee, and (if any) change. The split is deterministic and visible on-chain in the broadcast transaction. It is not enforced by script (Bitcoin script cannot compute percentages), but it is observable and auditable.
  • The sweep path in api/src/withdrawals/services/bitcoin-withdrawal-transfer.service.ts stays, but signs via the multisig ceremony instead of a unilateral key.

What is out of scope​

BTC subscriptions / auto-charge​

Today's Auto-charge already states that subscription pulls are supported on EVM and Solana only. That remains true after Phase 5.

There is no credible allowance-pull equivalent on BTC L1:

  • No standard token allowance primitive.
  • No general contract that can transferFrom on behalf of a payer.
  • Pre-signed PSBT sequences (one per period) exist in theory but offer none of the cancel/modify flexibility payers expect from subscriptions.

Fedimint, Cashu, statechains​

Interesting research; none is positioned to become a production payments rail we can offer to every merchant today. We revisit when adoption changes.

The Lightning path​

Recurring BTC payments have one realistic future home: Lightning BOLT12 offers + the recurrence extension. That would give BTC an equivalent to ERC-20 approve + pull.

Dependencies (all upstream):

  • Mature BOLT12 recurrence implementations in major LN nodes (LND, Core Lightning).
  • Wallet support for BOLT12 recurrence in the wallets our payers use (Phoenix, Zeus, Blink, hardware wallets).
  • Liquidity: an LN node fleet or partner network with capacity for expected volumes.
  • UX: the pay app must make recurring Lightning feel as simple as approve(cap) on EVM.

We will publish a design doc when the upstream stack is ready. Until then, BTC stays one-shot.

Operational details​

Merchant onboarding​

  • Merchant provides an xpub (one or two — primary and optional backup).
  • OrcaRail derives per-link merchant keys from the xpub; merchant derives the same keys locally to co-sign.
  • Backup xpub is strongly encouraged to handle merchant key loss.

Key loss recovery​

  • Merchant loses primary key, has backup: derive from backup, continue.
  • Merchant loses both: existing open links cannot be settled merchant-side. The pre-signed refund PSBTs still work (payer recovery). New links require a new xpub.
  • Platform key rotation (annual): all existing deposits keep working because the old key is still valid for those specific addresses. New links use the new derivation path.

HSM or MPC failover​

  • Platform HSM is deployed redundantly across regions.
  • MPC alternative adds an extra signer tier but adds complexity; we are evaluating during Phase 5 design.
  • Runbook for emergency failover documented and rehearsed quarterly.

Gas / fee market​

  • Settlement PSBT pays fee at broadcast time. The co-sign UI shows the current fee rate and flags unusually high values.
  • CPFP (child-pays-for-parent) hook available if a settlement transaction gets stuck in the mempool.

Regulatory posture​

With merchant signers on every link, BTC payments on OrcaRail look much more like a regular merchant processor and less like custody:

  • No single-party control over funds.
  • Payer recovery is always available via the pre-signed refund PSBT.
  • Platform never sees the raw private key on any server.

This materially simplifies the compliance story in most jurisdictions, but does not eliminate registration requirements everywhere. Check with local counsel.

See also​