Abstract
Threshold signature schemes (TSS) and secure multi-party computation custody systems are increasingly the default for institutional digital asset custody, replacing hardware security module clusters and native blockchain multisig for many high-value wallets. The appeal is straightforward: TSS produces a single on-chain signature indistinguishable from a single-key spend, eliminating the on-chain overhead and blockchain-specific logic of 2-of-3 or 3-of-5 multisig. What is less frequently examined is what custodians are trading when they move from a transparent on-chain construct to an off-chain cryptographic protocol. This post unpacks the security model differences, the protocol landscape, and the operational failure modes that matter in practice.
How TSS Differs from On-Chain Multisig
Native multisig (Bitcoin’s OP_CHECKMULTISIG, Ethereum’s contract-based multisig like Safe) encodes the signing policy in script or contract code that is publicly verifiable on-chain. Any observer can confirm that a given transaction required M-of-N specific keys to authorize. TSS constructs the signing key as shares distributed across parties; no single party holds the private key, and the signing ceremony runs an MPC protocol that produces a valid signature without ever reconstructing the key. From the blockchain’s perspective, the transaction looks like a single-key spend. This has two consequences: on-chain fees are lower and the policy is simpler to verify at the protocol level, but auditability of the signing policy requires trusting the MPC system’s internal access controls rather than reading them from the chain.
Protocol Landscape - GG18, GG20, CGGMP21
The most widely deployed TSS protocols for ECDSA signing are GG18 (Gennaro-Goldfeder 2018), GG20 (the 2020 revision), and CGGMP21 (Canetti, Gennaro, Goldfeder, Makriyannis, Peled 2021). GG20 became the default in custody platforms including Fireblocks and many banks’ internal MPC stacks due to its practical performance on cloud hardware. CGGMP21 addressed security issues found in GG20’s proof of correctness under certain adversarial party behaviors, and as of 2025-2026 it is the recommended protocol for new deployments. For Schnorr-based chains (Bitcoin taproot key-path spends, Zcash, Solana), FROST (Flexible Round-Optimized Schnorr Threshold signatures, RFC 9591 finalized in 2024) is now the standard; its simpler structure compared to ECDSA TSS protocols makes implementation verification more tractable.
Key Refresh and Share Lifecycle Management
One operational property of TSS that often surprises teams moving from hardware multisig is key refresh. In a well-designed MPC custody system, share refresh is a periodic operation that rotates the individual shares without changing the public key or requiring an on-chain transaction. This limits the window of exposure if a share is compromised: an attacker who obtains a share before a refresh and after a refresh holds two mathematically unrelated values, neither sufficient to reconstruct the key without contemporaneous shares. Fireblocks, Sepior (acquired by Coinbase), and open-source libraries like tss-lib (Go, by bnb-chain) and multi-party-ecdsa (Rust, by ZenGo) all implement periodic refresh. The operational risk is that refresh ceremonies require liveness of a quorum of parties; a refresh that fails or is skipped creates a window where the security model degrades silently.
Failure Mode Catalogue
Three failure modes dominate incident reports in MPC custody. First, availability failure during signing: TSS requires online participation from a threshold of parties, and if a cloud availability zone is down or a hardware token is lost, signing stalls. Unlike on-chain multisig where backup keys can be published, TSS backup procedures are more complex and must be established before the incident. Second, proactive secret sharing gaps: not all deployed systems implement proactive refresh; systems running GG18 without refresh have a weaker long-term security model than their documentation implies. Third, audit trail gaps: because signing happens off-chain in the MPC protocol, audit logs are generated by the custody platform’s software rather than derived from chain data; platform compromise or log deletion can obscure signing history in ways that on-chain multisig cannot.