# MPCs in a Protocol Treasury and Operational Context: Trust, Don't Verify!

*This research is a joint initiative between [LlamaRisk](https://www.llamarisk.com/) and [Steakhouse Financial](https://www.steakhouse.financial/).*

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

### What is a MPC wallets?

#### Public Key Cryptography

One of the core concepts that is typical for managing user interactions in blockchain systems is [**public key cryptography**](https://en.wikipedia.org/wiki/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:
1. The *private key* signs transactions to confirm authenticity and ownership.
2. The *public key* allows anyone to verify the validity of the signed transaction without revealing the private key.

graph LR
    A[Private Key Holder] -->|Generates| B[Signature]
    B -->|Authorizes| C[Transaction]

In conventional Single-Signature Wallets (a.k.a. Externally Owned Acounts, 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.

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

graph LR
    A[Cosigner 1] 
    A2[Cosigner 2]
    A3[Cosigner 3]
    A4[Cosigner 4]
    A5[Cosigner 5]
    B1[Individual Signature]
    B2[Individual Signature]
    B3[Individual Signature]
    C[Transaction]
    
    A -->|Generates| B1
    A2 -->|Generates| B2
    A3 -->|Generates| B3
    A4 -. No action .-> C
    A5 -. No action .-> C
    B1 -->|Authorizes| C
    B2 -->|Authorizes| C
    B3 -->|Authorizes| C

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.

#### MPC Wallet
MPC wallets rely on [Multi-Party Computation (MPC)](https://en.wikipedia.org/wiki/Secure_multi-party_computation), 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.

graph LR
    A[Party 1]
    A2[Party 2]
    A3[Party 3]
    B1[Private Share]
    B2[Private Share]
    B3[Private Share]
    C[Signature]
    D[Transaction]

    A -->|Holds| B1
    A2 -->|Holds| B2
    A3 -->|Holds| B3
    B1 -->|Combines| C
    B2 -->|Combines| C
    B3 -->|Combines| C
    C -->|Authorizes| D

While various MPC wallets rely on different cryptographic methods, common foundational protocols include - [Shamir's Secret Sharing (SSS)](https://en.wikipedia.org/wiki/Shamir%27s_secret_sharing), a technique for splitting a secret into multiple shares; [Yao's Garbled Circuit](https://en.wikipedia.org/wiki/Garbled_circuit) used for more general-purpose secure computations; and [Fully Homomorphic Encryption (FHE)](https://en.wikipedia.org/wiki/Homomorphic_encryption) 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.

#### Threshold Signature Schemes (TSS) in MPC Wallets
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) = a_0 + a_1x + \dots + a_{t-1}x^{t-1}$, where $a_0 = S$ is the secret. Each participant holds one share, $f(1), f(2), \dots, f(n)$. To generate a valid signature, a subset of participants meeting the predefined threshold $t$ combines their shares using techniques like [Lagrange interpolation](https://en.wikipedia.org/wiki/Lagrange_polynomial#Remainder_in_Lagrange_interpolation_formula), 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.

##### Adding and removing key share
To add a new signer in a threshold signature scheme (TSS), the system initiates a recomputation process. The original secret $S$ remains unchanged, but a new polynomial $f'(x)$ is generated to create fresh key shares. Each participant, including the new signer, receives a new share derived by evaluating $f'(x)$ at distinct points $( f'(1), f'(2), f'(3), \dots)$. The old shares are invalidated, and the updated shares are distributed securely to all parties. This process ensures that the secret is never exposed or reconstructed while maintaining the same threshold $t$, allowing the system to dynamically adapt to new participants without compromising security.

graph LR
    %% Initial Shares
    subgraph Initial_Shares[Key Shares prior recompute]
        Party1[Party 1] --> Key1[Key Share 1]
        Party2[Party 2] --> Key2[Key Share 2]
    end

    subgraph recompute[Recompuation Process]
    %% Arrows connecting phases
    Key1 --> Recompute
    Key2 --> Recompute

    end
    
    subgraph New_Shares[Key Shares past recompute]
        Recompute --> NewKey1
        Recompute --> NewKey2
        Recompute --> NewKey3
        NewKey1[New Key Share 1] --> Party1_new[Party 1]
        NewKey2[New Key Share 2] --> Party2_new[Party 2]
        NewKey3[New Key Share 3] --> Party3_new[Party 3]
    end

##### Changing signing threshold
To change the threshold $t$ in a threshold signature scheme (TSS) without altering the signing parties, a recomputation process is initiated. The original secret $S$ remains unchanged, but a new polynomial $f'(x)$ with an updated degree reflecting the new threshold is generated. New key shares $f'(1), f'(2), f'(3), \dots$ are computed and securely distributed to the same set of participants, while the old shares are invalidated. For example, increasing $t$ from 2 to 3 requires a new polynomial of degree 2, ensuring that all three shares are now needed to reconstruct the secret and authorize transactions. This process enhances security by requiring more parties for signing, without exposing the private key or altering the participant set.

graph LR
    %% Initial Shares
    subgraph Initial_Shares[Key Shares Prior to Recompute]
        Party1[Party 1] --> Key1[Key Share 1]
        Party2[Party 2] --> Key2[Key Share 2]
        Party3[Party 3] -. Optional .-> Key3[Key Share 3]
    end

    subgraph recompute[Recompute Process]
        Key1 --> Recompute
        Key2 --> Recompute
        Key3 --> Recompute
    end
    
    subgraph New_Shares[Key Shares After Recompute]
        Recompute --> NewKey1[New Key Share 1]
        Recompute --> NewKey2[New Key Share 2]
        Recompute --> NewKey3[New Key Share 3]
        NewKey1 --> Party1_new[Party 1]
        NewKey2 --> Party2_new[Party 2]
        NewKey3 --Required--> Party3_new[Party 3]
    end

### MPC Wallet 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.

graph LR
    subgraph "MPC Wallet Transaction Flow"
    A[User Initiates Transaction] -->|Request to Server| B[Generate Encrypted Random Number]
    B -->|Deliver to User| C[User Decrypts and Signs]
    C --> D[Return Signature to Server]
    D --> E[Combine Signatures]
    E -- "If All Shares Valid" --> F[Authorize Transaction]
    E -- "If Any Invalid" --> G[Reject Transaction]
    F --> H[Broadcast Transaction]
    end

### MPC Wallet 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](https://aws.amazon.com/blogs/database/build-secure-multi-party-computation-mpc-wallets-using-aws-nitro-enclaves/).

graph TD
    %% Key Shard Generation
    subgraph Key_Shard_Generation["Key Shard Generation"]
        DKG["Distributed Key Generation (DKG)"] --> Shard1["Key Shard 1"]
        DKG --> Shard2["Key Shard 2"]
        DKG --> Shard3["Key Shard 3"]
    end
    
    %% Enclaves
    subgraph Cosigners["Cosigner Architecture"]
        subgraph Enclave1["Cosigner 1 (Secure Enclave)"]
            Shard1 --> Enclave1Processing["Secure Signing Operations"]
            Enclave1Processing --> Message1["MPC Message (Signed)"]
        end
        subgraph Enclave2["Cosigner 2 (Secure Enclave)"]
            Shard2 --> Enclave2Processing["Secure Signing Operations"]
            Enclave2Processing --> Message2["MPC Message (Signed)"]
        end
        subgraph Enclave3["Cosigner 3 (Secure Enclave)"]
            Shard3 --> Enclave3Processing["Secure Signing Operations"]
            Enclave3Processing --> Message3["MPC Message (Signed)"]
        end
    end
    
    %% Communication Layer
    subgraph Communication["Communication and Validation"]
        Message1 --> Broker["Message Broker (e.g., Message Queue/Stream)"]
        Message2 --> Broker
        Message3 --> Broker
        Broker --> Verification["Zero-Trust Validation"]
    end
    
    %% Transaction Signing
    subgraph Transaction_Signing["Transaction Signing"]
        Verification --> Combine["Combine MPC Messages"]
        Combine --> ValidSignature["Valid Blockchain Signature"]
        ValidSignature --> Blockchain["Blockchain Transaction"]
    end

<!--
NOTE: INSERT BACK INTO CHART IF NEEDED
%% Data Storage
subgraph Data_Persistence["Data Persistence"]
Storage["Encrypted Persistent Storage"]EncryptedDB["Encrypted Database (In-Memory)"]
EncryptedDB -.-> Enclave1Processing
EncryptedDB -.-> Enclave2Processing
EncryptedDB -.-> Enclave3Processing
end -->

In general, a MPC wallet architecture utilises [Distributed Key Generation (DKG)](https://en.wikipedia.org/wiki/Distributed_key_generation). 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 to be a hold a [key shard in a MPC TSS wallet](https://developers.bitgo.com/guides/wallets/overview).

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.

<!-- The architecture also incorporates robust mechanisms for securely storing key shards and transient cryptographic data. *Persistent storage*, such as encrypted cloud-based or local systems, ensures that key shards remain available even in the event of a system restart or failure. *In-memory storage* is used for temporary data during operations, providing faster access while minimizing long-term risk. Encryption tightly binds the stored data to the secure environment, ensuring it can only be accessed by the processing unit that created it. -->

### Risks and vulnerabilities of MPC architecture

#### Structural or mathematical risks

##### Theoretical Exploits in Threshold Signature Schemes (TSS)
A significant theoretical exploit in the context of MPC wallets is the [TSS Shock Attack](https://verichains.io/tsshock/), 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.

#### Operational and idiosyncratic risks

##### Elliptic curve operational handling
In the [BitForge vunerablity](https://www.fireblocks.com/blog/bitforge-fireblocks-researchers-uncover-vulnerabilities-in-over-15-major-wallet-providers/) 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 a beyond the scope of this article but it documented in this research piece by [Makriyannis et al., 2024](https://eprint.iacr.org/2023/1234.pdf#page=22.23).

##### Key man risk and concentration risk
The Multichain hack, resulting in over [$130 million in losses](https://rekt.news/multichain-r3kt/), illustrates how poor operational practices within an MPC setup can override even sophisticated cryptographic safeguards. [According to the Mutlichain Team](https://twitter.com/MultichainOrg/status/1679768407628185600), 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.

### Transparency in MPC Wallets
As seen in the [System Architecture of the MPC Wallet](https://hackmd.io/klogPq_eTPueK2jQ4Eg0SQ#MPC-Wallet-System-Architecture) - 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.

| Single-Signature Wallet (EOA) | Multi-Signature Wallet | Multi-Party Computation Wallet |
| -------- | -------- | -------- |
|  |  |  |
| [Source](https://etherscan.io/tx/0xd467843e9b31ff406bddca2612554fc3db7c1f3d71ad2b42626d501d3717e069) | [Source](https://etherscan.io/tx/0x5e4737a22c250f25609061ae1dc195ae42a18d91c647af2d7410a50e46581580) | [Source](https://etherscan.io/tx/0xfcdaa92f37af876f863c962f9d2d3251d726ccd98f0a4e9e464849bc51291119) |

To date there are limited transparency practices available to audit MPC systems offered by providers. Transparency practices can summarised by open-source cryptograhic libaries 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 vunerablities 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](https://secureframe.com/hub/soc-2/soc-1-vs-soc-2-vs-soc-3) 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 certficiation include:

- [ISO/IEC 27001](https://www.iso.org/standard/27001): Focuses on the establishment, implementation, and maintenance of an Information Security Management System (ISMS)
- [ISO/IEC 27017](https://www.iso.org/standard/82878.html): Provides guidelines for enhancing information security in cloud services
- [ISO/IEC 27018](https://www.iso.org/standard/76559.html): 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.

### The regulatory landscape for MPC wallets

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.

#### 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](https://academic.oup.com/cmlj/article/19/3/207/7692861) 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.

#### 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](https://www.californialawreview.org/print/applying-the-sec-custody-rule-to-cryptocurrency-hedge-fund-managers) analyzing the SEC’s custody rules. The use of multiple keys, held by separate parties to authorize transactions, aligns with these protective measures.

#### MAS

Singapore’s Payment Services Act includes provisions acknowledging distributed cryptographic solutions in the safeguarding of digital tokens, as outlined in [Guideline PS-G01](https://www.mas.gov.sg/regulation/guidelines/ps-g01-guidelines-on-licensing-for-payment-service-providers). 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), who specify in [Customer Protection Guidelines](https://www.mas.gov.sg/regulation/guidelines/ps-g03-guidelines-on-consumer-protection-measures-by-dpt-service-providers) 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.

#### 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](https://www.sfc.hk/-/media/EN/assets/components/codes/files-current/web/guidelines/Guidelines-for-Virtual-Asset-Trading-Platform-Operators/Guidelines-for-Virtual-Asset-Trading-Platform-Operators.pdf). 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](https://apps.sfc.hk/edistributionWeb/api/consultation/conclusion?lang=EN&refNo=23CP1) 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.

#### VARA

Under the Dubai's Virtual Asset Regulatory Authority (VARA) framework, the [Custody Rulebook](https://rulebooks.vara.ae/rulebook/general-requirements-0) 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.

## Assessing Operational Access Control Management: A Framework for MPCs
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.

### Background: Understanding Risk in Operational Access Control Management Providers
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.

1. **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](https://etherscan.io/address/0xc02aaa39b223fe8d0a0e5c4f27ead9083c756cc2) contract is just about the lowest trust protocol.
2. **Trust assumptions on key inputs**:
Protocols depend on external inputs, such as price feeds, which create dependencies for signed transactions to submit prices.
3. **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').
4. **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:

| **Source of Risk** | **How Financial Loss Materializes** |
|-----------------------|-------------------------------------------------------------|
| **Counterparty** | A provider defaults on its obligations or fails to perform a service. |
| **Regulatory** | Changes in laws or non-compliance expose providers to operational failure modes or asset sequestration. |
| **Operational** | Inadequate processes lead to errors, resulting in financial losses or incorrectly executed transactions. |
| **Security** | Breaches or cyberattacks exploit vulnerabilities in the provider’s architecture. |
| **Legal** | Lack of legal protections or exposure to enforcement actions. |
| **Reputational** | Loss of trust due to perceived unreliability or compromised systems. |
| **Technology** | Failures, obsolescence, or bugs cause incorrect transaction processing or exploitable vulnerabilities. |

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.

| **Financial Risk** | **Deployment Model** | **Key Management** | **Operational Security** | **Compliance & Regulation** | **Auditability** | **Transparency** | **Operational Resilience** |
|------------------------|----------------------|--------------------|---------------------------|-----------------------------|------------------|------------------|---------------------------|
| **Counterparty Risk** | ✓ | ✓ | | | | ✓ | ✓ |
| **Regulatory Risk** | | ✓ | | ✓ | | | |
| **Operational Risk** | ✓ | ✓ | ✓ | | | | ✓ |
| **Security Risk** | | ✓ | ✓ | | ✓ | | |
| **Legal Risk** | ✓ | ✓ | | ✓ | | | |
| **Reputational Risk** | | | ✓ | | ✓ | ✓ | |
| **Technology Risk** | ✓ | | ✓ | | | | ✓ |

## **The MPC Provider Framework**

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.

### Relational Components

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

| Component | Category | Sub-Category | Definition | Value |
|------------|-------------------|---------------------------|---------------------------------------------------------------------------------------------------------------------------------------------|-----------|
| Relational | Deployment Model | Provider-hosted Infrastructure | The solution is fully hosted and managed by the service provider in their environment, offering a turnkey, scalable, and low-maintenance option for clients. | True/False |
| Relational | Deployment Model | Self-hosted Infrastructure | The client hosts and manages the solution on their own infrastructure (e.g., on-premises or private cloud), granting full control over security, compliance, and customization. | True/False |
| Relational | Deployment Model | Hybrid Deployment | The solution splits between provider-hosted and self-hosted environments, balancing scalability and convenience with greater client control and compliance measures. | True/False |

#### Key Management Relationship

Key management relationship defines who controls cryptographic keys and how that affects trust, security, and operational complexity.

| Component | Category | Sub-Category | Definition | Value |
|------------|----------------------------|-----------------|---------------------------------------------------------------------------------------------------------------------------------------------|-----------|
| Relational | Key Management Relationship | Custodial | Provider has full control over the client’s cryptographic keys, simplifying management but increasing reliance on provider security. | True/False |
| Relational | Key Management Relationship | Shared Custody | Keys are divided between provider and client, requiring both parties’ involvement to authorize transactions. | True/False |
| Relational | Key Management Relationship | Self-Custodial | Clients retain exclusive control of their keys, enhancing security autonomy but adding complexity and responsibility for key management. | True/False |

### Feature Components

#### Key Management

Key management features focus on the technical measures used to secure cryptographic keys, ensuring their integrity, availability, and resilience against compromise.

| Component | Category | Sub-Category | Definition | Value |
|-----------|----------------|-------------------------|-------------------------------------------------------------------------------------------------|------------------------------|
| Feature | Key Management | Recovery Mechanism | Provider offers methods to recover lost keys or credentials, reducing the risk of permanent loss. | Yes/No (Specify if Yes) |
| Feature | Key Management | Key Fragmentation | Private keys are split into fragments (shards) and distributed, reducing risk of single-point compromise. | True/False |
| Feature | Key Management | HSM Integration | Uses Hardware Security Modules to securely generate and store keys, providing tamper-resistant protection. | True/False |
| Feature | Key Management | TSS Support | Employs Threshold Signature Schemes that require multiple key shares to sign a transaction. | True/False |
| Feature | Key Management | Key Rotation Policies | Supports regular updating of cryptographic keys to reduce exposure over time. | True/False |
| Feature | Key Management | Cryptographic Protocols Used | Indicates which cryptographic algorithms and protocols are employed to assess security strength. | True/False |

#### Operational Security

Operational Security metrics assess the provider’s adherence to security standards, incident preparedness, and vulnerability management practices.

| Component | Category | Sub-Category | Definition | Value |
|-----------|----------------------|----------------------------------|-----------------------------------------------------------------------------|-----------------|
| Feature | Operational Security | Security Standards | Provider adheres to recognized security certifications (e.g., ISO 27001). | List certifications |
| Feature | Operational Security | Incident Response Plan | Documented procedures for handling and mitigating security incidents. | True/False (Specify if Yes) |
| Feature | Operational Security | Security Audits and Penetration Testing | Regularly conducts tests to identify and address vulnerabilities proactively. | True/False |
| Feature | Operational Security | Bug Bounty Program | Encourages external researchers to report vulnerabilities for continuous improvement. | True/False |

#### Operational Resilience

Operational resilience addresses the provider’s ability to maintain service continuity, recover from disruptions, and mitigate operational failures.

| Component | Category | Sub-Category | Definition | Value |
|-----------|----------------------|------------------------|--------------------------------------------------------------------|-----------------------------|
| Feature | Operational Resilience | Disaster Recovery Plan | Has strategies to restore operations following major disruptions. | True/False |
| Feature | Operational Resilience | Uptime Guarantees (SLAs) | Specifies minimum service availability and reliability commitments. | Specify percentage/True/False |
| Feature | Operational Resilience | Redundancy Measures | Implements redundancy to avoid single points of failure. | True/False |
| Feature | Operational Resilience | Insurance Coverage | Provides insurance against losses from theft, fraud, or system failures. | True/False |

#### Compliance and Regulation

Compliance and regulation metrics ensure that the provider operates within relevant legal frameworks, reduces regulatory risk, and upholds data protection standards.

| Component | Category | Sub-Category | Definition | Value |
|-----------|-----------------------|---------------------------|-----------------------------------------------------------------------------|-----------------------------------|
| Feature | Compliance and Regulation | KYC/AML Compliance | Implements Know Your Customer and Anti-Money Laundering measures to prevent illicit activities. | True/False |
| Feature | Compliance and Regulation | Jurisdictional Adaptability | Can comply with different regional regulations, reducing legal friction. | True/False |
| Feature | Compliance and Regulation | Regulatory Status | Indicates alignment with relevant regulatory authorities. | Compliant/Non-Compliant/Unknown |
| Feature | Compliance and Regulation | Data Protection Compliance | Adheres to data protection laws like GDPR or CCPA. | True/False |
| Feature | Compliance and Regulation | Regulatory Engagement | Actively participates in regulatory discussions and industry standard setting. | True/False |

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

| Component | Category | Sub-Category | Definition | Value |
|-----------|--------------|------------------------|------------------------------------------------------------------|------------|
| Feature | Auditability | Audit Logs Available | Maintains logs of all activities for accountability and traceability. | True/False |
| Feature | Auditability | Audits | Undergoes independent third-party audits to validate security measures. | True/False |
| Feature | Auditability | Internal Audit Reports | Conducts internal audits and shares relevant findings with clients. | True/False |

#### Transparency

Transparency evaluates how openly the provider discloses information about their operations, security measures, and governance, enabling stakeholders to make informed decisions.

| Component | Category | Sub-Category | Definition | Value |
|-----------|---------------|--------------------------------|------------------------------------------------------------------------------------|------------|
| Feature | Transparency | Open-Source Code or Publicly Named Algorithms | Discloses software code or cryptographic algorithms used, fostering trust through openness. | True/False |
| Feature | Transparency | Audit Report Disclosure | Makes audit results publicly available, improving accountability. | True/False |
| Feature | Transparency | Transparency Practices | Implements measures like on-chain logs to allow third-party verification of transactions. | Specify practices |

### Overview of Operational Access Control Management Providers: Classification

This section presents a comparative analysis of four MPC providers—Fireblocks, BitGo, Ceffu, and Cobo—through a detailed risk framework.

| **Logo** | **Company** | **Founded** | **Description** | **Headquarters** | **Company Size** | **Target Clients** |
|-----------------|----------------|-------------|----------------------------------------------------------------------------------------------------------------------------------|-----------------------|------------------|----------------------------------------------------------------------------------------------------------|
|  | **[Fireblocks](https://www.fireblocks.com/)** | 2018 | A leading digital asset security platform utilizing advanced MPC and chip isolation technology to protect private keys and API credentials. | New York, USA | 501-1000 | Exchanges, banks, PSPs, lending desks, custodians, trading desks, hedge funds. |
|  | **[BitGo](https://www.bitgo.com/)** | 2013 | Provides secure and scalable solutions for the digital asset economy, including custody, borrowing/lending services, and blockchain infrastructure. | Palo Alto, USA | 201-500 | Institutional clients, including asset managers, exchanges, and other financial institutions. |
|  | **[Ceffu](https://www.ceffu.com/)** | 2021 | Offers compliant and audited institutional-grade custody, asset management, and settlement solutions. | Singapore, Singapore & Warsaw, Poland | 11-50 | Financial services firms, institutional investors, crypto-native firms, Binance institutional users. |
|  | **[Cobo](https://www.cobo.com/)** | 2017 | A trusted custody and wallet infrastructure provider supporting 3,000+ tokens across 80+ chains. Achieved milestones such as PoS staking features and SOC 2 Type 2 certification. | Singapore, Singapore | 201-500 | Blockchain developers, organizations seeking scalable and secure digital asset solutions. |

Please refer for sources of this work to this [supplementary research spreadsheet](https://docs.google.com/spreadsheets/d/1dCAWuBGRSo9NfzJyYKYDQu8818zd68o-qzdcuwDh3p0/edit?usp=sharing).

<!-- - **Fireblocks:** A leading provider offering centralized and customizable solutions, leveraging MPC technology for secure, scalable deployment. Known for high compliance standards and key recovery tools.
- **BitGo:** Focused on institutional-grade security with strong custody options and regulatory adaptability. Offers multi-signature support and integration with third-party recovery tools.
- **Ceffu:** Combines MPC with distributed storage and air-gapped security for institutional clients. Strong emphasis on DeFi integration and compliance features.
- **Cobo:** A versatile provider offering custodial and co-managed custody solutions with robust disaster recovery measures and role-based compliance tools.
-->

### Deployment Model

| **Metric** | **Fireblocks** | **BitGo** | **Ceffu** | **Cobo** |
|---------------------------------|----------------|-----------|-----------|----------|
| **Provider-Hosted Infrastructure** | True | True | True | True |
| **Self-Hosted Infrastructure** | True | False | False | True |
| **Hybrid Deployment** | True | True | False | True |

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

### Key Management Relationship

| **Metric** | **Fireblocks** | **BitGo** | **Ceffu** | **Cobo** |
|-------------------|----------------|-----------|-----------|----------|
| **Custodial** | False | True | True | True |
| **Shared Custody** | True | True | True | True |
| **Self-Custodial** | True | False | False | False |

**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 towards the others.

### Key Management (Features)

| **Metric** | **Fireblocks** | **BitGo** | **Ceffu** | **Cobo** |
|------------------------|----------------|-----------|-----------|----------|
| **Recovery Mechanism** | Yes | Yes | Yes | Yes |
| **Key Fragmentation** | True | True | True | True |
| **HSM Integration** | True | True* | True | True |
| **TSS Support** | True | True | True | True |
| **Key Rotation Policies** | True | True | True | False |
| **Cryptographic Protocols Used** | True | True | False | True |

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

### Operational Security

| **Metric** | **Fireblocks** | **BitGo** | **Ceffu** | **Cobo** |
|----------------------------------------|----------------|-----------|-----------|----------|
| **Security Standards (ISO, SOC, etc.)** | Yes | Yes | Yes | Yes |
| **Incident Response Plan** | True* | True* | True* | True* |
| **Security Audits & Pen Testing** | True | True | True | True |
| **Bug Bounty Program** | True | True | False | True |

> (*"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.

### Operational Resilience

| **Metric** | **Fireblocks** | **BitGo** | **Ceffu** | **Cobo** |
|------------------------|----------------|-----------|-----------|----------|
| **Disaster Recovery Plan** | True* | True* | True* | True* |
| **Uptime Guarantees (SLAs)** | 99.9% | 99.95% | False | False |
| **Redundancy Measures** | True | True | True | True |
| **Insurance Coverage** | Unknown | True | True | True |
> (*"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.

### Compliance and Regulation

| **Metric** | **Fireblocks** | **BitGo** | **Ceffu** | **Cobo** |
|------------------------------|----------------|-----------|-----------|----------|
| **KYC/AML Compliance** | True | True | True | True |
| **Jurisdictional Adaptability** | True | True | True | True |
| **Regulatory Status** | Compliant | Compliant | Compliant | Compliant |
| **Data Protection Compliance** | True | True | True | True |
| **Regulatory Engagement** | True | True | True | True |

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.

### Auditability

| **Metric** | **Fireblocks** | **BitGo** | **Ceffu** | **Cobo** |
|------------------------|----------------|-----------|-----------|----------|
| **Audit Logs Available** | True | True | True | True |
| **Public Audits** | False | False | False | False |
| **Internal Audit Reports** | True | True | False | False |

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.

### Transparency

| **Metric** | **Fireblocks** | **BitGo** | **Ceffu** | **Cobo** |
|--------------------------------|----------------|-----------|-----------|----------|
| **Open-Source Code/Algorithms** | True | True | False | False |
| **Audit Report Disclosure** | False | False | False | False |
| **Transparency Practices** | False | False* | False | True* |

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.

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

<!-- ### Summary of Analysis
- [ ] Introduce weighting metrics
> *Note: Excluded metrics due to non-binary nature or lack of comparability include: cryptographic protocols (Security & Authorization), Cetification, public audits (Auditability), uptime percentages (Operational Resilience), and transparency practices (Transparency).*

The comparative analysis of MPC providers—Fireblocks, BitGo, Ceffu, and Cobo—highlights key differences and similarities across critical categories:

1. **Deployment Model**: Fireblocks and Cobo offer the most flexibility, supporting cloud-based, on-premises, and client-specific deployments. BitGo and Ceffu focus primarily on cloud-based solutions.
2. **Key Management**: Fireblocks excels in self-custodial options, whereas the others focus on custodial or shared custody models. Recovery mechanisms are robust across all providers.
3. **Security and Authorization**: All providers implement key fragmentation and distributed transaction signing. However, multi-signature support varies, with BitGo and Cobo offering strong support.
5. **Compliance and Regulation**: Providers demonstrate strong compliance across KYC/AML regulations and jurisdictional adaptability. Fireblocks' insurance coverage is unclear compared to the others.
6. **Auditability**: All providers maintain audit logs, but none disclose public audit results. Fireblocks and BitGo offer internal audit reports, adding transparency.
7. **Transparency**: Fireblocks and BitGo excel in disclosing cryptographic frameworks, while Cobo and BitGo provide strong transaction transparency practices.
8. **Operational Resilience**: Disaster recovery plans and redundancy measures are robust across all providers. BitGo offers the highest uptime guarantee at 99.95%. -->

<!-- 4. **Use Case Alignment**: All providers cater to institutional trading, treasury management, and DeFi integration, with Fireblocks and BitGo leading in high-frequency trading support. -->

## **Strengthening 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.

#### **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](https://www.fireblocks.com/blog/fireblocks-becomes-soc-2-type-ii-certified/), 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 libaries publically auditable, like [Fireblocks-MPC](https://github.com/fireblocks/mpc-lib/blob/main/README.md), 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](https://www.mpcalliance.org/), can also foster industry-wide trust and interoperability.

#### Open Issue: Auditability of MPC Systems
As we have shown in the report, auditability of MPC system is somewhat limited. For system architecure our best bet for the foreseeable future will be external audits. Yet, exciting research exist on auditing specific set up for a MPC wallet allowing for transaparency in signing operation, number key shards and thesholds replicating the transparency of traditional multisig wallets. For instance research on auditable MPC-as-a-Service, such as suggested by [Kanjalkar et al. (2021)](https://arxiv.org/pdf/2107.04248#page=0.97), introduces mechanisms to replicate the functionality of public auditablity.

**Source:** [Kanjalkar et al. (2021)](https://arxiv.org/pdf/2107.04248#page=0.97)

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:
1. The inputs match their commitments.
1. The computation followed the specified function `f₁`.
1. The proof `π₁` confirms that the output `yₖ` 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 suggest that [audit logs for clients are already available](https://developers.fireblocks.com/reference/getauditlogs) - given we do not have access to the acutal 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.

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

## **Conclusion: Navigating Trade-Offs and Charting the Future**

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.