Over $100,000 is locked, and the importance of trustless custody is judging from the Unibtc freezing incident

Original source: DeepSafe Research

On April 23, 2025, a netizen named Brain asked for help on Twitter with a friend, saying that when he was conducting arbitrage operations on a certain Bitcoin Layer2 chain, his unibtc assets of more than $100,000 were trapped by Bedrock officials and could not withdraw.

According to the disclosure of the party W, on April 17, he found that the unibtc issued by Bedrock had an abnormal price on a certain Bitcoin L2 chain and was decoupled from BTC. W believed that the decoupling would be temporarily and would return to anchor soon. There was a good arbitrage opportunity here, so he stepped into the Bitcoin L2, exchanged it for unibtc and sold it after it was back to anchor.

Unibtc has returned to anchor within 24 hours after decoupling, but when W tried to sell the Unibtc in his hand, he found that the Unibtc-BTC liquidity pool on the chain was officially removed by Bedrock, and this token was the only Unibtc secondary market exit channel on the chain. W couldn't get the unibtc in his hand, so he tried to span unibtc to other chains.

When he found the only cross-chain bridge (named Free) on the chain that supports Unibtc, he received a prompt - "The transaction requires signature authorization from the project party." W found the customer service of Free Cross-chain Bridge, and explained the opposite side: "The multi-signature key of the unibtc cross-chain is hosted by Bedrock. Without their permission, users cannot mention unibtc to other chains."

There is no way, W can only find Bedrock's relevant personnel to ask about this matter. The other party's preliminary reply was: "We can allow you to withdraw the principal, but whether the profits generated by your arbitrage can be withdrawn must be temporarily reviewed."

At this point, W realized that the exit path of Unibtc on this chain was completely cut off, and the Unibtc worth about 200,000 U in his hand was "temporarily frozen" - there was no way to sell it on this chain, nor could it cross on other chains. At this time, he felt very helpless and just wanted to withdraw his principal smoothly.

However, the attitudes of BedRock's relevant personnel became ambiguous - they did not specify when W could withdraw their principal, nor did they provide any written commitments, and delayed on the grounds of "risk review" and "technical investigation".

After delaying for a while, BedRock claimed that the unibtc decoupling originated from the large-scale borrowing of unibtc assets on the LayerBank platform and smashing the market. Then BedRock's people suggested that W "hold LayerBank accountable." But W has not received any response for a long time after finding LayerBank.

In desperation, W had to find a friend on Twitter for help. After more than two weeks of work, he finally received an active response from LayerBank and BedRock, and successfully recovered his assets.

W's experience is not an isolated case. According to feedback from other parties, BedRock also used similar means to cut off the user's unibtc exit path last year, resulting in the "substantive freezing" of these unibtcs. Of course, this article does not intend to speculate on the reasons behind the above incidents, and only explains to everyone from a technical level how to avoid and eliminate similar centralized evil behaviors.

First, reviewing the above events, we can see that BedRock, as the issuer of the unibtc and the initial LP of the secondary market liquidity pool, naturally has the authority to exit the unibtc secondary market. If its power is to be restricted, it must be more governed rather than technical means;

However, the fact that Free cross-chain bridge and BedRock conspired to refuse user requests in the previous article exposed that Unibtc had obvious technical flaws in the "issuance-single-chain circulation-multi-chain circulation" link: Free cross-chain bridge, as the BedRock partner, is obviously highly centralized.

The truly Trustless bridge should ensure that the official bridge cannot prevent users from exiting. In the case of Unibtc freezing, both BedRock and Free cross-chain bridges have strong centralized permissions and do not provide a resistant exit channel.

Of course, cases like Unibtc are not uncommon, and cutting off user exit paths is common in major exchanges. For cross-chain bridges or other types of project parties, there are many cases of using centralized permissions. In June 2022, Harmony Horizon Bridge suspended withdrawal channels for 57 assets due to hackers. Although this behavior has "legitimate reasons", it still makes some people feel extremely terrified;

In the StableMagnet incident in 2021, the project party stolen $24 million through pre-reserved program loopholes. In the end, Hong Kong and the UK dispatched a large number of police forces to recover 91% of the stolen money with the assistance of the community. Various cases fully demonstrate that if the asset custody platform cannot provide trust-free services, it will inevitably lead to bad consequences in the end.

However, Trustless is not easy to get. From payment channels and DLC to BitVM and ZK Rollup, people have tried various implementation methods. Although it can greatly protect user autonomy and provide reliable asset evacuation exports, there are still inevitable flaws behind this.

For example, the payment channel requires the parties to monitor the potential malicious behavior of the opponent, and DLC needs to rely on oracles; while BitVM is expensive to use, and there are other trust assumptions in the practice; the escape pole of ZK Rollup needs to be triggered through a long window period, and Rollup needs to be shut down first, which is very expensive.

Judging from the implementation of major technical solutions, there has been no perfect asset custody and exit plans, and the market still needs to innovate. Hereinafter, DeepSafe Research will take the asset custody solution officially launched by DeepSafe as an example to illustrate to everyone a trustless message verification solution combining TEE, ZK and MPC. This solution balances the cost, security, user experience and other indicators that cannot be obtained, and can provide reliable underlying services for trading platforms, cross-chain bridges or any asset custody scenarios.

CRVA: Encrypted random verification network

Currently, the most widely used asset management solutions on the market use multi-signature or MPC/TSS to determine whether the asset transfer request is valid. The advantage of this solution is that it is simple to implement, low cost, and fast message verification. The disadvantages are self-evident - it is not safe enough and tends to be centralized. In the Multichain case in 2023, 21 nodes participating in MPC computing were controlled by one person, which is a typical witch attack. This is enough to prove that the dozens of nodes on the surface cannot provide high decentralization guarantees.

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

Secondly, in order to improve the efficiency of MPC/TSS calculation, CRVA will randomly select nodes through the lottery algorithm, such as drawing 10 nodes every half an hour, and they serve as verifiers to verify whether the user request should be passed, and then generate the corresponding threshold signature for release. In order to prevent internal conspiracy or external hacking, CRVA's lottery algorithm uses original ring VRF, combined with ZK to hide the identity of the person being drawn, so that the outside world cannot directly observe the person being drawn.

Of course, it is not enough to do this level alone. Although the outside world does not know who was selected, the person who was drawn at this time knows it, so there is still a path to conspiracy. In order to further eliminate conspiracy, all nodes of CRVA must run the core code in the TEE hardware environment, which is equivalent to carrying out the core work in a black box. In this way, no one can know whether he has been drawn unless he can crack TEE trusted hardware. Of course, based on current technical conditions, this is extremely difficult to do.

The above mentioned is the basic idea of ​​DeepSafe's CRVA solution. In the actual workflow, a large number of broadcast communications and information exchanges must be carried out between nodes in the CRVA network. The specific process is as follows:

1. Before entering the CRVA network, all nodes must 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 after that, the CRVA network will randomly select several nodes. But before this, all candidates must generate a one-time "temporary public key" locally and generate ZKP at the same time to prove that the "temporary public key" is associated with the "permanent public key" recorded on the chain; in other words, everyone must prove through ZK that they exist on the candidate list, but do not disclose which one they are;

3. The function of "temporary public key" lies in privacy protection. If you draw lots directly from the "permanent public key" collection, when the results are announced, you will directly know who is elected. If you only expose a one-time "temporary public key" and then select a few people from the "temporary public key" set, you know at most that you won the lottery, but you don't know who the other temporary public keys won the lottery corresponds to.

4. In order to further prevent identity leakage, CRVA intends to make yourself unaware of what your "temporary public key" is. The generation process of temporary public keys is completed in the TEE environment of the node. You who run TEE cannot see what is happening inside.

5. Then encrypt the temporary public key plaintext into "garbled code" in TEE and then send it to the outside world. Only specific Relayer nodes can be restored. Of course, the restore process is also completed in the TEE environment of the Relayer node, and Relayer does not know which candidates are corresponding to these temporary public keys.

6. After Relayer restores all "temporary public keys", it collects them uniformly and submits them to the VRF function on the chain, and selects the winners from them. These people verify the transaction request sent by the user's front-end, and then generates a threshold signature based on the verification results, and finally submits it to the chain. (It should be noted that the Relayer here is actually a hidden identity and is regularly selected)

Some people may ask, since each node does not know whether it has been drawn, 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 are released, we will directly broadcast the list. Everyone just passes the list into TEE and check whether they have been selected.

The core of the DeepSafe solution is that almost all important activities are carried out within TEE hardware, and what is happening cannot be observed from outside TEE. Every node does not know who the selected validator is, preventing collusion and greatly increasing the cost of external attacks. To attack the CRVA committee based on DeepSafe, in theory, it is necessary to attack the entire CRVA network. In addition, each node has TEE protection, so the difficulty of attack has increased significantly.

Implementation of asset self-custody schemes combined with CRVA

Above we introduced the general principles of CRVA and explained to you how CRVA can achieve decentralization and trust-free. Below we will take the Bitcoin algorithm stablecoin named HelloBTU as a case to further clarify the application of CRVA in asset custody solutions.

As we all know, since the Bitcoin chain does not have a Turing-complete environment and cannot directly implement complex smart contract logic such as Defi, the mainstream BTCFi bridges Bitcoin to other chains and interacts with smart contracts. The smart contract part of HelloBTU is arranged on Ethereum. Users can deposit BTC into the collection address specified by HelloBTU, and then the latter's official bridge will cross BTC to the Ethereum chain, and then interact with HelloBTU's stable smart contract.

Suppose that the user now wants to pledge 10 BTCs to the HelloBTU platform. The specific operation is to first transfer 10 BTCs to a Taproot address on the Bitcoin chain. The corresponding unlocking requires more than 2/2 signs, one of which is generated by the user and the other signature is generated by CRVA.

Several situations involved here are:

Suppose that after 10 BTCs are transferred to the above Taproot address, the user uses these 10 BTCs to mint stablecoins and now intends to actively redeem BTC. At this time, the user and CRVA each generate a signature, unlock these 10 BTCs and return them to the user address. If CRVA fails to cooperate with users for a long time, after the time lock window expires, the user can unilaterally get these 10 BTCs back. This function is called "User Self-Redeem".

Another situation is that the user's BTC as collateral has been liquidated, and now he should cooperate with CRVA to transfer these BTCs and hand them over to the CRVA one-way channel to control. However, users may refuse to cooperate. At this time, these BTCs are temporarily stuck and no one can take them away. Once the time lock window passes, the money can be transferred by CRVA and enter the Taproot address controlled by CRVA (CRVA one-way channel);

There is a detail here, that is, the time lock for BTC to enter the CRVA unidirectional channel is relatively short, while the time lock for users to redeem themselves is longer. In other words, if CRVA and users cannot cooperate with each other, these BTCs will eventually be given priority to enter the CRVA unidirectional channel. In this way, users' behavior of relying on debts and committing evil deeds can be effectively restricted.

As for the case of CRVA doing evil, since CRVA is an automated node network system, as long as the code at the initial 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 the CRVA causes a large number of nodes to be shut down due to power outages, floods and other force majeure, users still have a way to safely withdraw their assets according to the procedures mentioned in the above plan. The trust assumption here is that we trust CRVA to be decentralized enough and will not take the initiative to act evil (the reason has been fully explained before).

If BTC is transferred to the CRVA one-way channel, it often means that the corresponding on-chain stable position has been liquidated, and the actual ownership of BTC belongs to the liquidator. The liquidator may initiate a withdrawal request, which will be heard by the CRVA. If passed, the CRVA will generate a signature for it and transfer the corresponding amount of BTC to the liquidator.

At this time, if the CRVA fails to respond for a long time, after the time lock expires, these BTCs will be transferred to the address controlled by the DAO. This operation is triggered by multiple signs, and subsequent processing will be solved by DAO governance. This DAO is composed of well-known project parties, security companies and investment institutions, and is established with the purpose of curbing a single entity's evil deeds.

To sum up, we have roughly explained DeepSafe's asset self-custody scheme for Bitcoin, and the principle of ERC-20 assets is similar, so we will not elaborate on it here. For the Unibtc freeze case mentioned in the aforementioned article, if Unibtc cross-chain bridge adopts CRVA's self-custodial solution, it is difficult to have the asset issuer unilaterally control the overall situation.