The correct management of MPC wallets from the perspective of the Multichain event

Author: Loki, Senior Researcher at New Fire Technology

1. What Issues in MPC Wallet Management Were Exposed by the Multichain Incident?

On July 14, Multichain tweeted that its CEO Zhaojun was taken away by the police at his home on May 21, and since then, he has lost contact with the global Multichain team. The team contacted the MPC node operators and learned that the access keys for the MPC node server operations had been revoked.

This tweet revealed the reason behind the operational anomalies at Multichain and raised a question: why did Multichain still face such risks despite using MPC? The answer is quite simple: Multichain adopted MPC technology to manage its treasury, but adopting decentralized technology does not equate to decentralization; it requires a unified approach in both technology adoption and management methods.

There are many similar cases. BTC is decentralized, but if a miner monopolizes 100% of the hash power, the decentralization of the algorithm is meaningless; ETH is decentralized, but Vitalik still emphasizes the importance of DVT (Distributed Validator Technology) to avoid centralization trends.

The same applies to Multichain. A further look at the announcement details reveals that the reason for Multichain's issues is that all node servers were actually running under Zhaojun's personal cloud server account. This centralization of node servers is akin to a miner monopolizing 100% of the hash power; Multichain's management approach is equivalent to Zhaojun controlling all assets with a single-signature wallet. Based on this, the problem with Multichain is that Zhaojun should not control all MPC shards and did not provide a backup solution for extreme force majeure situations.

The next question is how to effectively leverage the characteristics of MPC technology. There are three main points:

(1) Provide stronger transparency to prevent conflicts of interest;

(2) Strictly adhere to decentralized custody methods to avoid excessive concentration of power;

(3) Prepare contingency plans for extreme force majeure situations.

• [ Preventing Conflicts of Interest: Rejecting Black Boxes ]

One fact that needs attention is that Fantom was also greatly affected by this incident. FTM founder AC stated in a forum that Multichain's failure was a "significant blow," as they had previously received many assurances from the team regarding server decentralization, access, and geographical distribution. In hindsight, Multichain did not fulfill the guarantees of server, access, and geographical distribution, and Fantom did not verify or had no way to verify this, choosing to simply trust Multichain, which ultimately led to collateral damage.

It is clear that Multichain's MPC solution is essentially a "black box," and the reason for this "black box" is that Multichain is both the builder and the user of the service. This concentration of attributes leads to opacity and room for malfeasance. The solution to this problem is to introduce a completely neutral third party that does not involve conflicts of interest, which means using a third-party MPC service with sufficient credibility instead of a self-built MPC service.

In addition to cross-chain bridges, conflicts of interest are prevalent in Web3. For example, centralized exchanges simultaneously perform the functions of providing trading services and safeguarding user assets, while these exchanges can profit from using these funds, such as through on-chain mining, market making, and investments. In fact, this is also the starting point for Sinohope to build Openloop; trust cannot be verified, and a reliable mechanism is the only way to prevent malfeasance.

Returning to this incident, if Multichain had used a third-party MPC service with sufficient credibility, at least under the circumstances allowed by Multichain, the service provider could have provided information verification for custodial solutions to stakeholders like Fantom, eliminating the "black box."

• [ Decentralized Custody: Rejecting Single Point Risks ]

In hindsight, Zhaojun's single point risk was the direct cause of the incident, and AC's response also provided us with the correct approach: [ensuring guarantees for servers, access, and geographical distribution]. These factors are also the principles that Sinohope follows when building products.

First, Sinohope adopts a 3-3 multi-signature scheme (also supports t-n threshold signature settings), where 2 shards are co-managed by the platform, ensuring security through high-strength encryption + trusted execution environments. Transactions can only be signed with the participation of all three parties, avoiding single point risks for users.

Diagram: Sinohope MPC-TSS Technical Principles

Secondly, business operations are typically hierarchical, so access should also be hierarchical. Therefore, Sinohope has adopted a multi-level private key derivation design, which allows managers to control the overall situation while also accommodating frontline operators to manage specific permissions, avoiding disruptions to the entire business process due to single point risks.

Finally, Sinohope has implemented online remote multi-active distributed storage, three-level offline cold storage backups, and integrated professional backup recovery services to ensure the highest level of geographical distribution guarantees. This series of mechanisms can minimize asset losses or service unavailability caused by single point risks, including at the private key level, personnel level, and external environment level.

• [ Preparing Social Recovery Plans for Extreme Situations ]

It is undeniable that no solution is perfect. Ensuring the decentralization of servers, access, and geography can solve some problems, but not all. We must acknowledge that many risks still exist, such as force majeure factors in the physical world. When unavoidable situations arise, we need to consider how to respond when such extreme force majeure situations occur.

Based on this, Sinohope has conceived an SOS Mode for risks of force majeure in the physical world. This service will be offered as a non-standard, optional service to users in need and will be customized based on actual requirements. This mode will not only include traditional private key sharding but will also set up several SOS shards, which will be managed separately from ordinary private key shards.

Under normal circumstances, SOS shards will not have any effect. However, in certain specific situations, SOS shards will be activated, such as when the private key shard manager/Owner manually activates them, when the private key shard connection is interrupted for a certain time threshold, when SOS shards proactively initiate an emergency event, or when a governance vote passes according to established rules. Once the SOS Mode is activated, SOS shards will replace private key shards to facilitate asset transfer or disposal in emergencies.

Of course, to prevent malfeasance by SOS shard holders, several restrictions can be added, such as setting a delay for the activation of SOS Mode, during which ordinary private key shards can override SOS Mode; or setting a lock-up period after the emergency transfer of assets in SOS Mode, during which further transfers cannot occur to prevent asset loss.