Author: Shew, Xianrang
In the Web3 world, 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 be wiped out in an instant. However, most people are accustomed to using a single point of private key management, which is like putting all your eggs in one basket. At any moment, a phishing link could result in your entire holdings being handed over to a hacker.
To address this challenge, various solutions have emerged in the blockchain space. From multi-signature wallets to MPC and the DeepSafe project's CRVA, each technological advancement has opened up new avenues for asset management. This article will explore the principles, characteristics, and applicable scenarios of these three asset management solutions to help readers choose the path that best suits them.
Multi-Signature Wallets: Passable, but Not Excellent
The concept of multi-signature wallets stems from a simple wisdom: don't concentrate all authority in one place. This idea has long been widely used in real-world applications, such as the separation of powers and board voting.
Similarly, in Web3, multi-signature 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 a signature, the specified account can execute a transaction.
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, the multi-signature solution will be more reliable.
Generally speaking, multi-signature wallets are technically divided into two categories. Conventional multi-signature wallets are typically implemented using on-chain smart contracts or supporting components of the underlying public blockchain, often without relying on specific cryptographic tools. The other type relies on specialized cryptographic algorithms, whose security depends on the specific algorithms and can sometimes completely eliminate the need for on-chain contracts. Below, we will discuss each of these approaches.
Representatives of conventional multi-signature solutions: Safe Wallet and Bitcoin Taproot
SafeWallet, one of the most popular multi-signature solutions, uses conventional Solidity smart contracts to implement multi-signatures. In SafeWallet'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 linked accounts.
The advantages of this approach lie in 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 enhance their functionality, such as limiting the maximum amount of funds that can be transacted. However, this transparency also means that the details of the multi-signature wallet are fully public on the blockchain, potentially exposing the user's asset management structure.
In addition to SafeWallet, a well-known multi-signature solution within the Ethereum ecosystem, Bitcoin also has multi-signature wallets built using BTC scripts, such as those based on OP_CHECKMULTISIG opcode. This opcode verifies that the number of signatures contained in the UTXO unlocking script meets the required number.
It is worth noting that the conventional multi-signature algorithms introduced above all support "M-of-N" mode, but some of the multi-signature algorithms based on specific cryptographic algorithms introduced later only support "M-of-M" mode, that is, 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 get rid of the participation of on-chain smart contracts. We tend to categorize it as follows:
1. Multisignatures. 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 the "M-of-N" model, but is generally more complex to build than the multi-signature algorithm mentioned above.
3. Secret Sharing. In this algorithm, users can split a single private key into multiple pieces. Once the user has collected enough private key fragments, they can restore 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 of the PoS system.
This multi-signature solution that relies solely on cryptographic algorithms has better compatibility because it does not rely on smart contracts, such as using a purely off-chain solution.
The signatures generated by pure cryptographic multi-signature schemes are identical in format to traditional single-private-key signatures and can be accepted by any blockchain that supports the standard signature format, thus possessing strong versatility. However, multi-signature algorithms based on specific cryptography are complex and difficult to implement, often requiring reliance on specialized infrastructure.
Real challenges of multi-signature technology
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 a 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 distributing private keys, then MPC (Multi-Party Computation) technology goes a step further, fundamentally eliminating the existence of complete private keys. In an MPC world, complete private keys are never present in any single location, not even during the key generation process. MPC also 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. Through complex cryptographic protocols, each party calculates its own "key fragment." These shares are meaningless individually, but they are mathematically linked and can be mapped to a specific public key and wallet address.
When signing an on-chain transaction, each participant can generate a "partial signature" using their own key fragments. These partial signatures are 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 complete private key never appears anywhere during the entire process. Even if an attacker successfully compromises a participant’s system, they cannot obtain the complete private key because the private key does not exist anywhere.
The essential difference between MPC and multi-signature
While both MPC and multi-signature involve multiple parties, there are fundamental differences between the two. From an outside observer, transactions generated by MPC are indistinguishable from ordinary single-signature transactions, providing users with better privacy.
This difference also manifests itself in compatibility. Multi-signature wallets require native blockchain network support or rely on smart contracts, which limits their use in certain contexts. Signatures generated by MPC, on the other hand, 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 typically requires creating a new wallet address, which introduces risks. (Of course, multi-signature wallets based on smart contracts can easily modify participants and their permissions.) In an MPC system, these parameters can be adjusted more flexibly and concisely, without having to change on-chain accounts or contract code, providing greater convenience for asset management.
Challenges facing MPC
However, while MPC offers advantages over standard multi-signature systems, it still presents challenges. The first is implementation complexity. The MPC protocol involves complex cryptographic calculations and multi-party communication, making the system difficult to implement and maintain. Any bug could lead to serious security vulnerabilities. In February 2025, Nikolaos Makriyannis et al. discovered a method to steal keys from MPC wallets.
Performance overhead is another challenge . The MPC protocol requires complex computation 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 the signature process. 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 MPC calculations were controlled by a single person, a classic Sybil attack. This incident clearly demonstrates that simply having a few dozen nodes does not provide a high degree of decentralization.
DeepSafe: Building the Next-Generation Security Verification Network
With both 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 the fact that it doesn't simply replace existing signature technology, but rather builds an additional layer of security verification on top of existing solutions.
Multi-factor authentication with CRVA
The core idea 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 will automatically be 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 based on user-defined rules, such as single transaction limits, target address whitelists, and transaction frequency restrictions. If any abnormal situation occurs, 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.
Technology upgrade based on traditional MPC solution
DeepSafe's CRVA solution addresses the shortcomings of traditional MPC asset management solutions. First, CRVA network nodes require asset staking for access. The mainnet will not be officially launched until approximately 500 nodes are reached. It is estimated that the assets staked by these nodes will remain in the tens of millions of dollars or more over the long term.
Secondly, to improve the efficiency of MPC/TSS calculations, CRVA randomly selects nodes through a lottery algorithm. For example, 10 nodes are selected every half hour. These nodes serve as validators to verify whether user requests should be approved and then generate the corresponding threshold signature to release them. 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 selected nodes, making them invisible to the outside world.
Of course, this isn't enough. While the outside world doesn't know who's been selected, the chosen individual knows, leaving 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 if they've been selected unless they can hack the TEE's trusted hardware, which is, of course, extremely difficult to achieve given current technology.
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 randomly selects 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 association between the "temporary public key" and the "permanent public key" recorded on the chain. In other words, each person must use ZK to prove that they exist on the candidate list without revealing their identity.
3. The purpose of "temporary public keys" is to protect privacy. If lots are drawn directly from the set of "permanent public keys," everyone will know who was selected when the results are announced. If everyone only reveals a one-time "temporary public key" and then selects a few people from the set of "temporary public keys," you will only know that you have won the lottery, but you will not know the corresponding temporary public keys of the other winners.
To further prevent identity leaks, CRVA aims to prevent you from even knowing what your temporary public key is. The temporary public key is generated within the TEE environment of your node, and you, the user 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 the specific Relayer node can restore it. Of course, the restoration process is also completed in the TEE environment of the Relayer node. The Relayer does not know which candidates these temporary public keys correspond to.
6. After the Relayer recovers all the "temporary public keys," it aggregates them and submits them to the on-chain VRF function, which randomly selects winners. These winners then verify the transaction request sent by the user's front-end. Based on the verification results, they generate a threshold signature and submit it to the chain. (Note that the Relayer's identity is also hidden and selected regularly.)
Some people may ask, if each node does not know whether it has been selected, how can the work be carried out? In fact, as mentioned earlier, each person will generate a "temporary public key" in the local TEE environment. After the lottery results are announced, we will directly broadcast the list. Everyone only needs to enter 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 their occurrences unobservable from outside the TEE. Each node is unaware of the selected validators, preventing collusion and significantly increasing the cost of external attacks. Attacking the DeepSafe-based CRVA committee theoretically requires attacking the entire CRVA network, and since every node is protected by a TEE, the attack becomes significantly more difficult.
As for CRVA's malicious behavior, 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 a large number of CRVA nodes are down due to force majeure such as power outages or floods, users can still safely withdraw their assets according to the process described in the above solution. The trust assumption here is that we trust CRVA to be sufficiently decentralized and not to actively engage in malicious activities (the reasons have been fully explained above).
Summarize
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 each new technology addresses existing problems, it can also introduce new complexities and risks. The Bybit incident shows that even with advanced multi-signature technology, attackers can still circumvent technical safeguards 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-sig, MPC, and CRVA are all tentative solutions to potential risks. As the blockchain industry evolves, innovation is necessary to find safer and more trustless solutions.
