Over $100,000 locked, highlighting the importance of trustless custody from the unibtc freeze incident.

Original author: Xianrang GodRealmX

On April 23, 2025, a netizen named Brain sought help on Twitter through a friend, stating that over $100,000 worth of unibtc assets were trapped by the Bedrock official and could not be withdrawn while he was conducting arbitrage operations on a certain Bitcoin Layer 2 chain.

According to the disclosure by party W, on April 17, he discovered that unibtc issued by Bedrock showed price anomalies on a certain Bitcoin L2 chain and decoupled from BTC. W believes that the decoupling is temporary and will soon re-peg, presenting a good arbitrage opportunity. He then transferred some BTC to this Bitcoin L2, exchanged it for unibtc, and planned to sell it after it re-pegged.

Only 24 hours after the decoupling, unibtc had been re-pegged, but when W tried to sell the unibtc in hand, they found that the unibtc-BTC liquidity pool on that chain had been removed by the Bedrock team, and this token was the only exit channel for unibtc in the secondary market on that chain. Unable to sell the unibtc in hand, W attempted to bridge the unibtc to other chains.

When he found the only cross-chain bridge on the chain that supports unibtc (named Free), he received a prompt stating, "Transaction requires project party signature authorization." W contacted the customer service of the Free cross-chain bridge, and they explained: "The multi-signature key for unibtc cross-chain is hosted by Bedrock, and without their permission, users cannot transfer unibtc to other chains."

There’s no way around it; W can only find the relevant personnel at Bedrock to inquire about this matter. The initial response from the other party is: "We can allow you to withdraw the principal, but whether the profits generated from your arbitrage can be withdrawn will need to be reviewed first."

At this point, W realized that the exit path for unibtc on this chain had been completely severed, and the unibtc worth about 200,000 U in his hands was "temporarily frozen"—he couldn't sell it on this chain, nor could he transfer it to another chain. At this moment, he felt very helpless, just hoping to smoothly withdraw his principal.

However, the attitude of the personnel related to BedRock has become ambiguous—neither clearly stating when W can withdraw the principal nor providing any written commitments, delaying under the pretext of "risk review" and "technical inspection."

After a period of procrastination, BedRock claimed that the decoupling of unibtc originated from someone on the LayerBank platform borrowing unibtc assets on a large scale and then dumping them. Subsequently, BedRock's people suggested that W "hold LayerBank accountable." However, W did not receive a response for a long time after contacting LayerBank.

In desperation, W had to find friends on Twitter for help. After more than two weeks of negotiations, he finally received a positive response from LayerBank and BedRock officials, successfully recovering the assets.

W's experience is not an isolated case. According to feedback from other parties, last year BedRock also used similar means to cut off users' exit paths for unibtc, resulting in these unibtc being "substantially frozen." Of course, this article does not intend to speculate on the reasons behind the aforementioned incident, but rather to explain from a technical perspective how to avoid and eliminate similar centralized malicious behaviors.

First, reviewing the aforementioned events, we can see that BedRock, as the issuer of unibtc and the initial LP of the secondary market liquidity pool, inherently possesses the authority to exit the unibtc secondary market. If we want to limit its power, it should be done more through governance rather than technical means.

However, the previous mention of the Free Cross-Chain Bridge colluding with BedRock to reject user requests exposes the obvious technical flaws in unibtc's "issuance - single-chain circulation - multi-chain circulation" process: the Free Cross-Chain Bridge, as a partner of BedRock, is clearly highly centralized.

A truly trustless bridge should ensure that the official cannot prevent users from exiting. However, in the unibtc freezing case, both BedRock and Free cross-chain bridges hold strong centralized powers and do not provide a censorship-resistant exit channel.

Of course, cases similar to unibtc are not uncommon; cutting off users' exit paths is frequently seen across major exchanges, and there are also many instances for cross-chain bridges or other types of project parties that involve the use of centralized authority. In June 2022, the Harmony Horizon Bridge suspended the withdrawal channels for 57 assets due to a hacking attack. Although this action had "justifiable reasons," it still left some people feeling deeply uneasy.

In the StableMagnet incident of 2021, the project team embezzled $24 million through a pre-reserved program vulnerability. Eventually, a large number of police forces from Hong Kong and the UK were deployed to recover 91% of the stolen funds with the assistance of the community. Various cases fully demonstrate that if asset custody platforms cannot provide trustless services, it will inevitably lead to disastrous consequences.

However, trustless systems are not easily attainable. From payment channels and DLCs to BitVM and ZK Rollups, various implementation methods have been attempted. While these can greatly ensure user autonomy and provide reliable asset withdrawal options, there are still unavoidable flaws behind them.

For example, payment channels require parties to monitor the potential malicious behavior of the counterparty, DLC relies on oracles; while BitVM is costly and has other trust assumptions in practical implementation; ZK Rollup's escape hatch requires a long window period to trigger and needs to stop the Rollup first, which comes at a significant cost.

From the current implementation of major technical solutions, there has yet to be a perfect asset custody and exit solution; the market still requires innovation. In the following text, DeepSafe Research will use the asset custody solution officially launched by DeepSafe as an example to explain a trustless message verification solution that combines TEE, ZK, and MPC. This solution balances indicators that cannot be simultaneously achieved, such as cost, security, and user experience, and can provide reliable underlying services for trading platforms, cross-chain bridges, or any asset custody scenarios.

CRVA: Cryptographic Random Verification Network

Currently, the most widely used asset management solutions on the market mainly use multi-signature or MPC/TSS methods to determine whether asset transfer requests are valid. The advantages of such solutions lie in their simple implementation, low cost, and fast message verification speed, while the disadvantages are self-evident—insufficient security and a tendency to centralization. In the 2023 Multichain case, all 21 nodes participating in the MPC computation were controlled by a single individual, which is a typical witch attack. This incident is enough to prove that merely having dozens of nodes on the surface does not provide a high level of decentralization assurance.

In response to the shortcomings of traditional MPC/TSS asset management solutions, DeepSafe's CRVA solution has made significant improvements. First, the CRVA network nodes adopt an asset staking access model, and the mainnet will officially launch only after reaching approximately 500 nodes. It is estimated that the assets staked by these nodes will be maintained at tens of millions of dollars or higher in the long term.

Secondly, in order to improve the efficiency of MPC/TSS calculations, CRVA will randomly select nodes through a lottery algorithm, for example, drawing 10 nodes every half hour, which will act as validators to verify whether user requests should be approved, and then generate the corresponding threshold signatures for release. To prevent internal collusion or external hacker attacks, CRVA's lottery algorithm uses an original ring VRF, combined with ZK to conceal the identities of those selected, making it impossible for outsiders to directly observe the selected individuals.

Of course, just reaching this level is not enough. Although the outside world does not know who has been selected, the person who has been drawn 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 within a TEE hardware environment, which is equivalent to conducting core work inside a black box. In this way, no one can know whether they have been selected unless they can break the TEE trusted hardware, which, of course, is very difficult to achieve given the current technological conditions.

The above discusses the basic idea of DeepSafe's CRVA solution. In the actual workflow, there needs to be a large amount of broadcast communication and information exchange between 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 several 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 draw is conducted directly from the set of "permanent public keys," the results will reveal to everyone who has been elected. However, if only the one-time "temporary public keys" are exposed, and then a few individuals are selected from the set of "temporary public keys," you will only know that you have won, but you won’t know who the other winners are corresponding to their temporary public keys.

4. In order to further prevent identity leakage, CRVA intends to make you unaware of 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, within the TEE, the plaintext of the temporary public key is encrypted into "garbled text" and sent to the outside world, where only specific Relayer nodes can restore it. Of course, the restoration process is also completed within the TEE environment of the Relayer nodes, 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 on-chain VRF function, from which winners are drawn. These individuals then validate the transaction requests sent from the user's front end, and based on the validation results, generate a threshold signature, which is finally submitted to the chain. (It should be noted that the Relayer here is also anonymous 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, and everyone just needs to input the list into the TEE to check if they have been selected.

The core of the DeepSafe solution is that almost all important activities take place within the TEE hardware, making it impossible to observe what is happening 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 theoretically requires attacking the entire CRVA network, and with each node having TEE protection, the difficulty of the attack increases significantly.

Implement asset self-custody solutions in conjunction with CRVA.

Above, we introduced the general principles of CRVA and clarified how CRVA achieves decentralized trustlessness. Next, we will use a case study of a Bitcoin algorithm stablecoin named HelloBTU to further clarify the application of CRVA in asset custody solutions.

As is well known, due to the lack of a Turing-complete environment on the Bitcoin chain, complex smart contract logic such as DeFi cannot be directly implemented. Therefore, the mainstream BTCFi bridges Bitcoin to other chains to interact with smart contracts. The smart contract part of HelloBTU is deployed on Ethereum, where users can deposit BTC into the designated receiving address of HelloBTU, which is then bridged to the Ethereum chain by the official bridge of HelloBTU, allowing interaction with HelloBTU's stable smart contract.

Assuming the user wants to stake 10 BTC on the HelloBTU platform, the specific operation is to first transfer 10 BTC to a Taproot address on the Bitcoin blockchain, with the corresponding unlocking requiring a 2/2 multi-signature, where one signature is generated by the user and the other signature is generated by CRVA.

The situations involved here are:

Assuming 10 BTC are transferred to the aforementioned Taproot address, the user has minted stablecoins using these 10 BTC and now intends to actively redeem the BTC. At this point, both the user and CRVA generate a signature to unlock these 10 BTC and transfer them back to the user's address. If CRVA does not cooperate with the user for a long time, once the time lock window expires, the user can unilaterally retrieve these 10 BTC. This feature is called "user autonomous redemption."

In another scenario, the user's BTC used as collateral has been liquidated, and now he should cooperate with CRVA to transfer these BTC and hand them over for control by the CRVA unidirectional channel. However, the user can refuse to cooperate, in which case these BTC are temporarily stuck and cannot be taken by anyone; once the time lock window period passes, this money can be transferred by CRVA to the Taproot address controlled by CRVA under (CRVA unidirectional channel );

There is a detail here, which is that the time lock for BTC entering the CRVA one-way channel is relatively short, while the time lock for user-initiated redemption is longer. In other words, if there is no cooperation between the CRVA and the users, these BTC will ultimately prioritize entering the CRVA one-way channel. This way, the users' acts of defaulting can be effectively restricted.

Regarding the situation where CRVA commits malicious acts, since CRVA is an automated node network system, as long as the code in its 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 CRVA experiences a large number of node shutdowns due to force majeure events such as power outages or floods, users still have a way to securely withdraw their assets according to the procedures mentioned in the above plan. The trust assumption here is that we trust CRVA to be sufficiently decentralized and not to act maliciously (as explained in detail earlier).

If BTC is transferred into the CRVA one-way channel, it often indicates that the corresponding on-chain stable position has been liquidated, at which point the actual ownership of BTC belongs to the liquidator. The liquidator can initiate a withdrawal request, which will be reviewed by CRVA. If approved, CRVA will generate a signature for the liquidator and transfer the corresponding amount of BTC to them.

At this point, if CRVA has not responded for a long time, after the time lock expires, these BTC will be transferred to an address controlled by the DAO. This operation is triggered by multi-signature, and the subsequent handling will be resolved by DAO governance. This DAO is composed of well-known project parties, security companies, and investment institutions, established with the purpose of preventing a single entity from committing malicious acts.

In summary, we have provided a general explanation of DeepSafe's self-custody solution for Bitcoin. As for ERC-20 assets, the principles are similar, and we will not elaborate further on that. Regarding the unibtc freezing case mentioned earlier, if the unibtc cross-chain bridge adopts the CRVA self-custody solution, it would be difficult for the asset issuer to unilaterally control the situation.