Dec 19, 2024
This research is a joint initiative between LlamaRisk and Steakhouse Financial 🤝
1. Introduction
In decentralized finance (DeFi) protocols, secure operational Access Control Management is essential for managing treasury transactions, pausing contracts, setting protocol parameters, and implementing governance decisions. While Multiparty Computation (MPC) Wallets offer an alternative to traditional multisignature setups by leveraging advanced cryptography to protect assets and enhance operational efficiency, they also introduce tradeoffs that must be carefully evaluated.
This report examines the advantages of MPC technology, evaluates key providers and use cases, and provides a framework to guide adoption decisions based on technical and operational considerations.
1.1 What is an MPC wallet?
1.1.1 Public Key Cryptography
One of the core concepts that is typical for managing user interactions in blockchain systems is public key cryptography.
A private key is a unique, secret piece of information used to prove ownership and authorize transactions. It acts as a password, granting control over the funds or assets associated with the corresponding public key. A public key is derived from the private key using cryptographic algorithms and serves as an address for receiving funds or interacting with the blockchain. While the public key is visible and shared openly, it does not expose the private key due to the one-way nature of the cryptographic process.
In blockchain operations:
The private key signs transactions to confirm authenticity and ownership.
The public key allows anyone to verify the validity of the signed transaction without revealing the private key.
In conventional Single-Signature Wallets (a.k.a. Externally Owned Accounts, or EOAs), anyone who possesses the private key can generate a signature and thus sign and authorize transactions. There is no method to delegate complete or partial access to funds, and the loss of a private key means a loss of funds. Single-Signature Wallets are conventionally used predominantly by individuals.
1.1.2 MultiSig Wallet
A multisignature wallet (MultiSig wallet), unlike single signature wallets, requires multiple private keys (from cosigners) to authorize a single transaction. They use an M-of-N algorithm, where a transaction requires at least M private keys (signatures) from a total of N available keys to proceed. For instance, in a 3-of-5 configuration, three out of five private keys are required to authorize a transaction.
The diagram illustrates how this works: multiple cosigners (Cosigner 1, Cosigner 2, and Cosigner 3) each generate their individual signature, which collectively authorizes access to the shared assets. As only 3 of 5 signatures are required, Cosigners 4 and 5 are not required to sign their transactions, or alternatively their signature or rejection would not deter the authorization from taking place.
1.1.3 MPC Wallet
MPC wallets rely on Multi-Party Computation (MPC), a cryptographic framework that allows multiple participants (referred to as "parties") to collaboratively perform computations over their private inputs while keeping those inputs confidential.
In the context of wallets, MPC is used to split the private key into unique cryptographic shares held by different participants. These shares are never reconstructed into the original private key, ensuring that no single entity can compromise the wallet. During a transaction, the private key shares are utilized by the parties to collaboratively compute a result, such as a cryptographic signature, without ever revealing the private key. This process is enabled through cryptographic protocols that ensure confidentiality and correctness of the computation.
While various MPC wallets rely on different cryptographic methods, common foundational protocols include - Shamir's Secret Sharing (SSS), a technique for splitting a secret into multiple shares; Yao's Garbled Circuit used for more general-purpose secure computations; and Fully Homomorphic Encryption (FHE) allows computations on encrypted data. This signature is then used to authorize and execute transactions on the blockchain, granting access to the wallet’s assets.
1.1.4 Threshold Signature Schemes (TSS)
Threshold Signature Schemes (TSS) are a specialized cryptographic application of MPC designed to enable distributed digital signature generation securely. At a high level, the private key S is represented as a mathematical secret, split into multiple shares using a polynomial f(x)=a0+a1x+⋯+at−1xt−1, where a0=S is the secret. Each participant holds one share, f(1),f(2),…,f(n). To generate a valid signature, a subset of participants meeting the predefined threshold t combines their shares using techniques like Lagrange interpolation, enabling the system to compute the signature f(0) without ever reconstructing the private key. This signature can then be used to authorize and execute transactions, ensuring security and trust while maintaining flexibility in participant involvement.
1.1.5 Adding and removing key shares
To add a new signer in a threshold signature scheme (TSS), the system initiates a re-sharing process. The original secret S remains unchanged, and a new polynomial f′(x) is generated to create updated key shares. Each participant, including the new signer, receives a fresh share derived by evaluating f′(x) at distinct points (f′(1),f′(2),f′(3),…). However, from a cryptographic standpoint, the old shares are not truly invalidated: as long as they reconstruct the same secret S, any quorum of old shares can still produce a valid signature. The benefit of re-sharing (without exposing S) is that the new signer gains a share corresponding to the same secret, allowing the system to adapt to new participants. In practice, a TSS protocol may enforce that only the new shares (i.e., the new polynomial) are allowed to authorize transactions, but mathematically, the old shares remain valid unless S is changed.
1.1.6 Changing signing threshold
To change the threshold $t$ in a threshold signature scheme (TSS) without altering the set of signing parties, the system similarly initiates a re-sharing process. The original secret $S$ remains the same, but a new polynomial $f'(x)$, with a degree reflecting the updated threshold, is generated. The new key shares $\bigl(f'(1), f'(2), f'(3), \dots\bigr)$ are then securely distributed to the existing participants. Again, because $S$ does not change, the old shares still interpolate the same secret —they are not cryptographically invalidated. For instance, increasing $t$ from 2 to 3 means creating a degree-2 polynomial so that any 3 shares are needed to reconstruct $S$. This enhances security *in the new scheme* by demanding more participants to sign. However, purely from a cryptographic angle, unless $S$ is replaced by a new secret, old shares remain a potential way to reconstruct $S$.
1.2 Transaction Flow
A typical MPC Wallet Transaction starts with a user initiating a transaction which prompts the server to generate a unique, encrypted random number. This number is sent to the user, who then decrypts it, signs the transaction using their private key share, and sends this signature back to the server. The server combines signatures from all necessary parties. If all shares are valid and meet the protocol requirements, the transaction is authorized and broadcasted; otherwise, it is rejected.
1.3 System Architecture
The technical architecture of MPC wallets varies based on the provider, but we aim to present a generalized archetype. The MPC implementation described here draws inspiration from this AWS Block article.
In general, a MPC wallet architecture utilizes Distributed Key Generation (DKG). This process divides the private key into "shards," or cryptographic pieces, and assigns each shard to a different participant. Each shard is unique, and no single shard can recreate the private key independently. This ensures that the private key never exists as a complete entity at any point in the system, significantly reducing the risk of compromise. It is common for MPC provider hold a key shard in a MPC TSS wallet.
Each shard is stored and operated within a secure processing unit, often referred to as an enclave or isolated environment. These units are designed to perform cryptographic operations, such as signing transactions, without exposing the shard or its underlying data. The secure environment ensures that even if the broader system is compromised, the shard remains inaccessible. These units act as the backbone of the MPC wallet, securely enabling operations without ever reconstructing the private key.
To sign a blockchain transaction, the secure processing units collaborate by exchanging cryptographic messages. This exchange takes place over a zero-trust network, where the system assumes that the communication channel itself may not be trustworthy. Messages are encrypted and signed, ensuring their integrity and authenticity. A message broker, such as a queue or streaming service, facilitates this exchange without gaining access to the actual data. This design ensures that sensitive information is protected throughout the signing process.
Once the secure processing units have completed their collaboration, they collectively produce a single, valid blockchain signature. This signature is indistinguishable from one generated by a traditional single-key wallet and is used to authorize transactions. By leveraging MPC protocols, the private key remains fragmented, never reconstructed or exposed during the signing process.
1.4 Risks & Vulnerabilities
1.4.1 Structural or mathematical risks
1.4.1.1 Theoretical Exploits in Threshold Signature Schemes (TSS)
A significant theoretical exploit in the context of MPC wallets is the TSS Shock Attack, outlined by Verichains. This vulnerability targets improperly implemented threshold signature schemes (TSS) in MPC wallets, exploiting weak randomness during key generation or signature computation. The attack demonstrates how an adversary can deduce private key components, potentially compromising the entire wallet.
The implication of this is that poor randomness implementation or lack of key verification during distributed key generation (DKG) makes MPC wallets vulnerable to such attacks. To mitigate this, robust randomness sources and cryptographic validation checks must be implemented at every stage of TSS.
1.4.2 Operational and idiosyncratic risks
1.4.2.1 Elliptic curve operational handling
In the BitForge vulnerablity event, Fireblocks researchers uncovered critical flaws in the cryptographic libraries of over major wallet providers. These vulnerabilities stemmed from improper handling of elliptic curve operations used in digital signature algorithms, such as ECDSA and EdDSA. This misimplementation could have enabled attackers to deduce private keys of different MPC TSS implementations. Details of the attack are beyond the scope of this article but it documented in this research piece by Makriyannis et al., 2024.
1.4.2.2 Key man and concentration risks
The Multichain hack, resulting in over $130 million in losses, illustrates how poor operational practices within an MPC setup can override even sophisticated cryptographic safeguards. According to the Mutlichain Team, when their CEO Zhaojun was detained on May 21, 2023, all critical MPC node servers—maintained under his personal cloud account—were abruptly out of reach. This centralization of infrastructure and keys with a single individual meant that mnemonic phrases, hardware wallets, and operational funds were also beyond the team’s control. Following this loss of access, an unauthorized cloud login on July 7 allowed attackers to misuse improperly managed key shards, reconstruct private keys, and transfer funds from MPC addresses without the necessary oversight.
Such a scenario could have been mitigated through a combination of technical and organizational measures. Distributing key shards across multiple, independent entities and securing them within trusted, tamper-proof environments would limit the damage from a single compromised account. Employing strict verification layers—such as transaction-specific context checks and replay protection—would prevent attackers from reusing valid signatures across multiple transactions. Finally, establishing contingency plans, shared governance models, and multi-party authorization processes would ensure the system remains operable and secure even if one key individual or component becomes unavailable. In short, robust MPC setups hinge not only on cryptography, but also on strong operational frameworks and decentralized controls.
1.5 Transparency in MPC Wallets
As seen in the System Architecture of the MPC Wallet - a valid signature is constructed off-chain. As a result the on-chain footprint is identical to simple EOA address. As illustration see below the table comparing EtherScan snapshot of a simple EOA, Multisig and MPC Wallet.
Multi-Party Computation Wallet
To date there are limited transparency practices available to audit MPC systems offered by providers. Transparency practices can be summarized by open-source cryptographic libraries and certification.
Bitgo and Fireblocks have both open-sourced their cryptographic libraries that underlies their MPC system. This allows the independent verification on robustness of the cryptography and allowed the uncovering of vulnerabilities in Bitgo-TSS such as BitForge. However, it does not by itself provide guarantees of a correct operational set-up.
Providers offering Multi-Party Computation wallets often obtain SOC 2 certifications to demonstrate their commitment to robust internal controls and data security.
SOC 2 reports can be issued as:
Type 1: Assesses the design of controls at a specific point in time. It provides a snapshot of the organization's control environment.
Type 2: Evaluates the operating effectiveness of controls over a period, typically between 3 to 12 months. This type offers a more comprehensive assessment of how controls function over time.
In addition, providers get certifications for the adherence to ISO standards, which establish international benchmarks for information security, cloud-specific security, and privacy.
Typical certification include:
ISO/IEC 27001: Focuses on the establishment, implementation, and maintenance of an Information Security Management System (ISMS)
ISO/IEC 27017: Provides guidelines for enhancing information security in cloud services
ISO/IEC 27018: Offers a code of practice for the protection of personally identifiable information (PII) in public clouds acting as PII processors
These certifications are a commendable source of third-party verification of operational processes and practices. However, they fall well short of the expectations of full operational transparency that DeFi protocol users may come to expect. For instance, the reports themselves are no guarantee of process integrity and are in most instances kept private for operational security reasons. Independent verifiability of a particular MPC setup remains difficult regardless of the presence of a third-party auditor or certification authority.
1.6 Regulatory landscape
Multi-party computation (MPC) has yet to achieve official recognition within global crypto custody legal frameworks. This may stem from the inherently technical nature of the solution. While MPC and Hardware Security Modules (HSMs) are established technologies in digital asset custody beyond the crypto sector, neither has a clearly defined legal status yet. Regulatory consultations and guidelines occasionally reference MPC’s distributed security features, which enable multiple parties to jointly compute functions while maintaining the privacy of individual inputs, but these references remain sparse and informal.
To date, lawmakers have concentrated on delineating custodial and non-custodial wallet frameworks. This distinction revolves around the concepts of control and possession. Possession generally pertains to the physical custody of an asset, whereas control relates to the ability to manage or direct its use, irrespective of physical possession. For example, possession of the private key linked to a digital wallet grants control over the assets within that wallet, enabling the holder to execute transactions. Conversely, one might hold possession of a digital asset without control if they lack the necessary keys or if the asset is held in a custodial service where the service provider retains control over the keys.
When custodial services incorporate MPC, the technology is often viewed as a robust means of enhancing key security. The scope of custody may vary depending on the system’s architecture and the custodian’s anticipated responsibilities. For instance, some designs require a minimum number of keys or key fragments, distributed among multiple parties, to authorize transactions. In such arrangements, neither the keys nor their individual components held by the client or the custodian alone are sufficient to complete a transaction.
An alternative configuration involves the client retaining full possession of the minimum number of key shares necessary to execute a transaction. In this case, the custodian or wallet service provider holds additional key shares that are insufficient on their own to authorize transactions. Here, the custodian acts as a backup signer, stepping in only if the client loses access to their keys.
The process of splitting cryptographic keys into multiple parts, often referred to as “key sharding,” bolsters security by distributing the key fragments across various locations or entities. Each entity holds only a portion of the key, ensuring that no single party can independently reconstruct it. Key shares are combined to authorize transactions without reconstituting the full key, preserving security even if one share is compromised. This technique has significant implications for compliance with regulatory standards.
Although “key sharding” lacks a formal legal definition as of November 2024, regulatory bodies are increasingly acknowledging its relevance in digital asset custody.
1.6.1 European Union (MiCA)
Under the EU’s Markets in Crypto-Assets Regulation (MiCA), MPC as a custody mechanism can be assessed within the framework of crypto-asset custody and administration services. Article 3(1)(17) MiCA defines custody as the safekeeping or controlling, on behalf of clients, of crypto-assets or the means of accessing such assets, including private cryptographic keys. Recital 83 further clarifies that service providers offering custody must conclude agreements with clients detailing the service’s nature, which may involve either holding crypto-assets or the means of accessing them. In some cases, clients may retain control, while in others, the service provider may assume full control.
MiCA does not explicitly define “control” in relation to cryptographic keys, leaving room for interpretation. Hybrid custodial solutions that limit service provider reliance, such as those employing MPC for co-signing or backup roles, may fall outside MiCA’s scope. Scholars argue that in such scenarios, where no single party can unilaterally act without user consent, shared control does not constitute “control” under Article 3(1)(17). However, the applicability of MiCA ultimately depends on the specific technical and operational setup of the MPC solution, necessitating a case-by-case analysis.
1.6.2 United States (SEC)
The U.S. Securities and Exchange Commission (SEC) has proposed new safeguarding rules addressing the custody of digital assets. These rules emphasize the role of qualified custodians in protecting assets, defining possession or control based on whether the custodian’s involvement is required to effect changes in beneficial ownership. If a custodian generates and maintains private keys in a way that prevents an adviser from altering ownership without their participation, they are deemed to have possession or control.
While MPC is not explicitly addressed in the proposed amendments, its utility in enhancing asset protection through distributed key management is acknowledged by legal practitioners analyzing the SEC’s custody rules. The use of multiple keys, held by separate parties to authorize transactions, aligns with these protective measures.
1.6.3 Singapore (MAS)
Singapore’s Payment Services Act includes provisions acknowledging distributed cryptographic solutions in the safeguarding of digital tokens, as outlined in Guideline PS-G01. Under this framework, digital payment token service providers are required to implement segregated cryptographic key components for custodial wallets, ensuring that no individual or system has access to a complete key.
MPC has drawn the attention of the Monetary Authority of Singapore (MAS), which specifies in Customer Protection Guidelines that key shares used in MPC setups must be distributed among multiple parties. No single party should be capable of authorizing or executing transactions independently. However, non-custodial applications of MPC have not yet been explicitly analyzed under this regulatory framework.
1.6.4 Hong Kong (SFC)
The Hong Kong Securities and Futures Commission (SFC) emphasizes private key security and due diligence in custody solutions in its Guidelines for Virtual Asset Trading Platform Operators. Platform operators must implement robust controls to ensure secure generation, storage, and backup of cryptographic seeds and private keys within Hong Kong.
The SFC has commented on technological advancements such as MPC and key sharding, noting the importance of adhering to industry standards and obtaining appropriate certifications, such as those involving Hardware Security Modules. While the authority signals possible allowance for third-party custody solutions, their adoption is contingent upon meeting established certification and standardization benchmarks.
1.6.5 Dubai (VARA)
Under the Dubai's Virtual Asset Regulatory Authority (VARA) framework, the Custody Rulebook mandates secure key generation and storage practices aligned with industry best practices. MPC providers can meet these requirements if deemed Virtual Asset Service Providers (VASPs) offering custody services. This entails safekeeping assets and acting only on verified instructions from or on behalf of the client.
In scenarios where MPC providers share co-signing authority with clients, their role may qualify as custodial under VARA regulations. However, the framework lacks clarity on the extent and verification of instructions. Custodians must assess risks tied to key generation and usage, including whether signatories should participate in key creation or be restricted from cryptographically signing transactions.
While MPC technologies clearly enhance security and align with emerging legal standards, their treatment under global frameworks remains fragmented and context-dependent.
2. The MPC Provider Framework
2.1 Background: Understanding the Risks
This section provides a theoretical framework for evaluating providers of Operational Access Control Management tools, with a focus on MPC. Given the relative novelty of MPC in this space, we introduce a structured approach to assess MPC providers, enabling users to evaluate their suitability based on specific operational and security needs.
DeFi applications or protocols typically aim to reduce reliance on centralized providers by employing automated smart contracts to minimize enforcement delays and eliminate trusted counterparties. However, the degree to which DeFi applications are automatable varies significantly, necessitating careful evaluation of which parts of the transaction value chain require trusted signatures and how these are implemented.
Low trust assumption protocol:
Singleton smart contracts or chains of smart contracts operate autonomously without external input, requiring no trusted signatures. For instance, the WETH contract is just about the lowest trust protocol.Trust assumptions on key inputs:
Protocols depend on external inputs, such as price feeds, which create dependencies for signed transactions to submit prices.Trust assumptions on gating access to user funds:
Protocols include mechanisms to freeze or slow access to user funds, acting as a fail-safe during failures in other parts of the protocol (may introduce a notion of 'custody').Broad dependence on trusted signatures:
Protocol execution relies extensively on trusted signatures to function as designed (may introduce a notion of 'control').
The possibility of financial loss in DeFi can be isolated into the following categories of risk:
The key source of risk in the context of DeFi custody or applications lies in the transaction value chain rather than the infrastructure used to secure trusted interactions. Operational access control mechanisms such as signature-based systems modulate risk at the margin but do not eliminate the inherent trust assumptions that amplify these risks.
To help users assess different providers, a risk framework categorizes key elements of operational access management into: Deployment Model, Key Management, Operational Security, Compliance and Regulation, Auditability, Transparency, and Operational Resilience. These dimensions help reduce the likelihood of financial loss and can be evaluated relative to customer needs, such as the contrasting requirements of a decentralized crypto protocol versus a regulated asset manager.
2.2 Metrics and Attributes
After identifying broad categories of financial risk, we introduce a structured set of metrics and attributes to evaluate MPC providers. These metrics are organized into Relational and Feature components. Relational components describe fundamental trust and operational models, while Feature components focus on specific technical, security, compliance, and transparency measures. This framework helps users assess providers based on their operational requirements, risk tolerance, and governance preferences.
2.2.1 Relational Components
2.2.1.1 Deployment Model
The deployment model clarifies how and where the MPC solution is hosted. It shapes the client’s data governance, operational autonomy, and trust assumptions.
2.2.1.2 Key Management Relationship
Key management relationship defines who controls cryptographic keys and how that affects trust, security, and operational complexity.
2.2.2 Feature Components
2.2.2.1 Key Management
Key management features focus on the technical measures used to secure cryptographic keys, ensuring their integrity, availability, and resilience against compromise.
2.2.2.2 Operational Security
Operational Security metrics assess the provider’s adherence to security standards, incident preparedness, and vulnerability management practices.
2.2.2.3 Operational Resilience
Operational resilience addresses the provider’s ability to maintain service continuity, recover from disruptions, and mitigate operational failures.
2.2.2.4 Compliance and Regulation
Compliance and regulation metrics ensure that the provider operates within relevant legal frameworks, reduces regulatory risk, and upholds data protection standards.
2.2.2.5 Auditability
Auditability metrics look at whether the provider maintains actionable audit trails, undergoes independent reviews, and shares these findings, enabling clients to independently verify claims.
2.2.2.6 Transparency
Transparency evaluates how openly the provider discloses information about their operations, security measures, and governance, enabling stakeholders to make informed decisions.
3. MPC Providers: Comparative Analysis
This section presents a comparative analysis of four MPC providers—Fireblocks, BitGo, Ceffu, and Cobo—through a detailed risk framework.
Please refer for sources of this work to this supplementary research spreadsheet.
3.1 Evaluation
3.1.1 Deployment Model
Fireblocks and Cobo offer the most flexibility, supporting provider-hosted, on-premises, and hybrid setups. BitGo supports provider-hosted and hybrid options, while Ceffu is primarily provider-hosted. Organizations needing strict data sovereignty or tailored infrastructures may find Fireblocks and Cobo most appealing, while BitGo and Ceffu offer simpler, more standardized environments.
3.1.2 Key Management (Relationship)
Fireblocks stands out by enabling self-custodial arrangements, granting clients maximum control over their keys. BitGo, Ceffu, and Cobo generally leverage custodial or shared custody models. Shared custody is universal, providing a balanced approach that combines the convenience of provider management with client oversight. Organizations that value absolute key ownership may favor Fireblocks, while those comfortable with managed solutions might lean toward the others.
3.1.3 Key Management (Features)
(*BitGo’s HSM usage is confirmed for multisig; MPC usage within HSMs is less explicitly documented but implied.)
All four providers utilize MPC and key fragmentation, enhancing security by eliminating single points of compromise. Recovery mechanisms are standard, ensuring business continuity in case of lost credentials. Hardware Security Modules (HSMs) are integrated to strengthen key protection. Fireblocks, BitGo, and Ceffu support robust key rotation policies, while Cobo’s stance is less clear. Fireblocks, BitGo, and Cobo openly disclose or reference their cryptographic protocols, providing transparency into their cryptographic underpinnings. Ceffu offers strong MPC security but is less forthcoming about the specific protocols used.
3.1.4 Operational Security
(*"True" indicates that while not publicly detailed, SOC/ISO compliance and industry practices strongly imply the existence of incident response procedures.)
All providers align with recognized security standards, conduct regular audits, and perform penetration testing. Fireblocks, BitGo, and Cobo actively run bug bounty programs, encouraging external vulnerability disclosures. While Ceffu meets high-level security benchmarks, the absence of a bug bounty program is a minor drawback for organizations seeking maximum external scrutiny.
3.1.5 Operational Resilience
(*"True" indicates that while not publicly detailed, SOC/ISO compliance and industry practices strongly imply the existence of incident response procedures.)
All providers implement disaster recovery and redundancy measures. BitGo leads in documented uptime SLAs with 99.95%, followed by Fireblocks at 99.9%. Neither Ceffu nor Cobo publicly discloses specific SLAs. Insurance coverage is explicitly available through BitGo, Ceffu, and Cobo, but Fireblocks’ current status remains unclear. Clients prioritizing formal service-level commitments and confirmed insurance may find BitGo and Ceffu’s offerings especially reassuring.
3.1.6 Compliance and Regulation
All four providers maintain robust compliance and regulatory postures, adhering to KYC/AML rules, demonstrating adaptability across jurisdictions, and engaging actively with regulatory authorities. Their strong compliance frameworks make them attractive to regulated institutions and global entities seeking legally conforming custody solutions.
3.1.7 Auditability
All providers offer audit logs for tracking activities, but none publicly disclose full third-party audit results. Fireblocks and BitGo go a step further by providing internal audit reports, giving clients some insight into their security posture. Ceffu and Cobo’s lack of client-accessible internal audit reporting may limit transparency for those who prioritize external verification.
3.1.8 Transparency
Fireblocks and BitGo openly share code or cryptographic details, building trust in their technology stacks. While public audit report disclosure is absent across the board, BitGo and Cobo enable through offering Multisig Wallets next to MPC the ability to allow operational transparency of clients onchain. Fireblocks and Ceffu lag the ability in on-chain transparency measures, which may matter to stakeholders seeking verifiable, public attestations of transaction validity.
3.2 Summary of Analysis
All four major MPC providers—Fireblocks, BitGo, Ceffu, and Cobo—demonstrate robust security architectures, regulatory compliance, operational resilience, and reliable key management features. Key differences emerge in deployment flexibility, custody models, and the degree of transparency:
Fireblocks excels in flexible deployments and self-custodial models, granting clients maximum autonomy over keys. It’s also open-source friendly regarding cryptographic algorithms.
BitGo leads with top-tier uptime guarantees, multi-signature support, internal audit reporting, and robust transparency measures. This combination is attractive to clients who need both reliability and insight.
Ceffu emphasizes MPC-based security, insurance coverage, and compliance, but provides fewer assurances regarding bug bounties, on-chain transparency, or explicit uptime SLAs.
Cobo offers flexible deployment, shared custody MPC solutions, insurance coverage, and some on-chain transparency, positioning it well for varied institutional requirements.
Ultimately, the choice depends on each client’s risk profile, operational needs, and preferences for transparency and control. All providers meet a high-security baseline, allowing organizations to choose the solution best aligned with their unique priorities. -
4. Protocol Security Recommendations
The security of decentralized protocols hinges on adopting robust operational access control mechanisms that align with the unique needs of each system.
4.1 Balancing Transparency and Security
MPC wallets offer cryptographic security, but their design often complicates transparency as the on-chain footprint is removed. Regular audits and certifications by trusted third parties, as exemplified by Fireblocks' annual SOC 2 Type II reports, should be a cornerstone of any MPC provider. These validations provide external assurance that the cryptographic protocols are both secure and reliable.
Open-source initiatives further enhance transparency while maintaining confidentiality. For instance, making MPC libraries publicly auditable, like Fireblocks-MPC, allows the broader cryptographic community to validate and contribute to the wallet's underlying mechanisms. Collaborative efforts to establish standardized practices for MPC wallets, such as those championed by the MPC Alliance, can also foster industry-wide trust and interoperability.
4.2 Auditability of MPC Systems
As we have shown in the report, auditability of MPC system is somewhat limited. For system architecture our best bet for the foreseeable future will be external audits. Yet, exciting research exists on auditing specific set up for a MPC wallet allowing for transparency in signing operation, number key shards and thresholds replicating the transparency of traditional multisig wallets. For instance research on auditable MPC-as-a-Service, such as suggested by Kanjalkar et al. (2021), introduces mechanisms to replicate the functionality of public auditablity.
Source: Kanjalkar et al. (2021)
Each participant (e.g., signers in the MPC wallet) commits to their inputs by generating cryptographic commitments, Com(x₁), Com(x₂), Com(x₃).These commitments are posted to a bulletin board, ensuring a public and immutable record of all inputs. he participants privately submit their actual inputs (x₁, x₂, x₃) to the MPC network, ensuring confidentiality during computation. A query is submitted to define the operation to be performed. For example, in the context of updating DeFi protocol parameters, this could be a function f₁ that adjusts the borrow cap or liquidation ratio based on current market conditions. The commitments (Com(x₁), Com(x₂), Com(x₃)) and the query (f₁) are fetched by the MPC system to validate that the commitments match the submitted inputs. The MPC network computes the result of the query (e.g., updated protocol parameters), producing yₖ, the output of f₁. The MPC system also generates a proof (π₁) to demonstrate the correctness of the computation. These results (yₖ, Com(yₖ), and π₁) are posted back to the bulletin board. Anyone (e.g., the protocol or a third-party auditor) can fetch the commitments, results, and proofs from the bulletin board and audit them to verify correctness. The audit process checks that:
The inputs match their commitments.
The computation followed the specified function
f₁.The proof
π₁confirms that the outputyₖis correct.
We encourage the adoption such system functionality by providers to make MPC more transparent. There is evidence such system may be already available. Fireblocks developer documentation suggests that audit logs for clients are already available - given we do not have access to the actual endpoint we were unable to verify what information can be retrieved. It may be the matter of protocols posting log to the blockchain or hosting them on frontend to increase auditability and transparency.
4.3 Remaining Role of Multisig
Until then, for protocols that place a premium on public accountability—such as those managing community treasuries or critical smart contract functions—the inherent on-chain transparency of multisig wallets may remain more aligned with their operational objectives. In these contexts, multisig solutions can still be the preferred choice, as they provide verifiable, protocol-level governance checks that MPC-based approaches currently struggle to match.
5. Conclusion: Navigating Trade-Offs
Choosing an optimal wallet infrastructure involves balancing transparency, security, and operational efficiency. Multi-Party Computation (MPC) wallets have demonstrated remarkable cryptographic strength and scalability, making them especially attractive for high-frequency or large-scale operations. At the same time, their reliance on distributed cryptographic processes can make transparency and on-chain verifiability more challenging.
Moving forward, the ecosystem’s stakeholders must collaborate to define and adopt best practices. This involves:
Researchers pushing the frontiers of auditable MPC frameworks, integrating verifiability while preserving confidentiality.
Operators implementing meaningful transparency measures—ranging from documented audits to publicly verifiable proofs—to foster user trust.
Protocol Designers rigorously evaluating their operational priorities and requirements, selecting MPC-based infrastructures that align with their strategic objectives for security, scalability, and user confidence.