Comparison of Web3 Asset Management Solutions: Multisignature, MPC, and CRVA

Author: 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, risking losing all assets to hackers at any moment by 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 opened new pathways 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.

Multisignature Wallet: Passable, but not Excellent

The concept of a multi-signature wallet stems 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 voting.

Similarly, in Web3, multi-signature wallets create multiple independent keys to distribute risk. The most common is the “M-of-N” model, for example, in a “2-of-3” setup, the system generates a total of three private keys, but as long as any two of those private keys generate a signature, the designated account can execute the transaction.

This design offers 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 implement, and often does not rely on specific cryptographic tools. The other type is the multi-signature wallet that depends on special cryptographic algorithms, where the security relies on the specific algorithm and sometimes can 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 currently, implements multi-signature using 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”. The contract only approves the multi-signature associated account to execute transactions when a sufficient number of valid signatures are collected.

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 enable 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 fully 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 contained in the UTXO unlocking 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 may only support the “M-of-M” mode, meaning users must provide all keys to conduct a transaction.

Multisignature implementation at the cryptographic level

At the cryptographic level, multi-signature verification can be achieved through specific cryptographic algorithms, and this solution can sometimes eliminate the need for on-chain smart contract involvement. We often classify as follows:

1. Multisignature algorithm ( Multisignatures ). This signature algorithm only supports “M-of-M” mode, where users must submit the signatures corresponding to all 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. Key Splitting Algorithm ( Secret sharing ). In the design of this algorithm, users can divide a single private key into multiple parts. When users collect 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 enables multi-signature verification. Meanwhile, the Ethereum consensus layer utilizes the BLS threshold algorithm to implement the core voting function within the PoS system.

![Schnorr and Taproot: A Dynamic Duo Shaking Up The Network!])https://img-cdn.gateio.im/webp-social/moments-c7421c1700b8d77503a380e90ad3e63d.webp(

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

The signatures generated by pure cryptographic multi-signature schemes are completely identical in format to 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 difficult to implement, often requiring reliance on certain specific facilities when in use.

) The Real-World Challenges of Multi-Signature Technology

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

More seriously, multi-signature wallets often shift the risk from private key management to the coordination and verification of signatures. As seen in the recent Bybit theft, attackers successfully deceived Bybit's multi-signature managers into signing phishing transactions by implanting phishing Safe front-end interface code in the AWS facilities relied upon by Safe. This indicates that even with relatively advanced multi-signature technology, the security of the front-end interface and the signature verification and coordination stages still has numerous vulnerabilities.

![]###https://img-cdn.gateio.im/webp-social/moments-18fac951ff23f33f32a1d7151782be3a.webp(

Moreover, not all signature algorithms used by blockchains natively support multi-signature. For example, the secp256k1 curve used by the Ethereum execution layer has relatively few multi-signature algorithms, which limits the application of multi-signature wallets in different ecosystems. For networks that require multi-signature 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 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, the complete private key never appears at 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.

![])https://img-cdn.gateio.im/webp-social/moments-3e0f8cc411f9c5edee87473c9f474c6d.webp(

In the application scenarios of cryptocurrency, the workflow of MPC demonstrates unique advantages. In the key generation phase, multiple participants each generate random numbers, and then through complex cryptographic protocols, each party computes its own “key share.” These shares have no significance 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 a “partial signature” using their own key shares, which are then cleverly combined through the MPC protocol. The final signature generated is identical in format to that of a single private key, and outside observers cannot even tell that this signature was generated by an 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 breaches the system of a participant, they will not be able to 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 both involve multiple parties, there are fundamental differences between the two in essence. From the perspective of external observers, transactions generated by MPC cannot be distinguished from ordinary single-signature transactions, which provides better privacy for users.

![])https://img-cdn.gateio.im/webp-social/moments-defc997a9dbed36ce34da3c2631d4718.webp###

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

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

( Challenges Facing MPC

However, although MPC is superior to ordinary 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, making 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 the MPC wallet.

Performance overhead is another challenge. The MPC protocol requires complex computations and data exchanges among multiple parties, consuming more computational resources and network bandwidth than traditional single-signature operations. While this overhead is generally acceptable in most cases, it can become a limiting factor in scenarios with extremely high performance requirements. Additionally, the MPC system still requires online coordination among all participating parties to complete the signing process. Although 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.

Moreover, MPC still cannot ensure decentralization. In the Multichain case of 2023, all 21 nodes participating in the MPC computation were controlled by a single individual, which is a typical witch attack. This incident is sufficient 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 Security Verification Network

Against the backdrop of relatively mature multi-signature and MPC technologies, 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 security verification layer on top of the existing solutions.

) Multi-Factor Authentication for CRVA

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

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 single transaction amounts, whitelists for target addresses, transaction frequency restrictions, etc. If any abnormal situations arise, 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 CRVA, as a safeguard, can still reject risky transactions based on preset rules, protecting the security of users' assets.

![]###https://img-cdn.gateio.im/webp-social/moments-425718cbadee8e962e697514dbd49b1d.webp###

( technical upgrade based on traditional MPC solutions

To address the shortcomings of traditional MPC asset management solutions, DeepSafe's CRVA program has made significant improvements. First, the CRVA network nodes adopt an asset staking admission model, and the mainnet will only officially launch after reaching around 500 nodes. It is estimated that the assets staked by these nodes will be maintained at tens of millions of dollars or more in the long term;

Secondly, to improve the efficiency of MPC/TSS calculations, CRVA will randomly select nodes through a lottery algorithm, for example, selecting 10 nodes every half hour, which will serve as validators to verify whether user requests should be approved, and then generate corresponding threshold signatures 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 the selected individuals, making it impossible for the outside world to directly observe the selected participants.

![])https://img-cdn.gateio.im/webp-social/moments-1b71dbb2881f847407a5e41da7564648.webp###

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 the 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 the CRVA solution of DeepSafe. In the actual workflow, there needs to be a large amount of broadcast communication and information exchange among the nodes within the CRVA network. The specific process is as follows:

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

2. Every hour, the CRVA network will randomly select a few 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 their existence on the candidate list without revealing who they are;

3. The role of the “temporary public key” is to protect privacy. If the drawing is done directly from the set of “permanent public keys”, when the results are announced, everyone will immediately know who has been elected. If only one-time “temporary public keys” are exposed, and then a few individuals are selected from the “temporary public key” set, you will at most know that you have won, but you won't know who the other winning temporary public keys correspond to.

4. To further prevent identity leakage, CRVA intends to make it so 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. Only specific Relayer nodes can restore it. Of course, the restoration process is also completed in the TEE environment of the Relayer node, and the Relayer does not know which candidates correspond to these temporary public keys.

6. After the Relayer restores all “temporary public keys”, it collects them uniformly and submits them to the VRF function on the chain, from which winners are drawn. These individuals then verify the transaction requests sent from the user front-end, and based on the verification results, generate a threshold signature, which is finally submitted to the chain. (It should be noted that the Relayer here is actually also an identity that is hidden and selected periodically.)

Some may ask, since each node does not know whether it has been selected, how does the work proceed? In fact, as mentioned earlier, everyone will generate a “temporary public key” in their local TEE environment. Once the lottery results are out, we simply broadcast the list. Each person only needs to pass the list into the TEE and verify whether they have been selected.

The core of the DeepSafe solution is that almost all important activities take place within the TEE hardware, which cannot be observed 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 the CRVA committee based on DeepSafe, it would theoretically require attacking the entire CRVA network, and with each node having TEE protection, the difficulty of attacks rises significantly.

As for the situation where CRVA acts maliciously, since CRVA is an automated node network system, as long as the initial code at the time of startup 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 shutdowns 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 take malicious actions on its own (the reasons have been fully explained earlier).

Summary

The development history 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 risks. Every new technology, while solving existing problems, may also introduce new complexities and risk points. From the Bybit incident, we see that even with the use of 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's multi-signature, MPC, or CRVA, they are merely tentative solutions to potential risks. As the blockchain industry evolves, new innovations will be necessary in the future to find safer and more trustless alternatives.