Web3 Asset Management Solutions Comparison: Multisignature, MPC and CRVA

Written by: Shew, Xianrang

In the Web3 space, private key management is a matter of life and death. Once a wallet's private key is stolen or lost, millions of dollars in assets can vanish in an instant. However, the vast majority of people are accustomed to using single-point private key management, which is like putting all your eggs in one basket, making it possible to lose all assets to hackers at any moment due to clicking on a phishing link.

To address this issue, various solutions have emerged in the blockchain field. From multi-signature wallets to MPC, and then to the CRVA proposed by the DeepSafe project team, each technological advancement has paved new paths for asset management. This article will explore the principles, characteristics, and applicable scenarios of the three asset management solutions mentioned above, helping readers choose the path that best suits them.

Multi-signature wallet: Passable, but not excellent

The concept of a multi-signature wallet originates from a simple wisdom: do not concentrate all permissions in one place. This idea has long been widely applied in reality, such as in the separation of powers and board of directors voting.

Similarly, in Web3, a multi-signature wallet creates multiple independent keys to disperse risk. The most common is the “M-of-N” model, for instance, in a “2-of-3” setup, the system generates a total of three private keys, but only if any two of those private keys generate signatures can the designated account execute the transaction.

This design provides a certain level of fault tolerance— even if one private key is lost, the assets remain secure and controllable. If you have multiple independent devices for storing keys, a multi-signature scheme will be more reliable.

Generally speaking, multi-signature wallets can be technically divided into two categories. One type is the conventional multi-signature, which typically uses on-chain smart contracts or supporting components of the public chain to achieve functionality and often does not rely on specific cryptographic tools. The other type is a multi-signature wallet that relies on special cryptographic algorithms, where security depends on the specific algorithm, and sometimes can completely operate without the involvement of on-chain contracts. Below, we will discuss the two solutions separately.

Regular multi-signature scheme represents: Safe wallet and Bitcoin Taproot

Safe wallet, as one of the most popular multi-signature solutions available today, implements multi-signature through conventional Solidity smart contracts. In the architecture of the Safe wallet, each multi-signature participant controls an independent key, while the on-chain smart contract acts as an “arbitrator” and will only approve the multi-signature associated account to execute transactions when it collects a sufficient number of valid signatures.

The advantage of this method lies in transparency and verifiability, as all multi-signature rules are explicitly encoded in the smart contract, allowing anyone to audit the code logic. Additionally, users can add modules to the multi-signature account to provide richer functionalities, such as limiting the funding cap for each transaction. However, this transparency also means that the details of the multi-signature wallet are completely public on the blockchain, which may expose the user's asset management structure.

In addition to well-known multi-signature solutions like the Safe wallet within the Ethereum ecosystem, there are also multi-signature wallets built using BTC scripts within the Bitcoin network, such as solutions based on the OP_CHECKMULTISIG opcode. This opcode can verify whether the number of signatures included in the UTXO unlock script meets the requirements.

It is worth noting that the conventional multi-signature algorithms mentioned above all support “M-of-N”, but the multi-signature methods based on specific cryptographic algorithms introduced later only support the “M-of-M” mode, meaning that users must provide all keys to conduct a transaction.

Multi-signature implementation at the cryptographic level

At the cryptographic level, multi-signature verification can be achieved through specific cryptographic algorithms, and this solution can sometimes bypass the need for on-chain smart contracts. We often categorize it as follows:

1. Multisignature Algorithm ( Multisignatures ). This signature algorithm only supports the “M-of-M” mode, where users must submit all signatures corresponding to the keys at once.

2. Threshold Signature Algorithm ( Threshold Signatures ). This algorithm supports the “M-of-N” model, but generally speaking, the construction difficulty is more complex compared to the multi-signature algorithms mentioned above.

3. Secret Sharing Algorithm ( Secret sharing ). In the design of this algorithm, users can split a single private key into multiple parts, and once the user collects enough private key fragments, they can restore the original private key and generate a signature.

Bitcoin introduced the Schnorr algorithm after the SegWit upgrade (, which naturally allows for multi-signature verification. Meanwhile, the Ethereum consensus layer uses the BLS threshold algorithm to implement the core voting functionality within the PoS system.

This multi-signature scheme that relies solely on cryptographic algorithms has better compatibility, as it does not depend on smart contracts, for example, it can be implemented using purely off-chain solutions.

The signatures generated by pure cryptographic multi-signature schemes are exactly the same in format as traditional single private key signatures and can be accepted by any blockchain that supports standard signature formats, thus possessing strong universality. However, multi-signature algorithms based on specific cryptography are relatively complex and very difficult to implement, often requiring reliance on certain specific facilities during use.

Real-world challenges of multi-signature technology

Although commonly used multi-signature wallets significantly enhance asset security, they also introduce new risks. The most obvious issue is the increased operational complexity: each transaction requires coordination and confirmation from multiple parties, which becomes a significant obstacle in time-sensitive scenarios.

Moreover, the more serious issue is that multi-signature wallets often shift the risk from private key management to the process of signature coordination and verification. As seen in the recent Bybit theft case, attackers successfully deceived Bybit's multi-signature managers into signing phishing transactions by implanting phishing code for the Safe front-end interface in the AWS facilities that Safe relies on. This indicates that even with the use of more advanced multi-signature technology, the security of the front-end interface and the processes of signature verification and coordination still have numerous vulnerabilities.

In addition, not all signature algorithms used in blockchain natively support multi-signature. For example, the secp 256 k 1 curve used by the Ethereum execution layer has relatively few multi-signature algorithms, which limits the application of multi-signature wallets across different ecosystems. For networks that require multi-signature implementation through smart contracts, there are additional considerations such as contract vulnerabilities and upgrade risks.

MPC: Revolutionary Breakthrough

If a multi-signature wallet enhances security by distributing private keys, then the MPC (Multi-Party Computation) technology takes it a step further by fundamentally eliminating the existence of a complete private key. In the world of MPC, a complete private key never appears in any single location, not even during the key generation process. At the same time, MPC often supports more advanced features such as refreshing private keys or adjusting permissions.

In the application scenarios of cryptocurrency, the workflow of MPC demonstrates unique advantages. During the key generation phase, multiple participants each generate random numbers, and then, through complex cryptographic protocols, each party calculates its own “key share.” These shares have no meaning when viewed individually, but they are mathematically related and can collectively correspond to a specific public key and wallet address.

When a signature is needed for a specific on-chain operation, each participant can generate “partial signatures” using their own key shares, and then cleverly combine these partial signatures through the MPC protocol. The final signature generated is identical in format to a signature created with a single private key, and external observers cannot even tell that this signature was generated by the MPC facility.

The revolutionary aspect of this design is that the complete private key has never appeared anywhere throughout the entire process. Even if an attacker successfully infiltrates the system of a participant, they cannot obtain the complete private key, as this private key essentially does not exist anywhere.

The essential difference between MPC and multi-signature

Although MPC and multi-signature (multisig) both involve multiple parties, there are fundamental differences between the two. From the perspective of an outside observer, transactions generated by MPC are indistinguishable from ordinary single-signature transactions, which provides users with better privacy.

This difference is also reflected in compatibility. Multi-signature wallets require native support from the blockchain network or rely on smart contracts, which limits their use in certain areas. In contrast, signatures generated by MPC use the standard ECDSA format, which can be used anywhere that supports this signature algorithm, including Bitcoin, Ethereum, and various DeFi platforms.

MPC technology also offers greater flexibility in adjusting security parameters. In traditional multi-signature wallets, changing the signing threshold or the number of participants often requires creating a new wallet address, which poses risks. ) Of course, multi-signature wallets based on smart contracts can conveniently modify participants and their permissions (, while in an MPC system, these parameter adjustments can be completed more flexibly and succinctly, without the need to change on-chain accounts and contract code, providing greater convenience for asset management.

Challenges Faced by MPC

However, although MPC is superior to traditional multi-signature, it still faces corresponding challenges. The first is the complexity of implementation. The MPC protocol involves complex cryptographic calculations and multi-party communication, which makes the implementation and maintenance of the system more difficult. Any bug could lead to serious security vulnerabilities. In February 2025, Nikolaos Makriyannis and others discovered a method to steal its keys within an MPC wallet.

Performance overhead is another challenge. The MPC protocol requires complex computations and data exchanges between multiple parties, consuming more computing resources and network bandwidth than traditional single-signature operations. Although this overhead is acceptable in most cases, it can become a limiting factor in scenarios with extremely high performance requirements. In addition, the MPC system still requires online coordination among all participating parties to complete the signing process. While this coordination is transparent to users, it may affect the system's availability in cases of unstable network connections or when certain participants are offline.

In addition, MPC still cannot ensure decentralization. In the Multichain case of 2023, all 21 nodes participating in the MPC computation were controlled by one person, which is a typical Sybil attack. This is enough to prove that merely having dozens of nodes on the surface does not provide a high level of decentralization assurance.

DeepSafe: Building the Next Generation of Secure Verification Networks

Against the backdrop of relatively mature multi-signature and MPC technology, the DeepSafe team has proposed a more forward-looking solution: CRVA (Cryptographic Random Verification Agent). The innovation of DeepSafe lies in the fact that it does not simply replace existing signature technologies, but builds an additional layer of security verification on top of existing solutions.

CRVA's multi-factor verification

The core idea of DeepSafe is “dual insurance”: users can continue to use their familiar wallet solutions, such as Safe Wallet, and once a multi-signature transaction is completed and submitted to the blockchain, it will automatically be submitted to the CRVA network for additional verification, similar to the 2FA multi-factor authentication of Alipay.

In this architecture, the CRVA acts as a gatekeeper, reviewing each transaction based on the rules set by the user in advance. For example, limits on the amount for a single transaction, whitelisting of target addresses, transaction frequency restrictions, etc. If there are any anomalies, the transaction can be interrupted at any time.

The advantage of this 2FA multi-factor authentication is that even if the multi-signature process is manipulated (such as the front-end phishing attack in the Bybit incident), the insurance CRVA can still reject risky transactions based on preset rules, protecting users' asset security.

Technical upgrades based on traditional MPC solutions

In response to the shortcomings of traditional MPC asset management solutions, DeepSafe's CRVA solution has made significant improvements. Firstly, the CRVA network nodes adopt an asset staking access model, and the mainnet will officially launch only after reaching approximately 500 nodes. According to estimates, the assets staked by these nodes will be maintained at tens of millions of dollars or more for the long term.

Secondly, to improve the efficiency of MPC/TSS calculations, CRVA will randomly select nodes using a lottery algorithm, for example, selecting 10 nodes every half hour, which will act as validators to verify whether user requests should be approved, and then generate the corresponding threshold signature for release. To prevent internal collusion or external hacker attacks, CRVA's lottery algorithm uses an original circular VRF, combined with ZK to hide the identity of those selected, making it impossible for outsiders to directly observe the selected participants.

Of course, just reaching this level is not enough. Although the outside world does not know who has been selected, the selected individual knows at this moment, so there is still a path for collusion. To further eliminate collusion, all nodes of CRVA must run the core code in a TEE hardware environment, which is equivalent to conducting core work in a black box. As a result, no one can know whether they have been selected unless they can crack the TEE trusted hardware, which is extremely difficult to achieve given the current technological conditions.

The above discusses the basic idea of DeepSafe's CRVA solution. In the actual workflow, nodes within the CRVA network need to engage in a large amount of broadcasting communication and information exchange, and the specific process is as follows:

1. All nodes must first stake assets on-chain before entering the CRVA network, leaving a public key as registration information. This public key is also known as the “permanent public key.”

2. Every hour, the CRVA network randomly selects several nodes. However, before this, all candidates must locally generate a one-time “temporary public key” and simultaneously generate a ZKP to prove that the “temporary public key” is associated with the “permanent public key” recorded on the chain; in other words, everyone must use ZK to prove that they exist on the candidate list without revealing who they are.

3. The purpose of the “temporary public key” is to protect privacy. If the draw is conducted directly from the set of “permanent public keys” and the results are announced, everyone will immediately know who has been elected. However, if only the one-time “temporary public key” is exposed, and then a few people are selected from the “temporary public key” set, you will at most know that you have won but will not know who the other winning temporary public keys correspond to.

4. In order to further prevent identity leakage, CRVA intends to ensure that you do not even know what your “temporary public key” is. The generation process of the temporary public key is completed within the TEE environment of the node, and you running the TEE cannot see what is happening inside.

5. Then, the temporary public key plaintext is encrypted into “garbled text” within the TEE and sent to the outside, where only specific Relayer nodes can restore it. Of course, the restoration process is also completed within the TEE environment of the Relayer nodes, and the Relayer does not know which candidates correspond to these temporary public keys.

6. After the Relayer restores all the “temporary public keys”, it collects them uniformly and submits them to the VRF function on the chain, from which it selects the winners. These individuals then validate the transaction requests sent from the user frontend, and based on the validation results, generate a threshold signature, which is finally submitted to the chain. (It is important to note that the Relayer here is also hidden in identity and selected periodically.)

Some may wonder how the work can proceed since each node does not know whether it has been selected. In fact, as mentioned earlier, everyone will generate a “temporary public key” within their local TEE environment. Once the lottery results are out, we will directly broadcast the list. Everyone just needs to input the list into the TEE to verify whether they have been selected.

The core of the DeepSafe solution lies in the fact that almost all important activities occur within TEE hardware, making it impossible to observe what is happening from outside the TEE. Each node does not know who the selected validators are, preventing collusion and significantly increasing the cost of external attacks. To attack a CRVA committee based on DeepSafe, it would theoretically require attacking the entire CRVA network, and with each node having TEE protection, the difficulty of the attack rises significantly.

As for the situation where CRVA behaves maliciously, since CRVA is a network system of automated nodes, as long as the initial code used to start it does not contain malicious logic, there will be no situation where CRVA actively refuses to cooperate with users, so it can basically be ignored;

If CRVA experiences a large number of node outages due to force majeure such as power outages or floods, users still have a way to safely withdraw their assets according to the processes mentioned in the above plan. The underlying trust assumption here is that we trust CRVA to be sufficiently decentralized and will not act maliciously on its own (the reasons have been sufficiently explained earlier).

Summary

The development of Web3 signature technology showcases humanity's relentless exploration in the field of digital security. From the initial single private key to multi-signature wallets, then to MPC, and emerging solutions like CRVA, each advancement opens up new possibilities for the secure management of digital assets.

However, technological advancement does not mean the elimination of risk. Every new technology can solve existing problems while also introducing new complexities and risk factors. From the Bybit incident, we see that even with advanced multi-signature technology, attackers can still bypass technical defenses through social engineering and supply chain attacks. This reminds us that technological solutions must be combined with good operational practices and security awareness.

Ultimately, the security of digital assets is not just a technical issue, but a systemic challenge. Whether it is multi-signature, MPC, or CRVA, these are merely tentative solutions to potential risks. With the development of the blockchain industry, there will still be a need for innovation in the future to find safer and more trustless solutions.