👥 Distributed Custody Network (DCN)

A Vault spend that requires loanPubkey authorization is signed by the Distributed Custody Network (DCN). The DCN is a set of independent signer organizations running threshold Schnorr signing.

The current deployment uses a 3-of-4 signing threshold for Bitcoin spends.

No single signer ever holds the full signing secret; each signer only holds a share. Signatures are produced only when quorum participation and policy checks both pass.

Signer

Signing Capabilities

Capability	Scheme	Used for	Protocol
Threshold Schnorr	BIP340	Vault spends on Bitcoin (Repayment, Liquidation)	Lin24
Threshold ECDSA	secp256k1	EVM-side signatures where a quorum-controlled key is required (e.g. multi-admin contract operations)	Multiparty ECDSA (Applied Cryptography Group specification), an OT-based n-party design building on Haitner et al. (2022) multiplication protocol

Both protocols share the same decentralized signer organisations, KeyProtector storage model (Key Shard Security), refresh and reshare flows (Key Lifecycle, Reshare & Onboarding), and the same per-signer policy stack (Signing Policy) - only the signature output differs.

Lin24 Threshold Schnorr

Surge uses Lin24 - Y. Lindell, Simple Three-Round Multiparty Schnorr Signing with Full Simulatability (ePrint 2022/374, republished as CiC 2024). The two names refer to the same protocol.

Why threshold specifically:

Taproot requires Schnorr. BIP340 defines Schnorr for Taproot spends. Lin24 outputs a standard BIP340-compatible aggregate signature.
No complete private key exists anywhere. After distributed key generation (DKG), each signer holds only a share. Reconstructing the key would require compromising t signers simultaneously. There is no wallet file, no seed phrase, and no vault where the full key lives "for disaster recovery."
Misbehaviour is identifiable, not just detectable. Lin24 includes Fischlin non-interactive zero-knowledge proofs of knowledge at the decommitment step. A signer that submits malformed data leaves a publicly-verifiable proof of their specific misbehaviour, which drives automated exclusion and reshare.

Why Lin24 over FROST

FROST (RFC 9591) is the other widely-cited threshold Schnorr construction. It is faster - two rounds instead of three - but trades robustness for speed.

Property	FROST	Lin24
Signing rounds	2	3
Security proof	UC-secure; aborts on any signer fault	UC-secure with full simulatability via Fischlin ZKPs
Abort handling	Session halts; coordinator trusted to identify cheater	Cryptographic evidence identifies the misbehaving signer, enabling rotation
DKG	~2 rounds (Pedersen VSS)	5+ rounds (Feldman VSS with stronger consistency)
Output witness	BIP340 Schnorr (64 bytes)	BIP340 Schnorr (64 bytes)

In a threshold signing session, if one signer submits invalid data:

FROST aborts with no attributable evidence. The coordinator must decide who cheated; if the coordinator is compromised, the wrong signer can be ejected, or the attack can persist across retries.
Lin24 aborts with Fischlin ZKPs that any observer can verify. The faulty signer is identifiable without trusting the coordinator, and can be excluded from the next session.

For a system that routinely signs spends against live Bitcoin collateral, this extra attribution is worth one additional round-trip.

DKG & Key Lifecycle

At vault-key creation, the signer set runs distributed key generation using Feldman's Verifiable Secret Sharing (VSS). The protocol publishes commitments that let each party verify its own share is consistent with the collective polynomial before accepting it. The output is a single BIP340-compatible x-only pubkey (the loanPubkey embedded in the Repayment and Liquidation leaves) and private shares held by the signers.

The full key lifecycle is documented in the MPC pages: DKG and refresh, PVE backup and recovery, signing policy, and reshare for onboarding and rotation.

Signing Session - Three Rounds

Each Bitcoin spend triggers one Lin24 session over the message hash (the BIP341 sighash for the Taproot spend).

Commitment. Each participating signer samples a nonce and broadcasts its hash commitment. Participation in this round is mandatory; a signer that fails to commit is excluded from the session.
Decommitment & ZKPs. Signers reveal nonces with Fischlin zero-knowledge proofs. Failed proofs identify faulty participation and the session aborts safely.
Signature shares. Honest signers compute their signature shares and the coordinator aggregates them into a single BIP340 Schnorr signature. Non-participating or faulty signers contribute no share.

The aggregate signature is submitted in the Taproot script-path witness. The signature component is standard BIP340 Schnorr.

Trust Model

Component	Trusted to	Not trusted for
Individual signer	Hold exactly one key share, enforce the signing policy locally, refuse to sign on invalid authorization	Knowing the full private key (cryptographically cannot) unilaterally moving BTC (script requires cooperation per leaf)
Coordinator / leader	Sequence sessions, collect shares, publish aggregate signature	Authorizing spends; fabricating authorization; bypassing per-signer validation
Signer-node crypto implementation	Correct implementation of Lin24 and supporting primitives	Policy decisions (what is signed, who can request, when to sign)
Surge signer orchestration code	Signing policy, reshare orchestration, Bitcoin tx and witness construction around the Lin24 output	Cryptographic security of the underlying MPC protocol

The adversary model we design against:

Up to t - 1 compromised signers - collusion remains below threshold. No signature is produced without an additional honest signer. For a 3-of-4 deployment this means any two compromised signers are recoverable without loss.
Compromised coordinator - cannot forge authorization, cannot coerce signers into producing signatures outside policy, and cannot substitute the signed message without per-signer validators detecting it.
Network attacker - mTLS between signers with pinned peer identities; manual peer certificate verification that enforces expected CN bindings, not just CA trust (see Transport Security).
A misbehaving signer that fakes liveness - detected via the Fischlin ZKP check and removed from active quorum by policy.