In my last Substack, I decoded MPC-TSS and how it plays a crucial role in securing billions of dollars in crypto assets, primarily for institutions. We discussed the evolution and how MPC-TSS has become a prime solution over private key-based simple self-custody, multi-sigs, and SSS-based setups.
MPC-TSS is often misunderstood by retail crypto DeFi enthusiasts and builders due to lack of evangelization, concentration among institutions, and its academic nature. However, institutional adoption is growing and protocols are maturing rapidly.
When I started evaluating MPC-TSS protocols for Surge's decentralized and trust-minimized Bitcoin custody engine, I couldn't find a comprehensive guide that compared different protocols objectively. Most of the available content comes from Wallet-as-a-Service and MPC-as-a-Service providers, but it's naturally restricted to the protocols they use or support. I needed to understand the broader landscape—from FROST (which most Bitcoin DeFi projects are adopting) to Paillier-based protocols like CGGMP—and make informed decisions based on our specific requirements.
After spending considerable time analyzing these protocols, understanding their trade-offs, and documenting my findings, I realized others probably face the same challenge. So I decided to put together this practical framework for evaluating MPC-TSS protocols. I'm also finalizing this framework with an actual database of different protocols and factors that help teams consider these options.
Where MPC-TSS is Being Used Today
Before diving into the evaluation framework, it's worth understanding how different sectors are implementing MPC-TSS in production. This context helps teams learn from similar use cases and understand proven approaches across the ecosystem.
Institutional Custody
Securing billions in assets for hedge funds and corporations through enterprise-grade custody solutions. Coinbase Custody, BitGo, Fireblocks - Focus on regulatory compliance and multi-institutional governance
Wallet-as-a-Service (WaaS)
Abstracting key management complexity for dApp developers and consumer applications. Dynamic, DFNS, Passkey Wallet - Emphasize seamless user onboarding and chain-agnostic infrastructure
Consumer Wallets
Eliminating seed phrases for mainstream adoption while maintaining self-custody principles. Zengo, emerging projects - Focus on user experience and mobile-first implementations
DeFi & Protocol Infrastructure
Securing treasury management, cross-chain bridges, and validator operations. THORChain, Lit Protocol - Focus on Asset security and permissionless key management.
Bitcoin DeFi projects - FROST Leverage for Bitcoin compatibility and trust-minimized bridges
Protocol Implementation Providers
Offering core MPC-TSS primitives that other teams can build upon. Sodot.dev, Silence Laboratories - Provide flexible infrastructure for custom implementations
Each sector faces different trade-offs between security, performance, and user experience. Understanding these patterns helps inform protocol selection for your specific use case.
Why the Migration is Happening
The shift toward MPC-TSS is driven by several factors:
Security: Eliminates single points of failure inherent in traditional key management
Operational efficiency: Reduces the operational overhead of managing multiple signatures and key ceremonies
Regulatory compliance: Better aligns with institutional custody requirements and regulatory frameworks
Chain agnostic: Works across multiple blockchains without protocol-specific implementations
User experience: Enables seamless key management without sacrificing security
Understanding these real-world implementations helps contextualize why choosing the right MPC-TSS protocol is critical for any team building crypto custody solutions.
Let's get started with the evaluation framework.
High-Level factors to consider
Once you have your business or product requirements clear, these 7 high-level factors are the ones to evaluate first. These factors align closely with your business or product requirements and help in evaluating protocols at a more technical level. I'll try to keep it less technical while retaining the essence. Here are the 7 questions to begin with:
What is your trust model? Do all participants (custodians) trust each other, or do you need a trustless setup?
What's your maximum acceptable signing latency?
How many parties need to approve transactions, and what is your governance structure?
How quickly must you recover from key loss or compromise?
What regulatory or audit requirements must you meet?
What blockchains must you support?
Will you manage the infrastructure, or would you prefer to use managed services?
The above questions should help you channel your requirements into something closer to how the protocols work. Let's examine how protocols operate at various stages and so it can help you with better decision making capabilities
#1 Key Generation Architecture
The foundation of any MPC-TSS system is how private keys are initially created and distributed. This directly impacts trust assumptions and operational security. It's one of the factors that confuses people into thinking MPC-TSS is not safe or that it's equivalent to multi-sig or a federated setup.
There are two primary options for key generation:
Trusted Dealer Setup
One party generates the complete private key, splits it into shares, distributes it to participants, and then deletes the original.
Pros: Faster setup and simpler implementation
Cons: Single point of trust during setup, requiring absolute faith in the dealer's key deletion process
Best for: High-trust environments or internal corporate treasury setups
Distributed/Trustless Key Generation (DKG)
Multiple parties collaboratively generate key shares, with no single party ever knowing the complete private key.
Pros: Eliminates single point of trust during setup, enables true decentralization from day one
Cons: Higher computational complexity, longer setup time, more communication rounds ( Learn more about rounds in sections below )
Best for: Multi-institutional custody, high-value assets, regulatory compliance scenarios
#2 Signing process architecture
The method by which transactions are signed determines operational efficiency and ongoing security. There are two dimensions to consider: the foundational approach and execution timing.
Cryptographic approach
Paillier Homomorphic Encryption-based
Each party has Paillier public/private key pairs (separate from the shards generated during key generation). During signing, parties encrypt secret values using Paillier encryption, allowing computations on encrypted data without decryption.
Characteristics: Proven approach with extensive research backing, but computationally heavy and vulnerable to implementation flaws
Protocols: GG18, GG20, CGGMP, Lindell17
Best for: Teams requiring universally composable security guarantees and willing to accept higher computational overhead
Oblivious Transfer (OT) based
Parties can retrieve information without the sender knowing what was retrieved. It's more aligned with computing without revealing what the other party holds.
Characteristics: More efficient leading to higher performance, gaining adoption in MPC-TSS implementations after recent Paillier-based vulnerabilities
Protocols: DKLs19, DKLs23, Hai18
Best for: Performance-critical applications, mobile/edge computing, teams prioritizing efficiency over extensive academic analysis
Schnorr-Optimized approaches
Takes advantage of Schnorr signature's linear structure, which is naturally "MPC-friendly."
Characteristics: Best performance for Schnorr-compatible chains, fewer rounds needed
Protocols: FROST, Lin22
Best for: Bitcoin Taproot, Solana, newer blockchain ecosystems
Execution Timing
Online Signing
All computation happens when a transaction needs to be signed.
Characteristics: Higher latency but secure, as every signing operation requires fresh cryptographic proofs
Offline Preprocessing (Presignatures)
Heavy computation is done in advance; actual signing consumes precomputed values.
Characteristics: Near-instantaneous signing but requires secure storage of preprocessed signature components
#3 Communication rounds and latency
Communication rounds are sequential back-and-forth message exchanges required between parties to complete cryptographic operations (signing). Each protocol makes different security vs efficiency trade-offs that directly impact round count. The core challenge is ECDSA's non-linear structure, which involves multiplicative operations that are inherently difficult to distribute.
The number of rounds depends on the factors like below:
Zero-knowledge proof requirements
Cryptographic approach and execution timing (refer above section)
Security model employed
Simple formula:
Total Latency = (Network Round-Trip Time × Rounds) + (Computation Time × Rounds) + Processing Delays
Protocol Examples:
FROST: 2 rounds (Schnorr-optimized)
DKLs23: 3 rounds (OT-based efficiency)
CGGMP: 4 rounds (Paillier with UC security)
GG18: Up to 9 rounds (extensive verification)
#4 Recovery and resilience mechanisms
This is a very important consideration that determines how the system handles key loss, compromise, or participant unavailability. There are also concerns that old parties can collude to compromise the signer network, which is another topic that confuses developers and causes them to undermine MPC-TSS protocols at first glance.
Recovery Types
Key Refresh/Rotation
Regular key rotation happens without changing the public key, limiting exposure windows and enabling compliance with security policies. This proactive security model ensures that even if key shares are periodically stolen, they become useless after the next refresh cycle. This capability is crucial for MPC-TSS to be successful in high-security environments, as it adds a time dimension to security that traditional key management cannot provide.
Share Recovery
Replacing lost participants without affecting others, enabling operational continuity and governance evolution. Modern protocols also offer identifiable abort capabilities, where malicious nodes can be detected and identified during the recovery process. This ensures that bad actors cannot disrupt operations while remaining anonymous—a significant advancement over older protocols that lack this detection mechanism.
Backup Mechanisms
Hierarchical backups: Multiple recovery levels
Geographic distribution: Disaster recovery across locations
Time-locked recovery: Delayed recovery for enhanced security
#5 Threshold Schemes, Governance, and Curve Support
These are standard and direct factors that determine protocol selection, and they're pretty straightforward. Based on business needs, you should consider:
Quorum Setup
t-of-n schemes: Any t parties out of n total can sign
2PC (Two-Party Computation): Client-server relationship models
Custom governance: Match threshold to organizational decision-making structure
Curve Support
The reason MPC-TSS protocols are chosen is often for multiple curve support, making them chain and ecosystem agnostic. However, specific to Schnorr signatures, there are only a few protocol options available.
Common Curves:
secp256k1: Bitcoin, Ethereum, most blockchains
Ed25519: Solana, Stellar, newer protocols
NIST curves: Enterprise, government compliance
BLS: Ethereum 2.0, some newer protocols
Selection Impact:
Bitcoin/Taproot focus: FROST protocol becomes attractive
Multi-chain support: Universal curve support essential
Enterprise compliance: NIST curve support required
Conclusion
Selecting the right MPC-TSS protocol requires carefully balancing technical capabilities with business requirements. The framework outlined here provides a systematic approach to navigate the complex landscape of available protocols.
I have compiled a comprehensive database of all MPC-TSS protocols and mapped them with respect to the factors discussed here. This database serves as a practical tool for teams evaluating which protocol best fits their specific crypto custody needs.
As the MPC-TSS ecosystem continues to mature, understanding these fundamental trade-offs will become increasingly important for anyone building secure, scalable crypto custody solutions.
This article was written with editorial assistance from Claude AI. All ideas, research, and conclusions are my own
I want to thank Punith and Nakul from our team at Surge for their valuable review and feedback on this framework. Their insights helped refine the technical details and ensure practical applicability for different use cases.
Special thanks to Ido Sofer, Co-founder and CEO at Sodot, for his expert review and contributions to the protocol evaluation criteria.
Additional thanks to Jay Prakash, Co-founder and CEO at Silence Laboratories, for his expert review with particular focus on how fintech stakeholders would perceive this framework. His prior experience working with these audiences helped shape the content to be more accessible and relevant for decision-makers.
Any errors or omissions remain my own, and I welcome feedback from the community to continue improving this evaluation framework.
Recommended Viewing
For a deeper understanding of why age-old cryptographic primitives continue to be used and how they may be limiting innovation in the digital age, I recommend watching this insightful video by Silence Laboratories: The Evolution of Cryptography in the Digital Age. It provides valuable context for understanding the trade-offs between established and emerging cryptographic approaches discussed in this guide.
MPC protocols are handling billions worth of assets and still not prominently spoken about. Thanks for putting this together.