Comparison of Web3 asset management solutions: multi-signature, MPC, and CRVA

In the Web3 community, 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, most people are accustomed to single-point private key management, which is like putting all their eggs in one basket, vulnerable to losing everything to hackers at any moment due to a phishing link. To address this challenge, the blockchain industry has developed a variety of solutions. From multi-sig wallets to MPC to CRVA proposed by the DeepSafe project, each technological advancement has opened up new avenues for asset management. This article will explore the principles, features, and applicable scenarios of these three asset management solutions to help readers choose the one that best suits them. Multi-Signature Wallets: Passable, But Not Excellent The concept of multi-sig wallets stems from a simple wisdom: Don't concentrate all authority in one place. This idea has long been widely applied in real-world settings, such as the separation of powers and board voting. Similarly, in Web3, multi-sig wallets create multiple independent keys to spread risk. The most common model is the "M-of-N" model. For example, in a "2-of-3" setup, the system generates three private keys, but as long as any two of them generate signatures, the designated account can execute transactions.

This design provides a certain degree of fault tolerance—even if a private key is lost, the assets are still safe and controllable. If you have multiple independent devices for storing keys, a multi-signature solution will be more reliable.

Generally speaking,

Multi-signature wallets are technically divided into two categories. One is conventional multi-signature, which is generally implemented using on-chain smart contracts or supporting components of the underlying public chain and often does not rely on specific cryptographic tools. Another type of multi-signature wallet relies on specialized cryptographic algorithms. The security of these wallets depends on the specific algorithms, and sometimes they can completely eliminate the need for on-chain contracts. Below, we'll discuss each of these approaches. Representatives of Conventional Multi-Signature Solutions: Safe Wallet and Bitcoin Taproot. As one of the most popular multi-signature solutions, Safe Wallet uses conventional Solidity smart contracts to implement multi-signatures. In Safe Wallet's architecture, each multi-signature participant controls an independent key, while the on-chain smart contract acts as an "arbitrator." Only when a sufficient number of valid signatures are collected will the contract approve transactions between the multi-signature accounts. The advantages of this approach lie in its transparency and verifiability. All multi-signature rules are explicitly encoded in the smart contract, allowing anyone to audit the code logic. Furthermore, users can add modules to multi-signature accounts to provide richer functionality, such as limiting the maximum amount of funds per transaction. However, this transparency also means that the details of the multi-signature wallet are completely public on the blockchain, potentially exposing the user's asset management structure. In addition to SafeWallet, a well-known multi-signature solution in the Ethereum ecosystem, there are also multi-signature wallets built using BTC scripts in the Bitcoin network, such as those based on the OP_CHECKMULTISIG opcode. This opcode can verify whether the number of signatures contained in the UTXO unlocking script meets the requirement. It's worth noting that the conventional multi-signature algorithms described above all support "M-of-N" mode, but some of the multi-signature algorithms based on specific cryptographic algorithms described later only support "M-of-M" mode, meaning that users must provide all keys to conduct transactions. 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 eliminate the need for on-chain smart contracts. We often categorize them as follows: 1. Multi-signature algorithms. This signature algorithm only supports "M-of-M" mode, and users must submit signatures corresponding to all keys at once. 2. Threshold Signatures. This algorithm supports "M-of-N" mode, but is generally more complex to build than the multi-signature algorithms mentioned above. 3. Secret sharing algorithms. In this algorithm, users can split a single private key into multiple pieces. Once they have collected enough fragments, they can recover the original private key and generate a signature. Bitcoin introduced the Schnorr algorithm after the Segregated Witness (SegWit) upgrade, which naturally enables multi-signature verification. Ethereum's consensus layer uses the BLS threshold algorithm to implement the core voting function within the PoS system. This multi-signature scheme, which relies solely on cryptographic algorithms, has better compatibility because it can be implemented without relying on smart contracts, such as using a purely off-chain solution. The signatures generated by purely cryptographic multi-signature schemes are identical in format to traditional single-private-key signatures and can be accepted by any blockchain that supports standard signature formats, thus possessing strong versatility. However, multi-signature algorithms based on specialized cryptography are complex and difficult to implement, often requiring reliance on specialized infrastructure. While common multi-signature wallets significantly improve asset security, they also introduce new risks. The most obvious issue is increased operational complexity: each transaction requires coordination and confirmation from multiple parties, which becomes a significant obstacle in time-sensitive scenarios. More seriously, multi-signature wallets often shift risk from private key management to signature coordination and verification. As in the recent Bybit theft, attackers successfully tricked Bybit's multi-signature administrator into signing a phishing transaction by implanting phishing Safe front-end interface code into the AWS infrastructure that Safe relies on. This demonstrates that even with advanced multi-signature technology, the security of the front-end interface and signature verification and coordination processes remains vulnerable. Furthermore, not all blockchain signature algorithms natively support multi-signatures. For example, the secp256k1 curve used by Ethereum's execution layer rarely supports multi-signature algorithms, limiting the application of multi-signature wallets in different ecosystems. For networks that require multi-signatures through smart contracts, there are additional considerations such as contract vulnerabilities and upgrade risks. MPC: A Revolutionary Breakthrough If multi-signature wallets improve security by decentralizing private keys, MPC (Multi-Party Secure Computation) technology goes a step further by fundamentally eliminating the existence of complete private keys. In an MPC world, complete private keys never appear in any single location, not even during the key generation process. Furthermore, MPC often supports more advanced features, such as refreshing private keys or adjusting permissions. In cryptocurrency applications, the MPC workflow offers unique advantages. During the key generation phase, multiple participants independently generate random numbers. Then, through a complex cryptographic protocol, each party calculates its own "key fragment." These fragments are meaningless individually, but they are mathematically linked and collectively correspond to a specific public key and wallet address. When signing an on-chain transaction, each participant uses its own key fragment to generate a "partial signature," which is then cleverly combined using the MPC protocol. The resulting signature is identical in format to a single private key signature, making it impossible for an outside observer to tell it was generated by the MPC facility. The revolutionary aspect of this design is that the full private key is never seen anywhere during this entire process. Even if an attacker successfully compromises a participant's system, they cannot obtain the full private key because it exists nowhere.

The Essential Difference Between MPC and Multi-Signature

Although both MPC and multi-sig involve multiple parties, there are fundamental differences between the two. To an outside observer, transactions generated by MPC are indistinguishable from ordinary single-sig transactions, providing users with better privacy.

This difference is also reflected in compatibility.

Multi-sig wallets require native support from the blockchain network or rely on smart contracts, which limits their use in some locations. The signatures generated by MPC use the standard ECDSA format and can be used anywhere that supports this signature algorithm, including Bitcoin, Ethereum, and various DeFi platforms.

MPC technology also provides greater flexibility for adjusting security parameters. In traditional multi-signature wallets, changing the signature threshold or the number of participants usually requires creating a new wallet address, which brings risks. (Of course, multi-signature wallets based on smart contracts can easily modify the participants and their permissions), but in the MPC system, the adjustment of these parameters can be completed more flexibly and concisely, without changing the on-chain accounts and contract code,

providing greater convenience for asset management.

Challenges Facing MPC

However, while MPC offers advantages over standard multi-signatures, it still faces corresponding challenges. First is implementation complexity. The MPC protocol involves complex cryptographic calculations and multi-party communication, making the system more difficult to implement and maintain. Any bug could lead to a serious security vulnerability. In February 2025, Nikolaos Makriyannis and others discovered a method to steal keys from an MPC wallet.

Performance overhead is another challenge. The MPC protocol requires complex computations and data exchange between multiple parties, consuming significantly more computing resources and network bandwidth than traditional single-signature operations. While this overhead is acceptable in most cases, it can become a limiting factor in certain performance-critical scenarios. Furthermore, the MPC system still requires online coordination among all participating parties to complete signatures. While this coordination is transparent to users, it can impact system availability if network connectivity is unstable or some participants are offline. Furthermore, MPC still cannot guarantee decentralization. In the 2023 Multichain case, all 21 nodes participating in the MPC calculation were controlled by a single person, a classic example of a Sybil attack. This case demonstrates that simply having a few dozen nodes alone cannot provide a high degree of decentralization.

DeepSafe: Building the Next-Generation Secure Verification Network

With multi-signature and MPC technologies already relatively mature, the DeepSafe team has proposed a more forward-looking solution: CRVA (Cryptographic Random Verification Agent). DeepSafe's innovation lies in not simply replacing existing signature technology, but rather building an additional layer of security verification on top of existing solutions. CRVA's Multi-Factor Authentication The core concept of DeepSafe is "double insurance": Users can continue to use their familiar wallet solutions, such as Safe Wallet. When a multi-signature transaction is submitted to the chain, it is automatically submitted to the CRVA network for additional verification, similar to Alipay's 2FA multi-factor authentication. In this architecture, CRVA acts as a gatekeeper, reviewing each transaction according to user-defined rules. For example, there are limits on single transaction amounts, target address whitelists, transaction frequency, and other restrictions. If there are any abnormalities, 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), CRVA, as insurance, can still reject risky transactions according to preset rules and protect the security of users' assets.

Technical upgrade based on traditional MPC solutions

In response to the shortcomings of traditional MPC asset management solutions, DeepSafe's CRVA solution has made a lot of improvements. First, CRVA network nodes adopt the form of asset pledge access, and the main network will be officially launched only after reaching about 500 nodes.According to estimates, the assets pledged by these nodes will be maintained at tens of millions of US dollars or more for a long time;

Secondly,In order to improve the efficiency of MPC/TSS calculations, CRVA will randomly select nodes through a lottery algorithm.For example, 10 nodes are selected every half an hour. They will act as validators to verify whether the user request should be approved, and then generate the corresponding threshold signature to release it. To prevent internal collusion or external hacker attacks, CRVA's lottery algorithm uses an original ring-shaped VRF combined with ZK to hide the identity of the winners,making it impossible for the outside world to directly observe the winners.

Of course, achieving this level alone is not enough. Although the outside world does not know who has been selected, the winners themselves know it, so there is still a path for collusion. To further prevent collusion, all CRVA nodes must run their core code within the TEE hardware environment, effectively performing their core work in a black box. This way, no one can tell whether they have been selected, unless they can crack the TEE trusted hardware, which is extremely difficult to achieve given current technical conditions. The above is the basic idea of ​​DeepSafe's CRVA solution. In the actual workflow, a large amount of broadcast communication and information exchange is required between nodes in the CRVA network. The specific process is as follows: 1. Before entering the CRVA network, all nodes must first pledge assets on the chain and leave a public key as registration information. This public key is also called the "permanent public key". 2. Every hour, the CRVA network will randomly select several nodes. However, before this happens, all candidates must generate a one-time "temporary public key" locally and simultaneously generate a ZKP to prove the link between the "temporary public key" and 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 "temporary public keys" is to protect privacy. If the lottery is drawn directly from the set of "permanent public keys", everyone will know who was elected when the results are announced. If everyone only reveals the one-time "temporary public key" and then selects a few people from the set of "temporary public keys", at most you will know that you have won the lottery, but you will not know the corresponding temporary public keys of the other winners.

4.To further prevent identity leakage,CRVA intends to make you yourself unaware of your "temporary public key".The generation process of the temporary public key is completed in the node's TEE environment. You who are running the TEE cannot see what is happening inside. 5. The temporary public key is then encrypted into "garbled code" within the TEE and sent to the outside world. Only specific Relayer nodes can restore it. Of course, the restoration process is also completed within the Relayer node's TEE environment. The Relayer does not know which candidates these temporary public keys correspond to. 6. After the Relayer restores all "temporary public keys", it collects them and submits them to the on-chain VRF function, from which winners are selected. These winners then verify the transaction request sent by the user's front-end, generate a threshold signature based on the verification results, and finally submit it to the chain. (It should be noted that the Relayer here is actually also hidden and selected regularly)

Some people may ask,Since each node does not know whether it has been selected, how can the work be carried out?In fact, as mentioned earlier, everyone will generate a "temporary public key" in the local TEE environment. After the lottery results come out, we will directly broadcast the list. Everyone only needs to pass the list into the TEE and check whether they have been selected. The core of the DeepSafe solution lies in the fact that almost all important activities are carried out within the TEE hardware, making it impossible to observe what is happening from outside the TEE. Every node does not know who the selected validators are, preventing collusion and significantly increasing the cost of external attacks. To attack the DeepSafe-based CRVA committee, theoretically, one must attack the entire CRVA network. Furthermore, since every node is protected by a TEE, the difficulty of attack is greatly increased. As for the situation where CRVA does something malicious, since CRVA is an automatically running node network system, as long as its initial startup code does not contain malicious logic, CRVA will not actively refuse to cooperate with users, so it can basically be ignored; If CRVA nodes are shut down in large numbers due to force majeure such as power outages or floods, users can still withdraw their assets safely according to the process mentioned in the above solution. The trust assumption here is that we trust that CRVA is sufficiently decentralized and will not actively do malicious things (the reasons have been fully explained above). Summary: The development of Web3 signature technology demonstrates humanity's relentless pursuit of digital security. From the initial single private key to multi-signature wallets, to MPC, and emerging solutions like CRVA, each advancement has opened up new possibilities for the secure management of digital assets. However, technological advancement does not eliminate risks. While solving existing problems, each new technology can also introduce new complexities and risks. The Bybit incident shows that even with advanced multi-signature technology, attackers can still circumvent technical defenses through social engineering and supply chain attacks. This reminds us that technological solutions must be combined with sound operational practices and security awareness. Ultimately, digital asset security isn't just a technical issue; it's a systemic challenge. Multi-signature, MPC, and CRVA are all tentative solutions to potential risks. As the blockchain industry evolves, innovation is necessary to find a safer and more trustless solution.