👥 Distributed Custody Network

Surge implements Lindell 2022 Multiparty Schnorr Signing (Lin22) a threshold Schnorr signature protocol and with ideal zero-knowledge and commitment functionality this framework provides strong security, fault tolerance, and privacy.

It enables quorum-based gated spending of Taproot vaults (dVaults) without revealing the signer structure or compromising on-chain efficiency.

Signer

Why Threshold Schnorr Signatures Essential for dVaults

• Threshold Signing - Every signing session is gated by pre-sign policy checks by individual signers making it reliable and accountable; only a t-of-n quorum can authorize within rules.
• Byzantine Resilient - The protocol continues safely even if some signers are offline or act maliciously. Misbehavior is provable and recoverable.
• Taproot Compatibility - Bitcoin's Taproot (BIP340) requires Schnorr signatures. Threshold signatures must be indistinguishable from single-party Schnorr signatures to preserve privacy and efficiency.

Why Surge Chooses Lin22

Surge prioritizes reliability, accountability, and verifiability over lowest latency.

• Trustless Coordinator - Lin22 doesn't rely on a trusted coordinator. Its security holds even with partial failures or adversarial behavior.
• Identifiable Misbehavior - Each signer provides Fischlin Zero-Knowledge Proofs (ZKPs). If a signer cheats or aborts, the network obtains cryptographic evidence, enabling automated slashing and signer rotation.
• Privacy Preserving - The final aggregated signature is a standard Taproot compatible Schnorr signature. Vault spends are indistinguishable from single signer spends.

Malicious Signer

Unlike FROST, where a single malicious signer can halt the session, Lin22 identifies and proves who misbehaved. Even if a round fails, it records cryptographic proof, keeping vault operations auditable and recoverable.

Surge's implementation uses Coinbase's audited cb-mpc library, embedding Lin22 within the signer coordination service.

Signing Flow in Surge (Lin22)

1. Distributed Key Generation (DKG)

• Key shares are generated using Feldman's Verifiable Secret Sharing (VSS).
• Public commitments allow verification that shares are consistent.
• Result: A single Taproot public key with private shares held by signers.

2. Signing Rounds

• Commitment - Signers choose nonces and share hash commitments. Inclusion in this round is mandatory.
• Decommitment & Proof - Nonces and Fischlin ZKPs revealed, invalid proofs flag misbehavior.
• Signature Shares - Honest signers compute valid shares, coordinator aggregates into a single BIP340 Schnorr signature, valid for Taproot.

Lin22 vs. FROST

Two major threshold Schnorr constructions were evaluated:

• FROST (RFC 9591) - Optimized for speed (two rounds).
• Lindell 2022 (Lin22) - Optimized for robustness, with three rounds and formal UC proofs.

Example: 3 of 4 Signing

• FROST → If a signer submits invalid data (e.g., a bad signature share), the session aborts. The honest participants cannot complete the signature. Need to trust coordinator to remove malicious signer.
• Lin22 → If a signer misbehaves, their ZK proof (included in the protocol) reveals them as malicious to the network. The session aborts, but with publicly verifiable evidence of who misbehaved. This will help for slashing and signature share rotation.

dVault remains operable even under Byzantine conditions, ensuring both fault-tolerance and cryptographic accountability.

Surge adopts Lin22 Threshold Schnorr Signatures because resilience and verifiability matters more than speed when securing Bitcoin collateral at scale.

References

• Simple Three-Round Multiparty Schnorr Signing with Full Simulatability
• Cure53 Audit Report: Coinbase cb-mpc Library