A practical guide to evaluating MPC-TSS Protocols for Crypto custody

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.

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.

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

Abstracting key management complexity for dApp developers and consumer applications. Dynamic, DFNS, Passkey Wallet - Emphasize seamless user onboarding and chain-agnostic infrastructure

Eliminating seed phrases for mainstream adoption while maintaining self-custody principles. Zengo, emerging projects - Focus on user experience and mobile-first implementations

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

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.

The shift toward MPC-TSS is driven by several factors:

1. Security: Eliminates single points of failure inherent in traditional key management

2. Operational efficiency: Reduces the operational overhead of managing multiple signatures and key ceremonies

3. Regulatory compliance: Better aligns with institutional custody requirements and regulatory frameworks

4. Chain agnostic: Works across multiple blockchains without protocol-specific implementations

5. 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.

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:

1. What is your trust model? Do all participants (custodians) trust each other, or do you need a trustless setup?

2. What's your maximum acceptable signing latency?

3. How many parties need to approve transactions, and what is your governance structure?

4. How quickly must you recover from key loss or compromise?

5. What regulatory or audit requirements must you meet?

6. What blockchains must you support?

7. 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

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:

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

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

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.

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

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

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

All computation happens when a transaction needs to be signed.

Characteristics: Higher latency but secure, as every signing operation requires fresh cryptographic proofs

Heavy computation is done in advance; actual signing consumes precomputed values.

Characteristics: Near-instantaneous signing but requires secure storage of preprocessed signature components

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)

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.

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.

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.

• Hierarchical backups: Multiple recovery levels

• Geographic distribution: Disaster recovery across locations

• Time-locked recovery: Delayed recovery for enhanced security

These are standard and direct factors that determine protocol selection, and they're pretty straightforward. Based on business needs, you should consider:

• 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

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

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.