Proven security: Why Turnkey built beyond MPC

In 2023, Fireblocks discovered several zero-day vulnerabilities in widely used multi-party computation (MPC) protocols.

Zero-day vulnerabilities are the black swans of cybersecurity, flaws unknown to developers and impossible to defend against until they’re discovered. They’re called “zero-day” because attackers can exploit them before any patch exists, and defenders have zero days to prepare or respond.

Fireblocks named the vulnerabilities they discovered BitForge, as they allowed attackers to exploit flaws in multi-party computation (MPC) protocols to forge digital signatures. The discovery revealed weaknesses in several widely used MPC implementations, including those deployed by Coinbase, ZenGo, and Binance.

For developers, web3 builders, and fintech teams that manage valuable digital assets, incidents like BitForge underscore the importance of choosing the right foundation for cryptographic security. 

Most modern custody architectures are built around either multi-party computation (MPC) or Trusted Execution Environments (TEEs). Turnkey evaluated both extensively and ultimately chose TEEs as the foundation for verifiable, scalable, and transparent protection of private keys. 

This article explores why that choice was made and the reasoning behind Turnkey’s decision to avoid MPC-based wallets at this time

What is multi-party computation and why it became popular

Multi-party computation (MPC) is a cryptographic method that allows multiple independent participants to work together on a shared computation without revealing their individual secrets. In digital asset security, this means a private key is never stored in one place. 

Many implementations divide the key into secret shares and distribute them across different machines or organizations. Others use Distributed Key Generation (DKG), where shares are created collaboratively, ensuring the private key never exists in a single place, even during generation.

When a computation or operation requires authorization, each participant uses their share to perform part of the process. At no point is the full secret reconstructed or exposed. The participants combine their individual outputs to produce a final, valid result such as a digital signature or decryption, without any single entity ever possessing the complete key.

This design became popular because it eliminates the traditional single point of failure: the private key. If one MPC server or participant is compromised, the attacker can only access that server’s key share, and will still be unable to access the entire key. 

By sharing control across multiple parties, MPC protects cryptographic keys while enabling flexible and collaborative key management. For financial institutions and digital asset custodians, this combination of redundancy and decentralization has made MPC an appealing choice for secure wallet infrastructure.

How MPC works in practice

Multi-party computation systems rely on highly complex cryptographic protocols that coordinate multiple participants to jointly compute a result, such as a valid digital signature, without ever revealing or reconstructing the private key. 

Each participant, or node, performs computations on its secret share and exchanges encrypted messages with the others. This message passing continues through multiple rounds until the group collectively produces a single output, like a signed cryptocurrency transaction

These workflows demand constant synchronization and trust in the correctness of every participant’s implementation. Even small timing or network issues can create opportunities for subtle bugs or misconfigurations. But in the world of cryptography, even subtle, seemingly-minor bugs can frequently be catastrophic.

Despite this complexity, MPC remains a common foundation for digital asset custody solutions, institutional wallet systems, and shared transaction signing environments, where multiple parties, such as co-signers or custodians, must approve an action.

The hidden complexity and fragility of MPC

Multi-party computation (MPC) is mathematically elegant but highly intricate, especially when applied to the digital signature standards that underpin most blockchain systems, such as ECDSA (Elliptic Curve Digital Signature Algorithm) and Ed25519 (Edwards-curve Digital Signature Algorithm).

These algorithms are time-tested, standardized by organizations like NIST and IETF, and have undergone decades of cryptographic analysis and real-world validation. 

By contrast, MPC implementations reproduce those same signing operations through distributed cryptographic protocols, splitting key material across multiple parties or devices. Each implementation must coordinate multiple message exchanges, zero-knowledge proofs, and mathematical operations without introducing a single point of leakage or failure. 

Even a small implementation bug, such as in serialization, nonce handling, or key generation, can compromise the entire security model.

Turnkey’s own evaluation of the field included reviewing Coinbase’s open-source Kryptology MPC library, developed by one of the strongest engineering teams in the industry. Despite that pedigree, the library suffered from serious vulnerabilities and was ultimately deprecated after repeated issues were discovered and disclosed.

Examples like this reveal that MPC remains an emerging, unstandardized field. Unlike ECDSA or Ed25519, whose correctness and resistance to attack have been verified over decades, many MPC schemes are still evolving, with limited peer review and no universal compliance framework. 

As a result, their maturity and verifiability are still low, and critical flaws can surface long after deployment, posing significant long-term risks for any system built upon them.

These flaws come out in some very important areas when considering the security, speed, and fragility of the overall infrastructure. Here are five things to consider when considering a provider that uses MPC for their security.

1. Multi-party computation doesn’t always mean the system is secure 

Secure multi-party computation is often described as eliminating single points of failure, but that protection only holds if each key share truly lives in a separate and independent security domain. 

In theory, this means that every participant in the protocol operates a unique implementation, on its own hardware, managed by different teams, checking authorization independently, with no overlapping infrastructure or access privileges. Only under these conditions can an attacker be forced to breach multiple, isolated environments to compromise a private key.

In reality, many MPC deployments fall short of this ideal. The “independent” signers often run on the same cloud provider, share the same operating system, or rely on identical software stacks. If a single vulnerability affects that shared infrastructure, all key shares can be exposed at once.

When this happens, the fundamental security promise of MPC breaks down. Rather than creating multiple layers of defense, overlapping infrastructure and common dependencies can recreate the same single point of failure MPC was designed to prevent.

2. Scalability and performance tradeoffs with MPC

MPC’s distributed nature also introduces major performance challenges. Because each signer must communicate with every other participant during the signing process, generating a single digital signature requires multiple rounds of data exchange. This coordination adds latency, increases bandwidth usage, and raises operational costs, especially at scale.

Multi-party threshold schemes are inherently slower than single-enclave signing because they depend on network synchronization and message passing between nodes. For high-frequency transaction systems, this delay can make MPC-based wallets impractical.

3. Cost, complexity, and operational fragility in MPC deployments

Building and maintaining a truly secure MPC system is costly and operationally demanding. To achieve real fault tolerance, each participant in the protocol should ideally run its own independent implementation, hosted on separate infrastructure, reviewed by different security teams, and audited by third parties. 

This level of redundancy requires maintaining multiple cryptographic libraries, extensive testing frameworks, and strict change management, making it both expensive and slow to develop.

In practice, many so-called MPC solutions take shortcuts. They often colocate signers on the same cloud environment or reuse the same software stack to reduce costs. These design compromises defeat the entire purpose of MPC, reintroducing single points of failure that the model was meant to eliminate.

For developers and financial institutions, this complexity also creates operational fragility. Each new update or audit introduces risk, and debugging issues across distributed systems can slow down product iteration. What begins as a theoretically elegant model quickly becomes an engineering and compliance burden that limits agility rather than enhancing security.

4. Post-quantum risks for MPC systems

Another challenge for MPC lies ahead: the shift toward post-quantum cryptography. If quantum computers become powerful enough to break current public-key algorithms like ECDSA and RSA, all existing MPC protocols built on these primitives will become obsolete.

The National Institute of Standards and Technology (NIST) has already recommended that non-quantum-resistant digital signature algorithms be deprecated by 2030. This means every MPC signature scheme and protocol that depends on today’s cryptographic assumptions will require a complete rewrite, a multi-year effort involving new algorithms, audits, and implementations.

5. Failure to protect against the most common attack vector: Authorization

Most real-world digital asset breaches don’t stem from broken cryptography or stolen private keys. They come from authorization failures, when legitimate systems are tricked into approving malicious actions.

Once attackers gain authorized access, they can initiate valid transactions, drain wallets, or alter policies without ever touching the underlying cryptographic mechanisms. In these scenarios, even perfect key confidentiality offers no protection.

Multi-party computation (MPC), while designed to protect private keys from compromise, does little to defend against these kinds of attacks. It addresses only a narrow slice of the real attack surface, leaving the majority of modern breach vectors, credential theft, phishing, and compromised integrations largely untouched.

This means it can safeguard the key material yet still fail to protect the intent behind the signature. The system will securely produce the wrong outcome, a mathematically valid signature on a malicious transaction, because authorization logic sits outside its protection boundary. 

Why Turnkey uses TEEs instead of MPC

Turnkey’s architecture is built on Trusted Execution Environments (TEEs) that provide a verifiable foundation for secure digital asset custody. 

A TEE is a dedicated, isolated area of hardware, called an enclave, where sensitive operations, like key generation and transaction signing, take place. Private keys exist only inside this isolated space, never leaving the enclave unencrypted or exposed to the host system.

Each enclave uses hardware-based memory encryption and integrity verification to ensure that even privileged users or cloud administrators cannot access its contents.

One great feature of many TEEs is verifiability. These TEEs use remote attestation, a cryptographic process that allows one computer to confirm that another system is running trusted, untampered software inside a secure hardware environment. 

Remote attestation provides an additional layer of transparency, allowing  anyone to verify that the enclave is running unmodified, approved code. TEEs and remote attestation minimize the attack surface, simplify cryptographic design, and replace the assumptions of security found in MPC systems with verifiable proof of security.

Fast, scalable, policy-enabled, and post-quantum prepped

By running signing operations inside isolated enclaves, Turnkey can perform cryptographic signing at near-native speed. Each enclave securely decrypts the key in protected memory, signs the transaction, and then wipes the data, all within a verifiable environment. 

This design allows Turnkey to horizontally scale to millions of wallets and keys while maintaining low latency and strong cryptographic security, achieving both speed and safety without the performance burdens of MPC.

Because TEEs encapsulate existing cryptographic logic inside verifiable hardware, Turnkey can more easily upgrade to quantum-safe primitives without reengineering the entire signing protocol. This modular design ensures that as cryptographic standards evolve, Turnkey’s infrastructure remains secure, flexible, and forward-compatible.

Turnkey also addresses authorization failures directly through its policy engine, which also runs inside these trusted execution environments. Every transaction request must meet strict policy conditions before it is ever signed. These policies define who can sign, under what circumstances, and with what limits, creating granular, programmable access control.

An MPC-based signing setup, by contrast, provides no inherent solution to authorization risks. Even if keys are split across multiple parties, an attacker who gains approval at the policy layer, or exploits a poorly implemented authorization process can still execute malicious transactions. Turnkey’s design integrates policy enforcement at the same trust boundary as key protection, eliminating that gap entirely.

Why verifiability matters more than distribution

MPC’s primary advantage lies in distribution, spreading key shares across multiple systems to reduce reliance on any single one. But distribution alone does not guarantee trust. If all participants share the same cloud infrastructure, authorization process, dependencies, or codebase, the supposed independence collapses into a single security domain.

Turnkey’s approach, rooted in verifiability, rather than distribution ensures that each enclave’s code, identity, and runtime state can be independently verified through remote attestation. This means every cryptographic operation can be publicly proven to occur within a genuine, untampered environment.

In a world where trust must be earned and demonstrated, verifiability has become the new gold standard for blockchain signing and digital asset custody. Turnkey’s enclave-first architecture delivers that assurance, offering both transparency and security at scale without the complexity or fragility of MPC.

Addressing concerns about TEE vulnerabilities

No trusted hardware is immune to risk, but Turnkey’s security model is designed to mitigate every known category of TEE vulnerability. Common attack vectors include unauthenticated host-to-TEE communication, API manipulation, PKI spoofing, and side-channel attacks. Each of these has been considered and countered within Turnkey’s design.

Turnkey ensures that enclaves never trust the host system directly. Every action a TEE takes must be authenticated by a verified user credential or another approved enclave. API interfaces between the host and TEE are regularly fuzz-tested to eliminate input manipulation attacks. 

To prevent PKI-related compromise, Turnkey relies on AWS Nitro’s attestation chain, which would require a deep compromise of AWS’s hardware root of trust, an extraordinarily unlikely event. And to reduce side-channel exposure, all hosts run Talos Linux, a minimal, hardened OS with no SSH access, further limiting vectors for observation or tampering.

This defense-in-depth strategy ensures that even if a theoretical attack on trusted hardware emerged, Turnkey’s multi-layered controls would make exploitation extremely difficult in practice.

Turnkey: Proven simplicity, verifiability, and security at scale

Turnkey’s decision to avoid MPC is not a rejection of innovation. It's a deliberate choice to prioritize cryptographic simplicity, proven security, and verifiable isolation. MPC remains an impressive and evolving field, but its complexity, fragility, and dependence on unproven implementations make it less suitable for securing high-value digital assets today.

By building on a foundation of trusted execution and remote attestation, Turnkey delivers a system that is both transparent and scalable. Private data and cryptographic keys remain protected inside verifiable enclaves, while developers and institutions gain the confidence of reproducible, provable security without the performance or operational tradeoffs of MPC.

As multi-party computation continues to mature, Turnkey remains open to integrating it in the future. But that will only happen when MPC implementations can meet the same high bar of verifiability, resilience, and trust-by-proof that defines Turnkey’s enclave-first architecture.

Get started with Turnkey today. 

‍