Over $100,000 locked up: The importance of trustless custody highlighted by the unibtc freeze incident

Author: DeepSafe Research

On April 23, 2025, a netizen named Brain sought help on Twitter through a friend, claiming that over $100,000 worth of unibtc assets were trapped and could not be withdrawn on a certain Bitcoin Layer 2 chain during an arbitrage operation.

According to the disclosure from the involved party W, on April 17, he discovered that unibtc, issued by Bedrock, had an abnormal price on a certain Bitcoin L2 chain and was decoupled from BTC. W believed the decoupling was temporary and would soon re-peg, seeing a good arbitrage opportunity. He then transferred some BTC to the Bitcoin L2 chain, exchanged it for unibtc, and planned to sell it after it re-pegged.

Within just 24 hours after the decoupling, unibtc had re-pegged. However, when W attempted to sell his unibtc, he found that the unibtc-BTC liquidity pool on the chain had been removed by Bedrock officials, and this token pair was the only exit channel for unibtc on the secondary market of that chain. Unable to sell his unibtc, W tried to bridge it to other chains.

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

With no other options, W had to reach out to Bedrock personnel to inquire about the matter. The initial response was: "We can allow you to withdraw your principal, but whether you can withdraw the profits from your arbitrage will need to be reviewed."

At this point, W realized that the exit path for unibtc on this chain had been completely cut off, and the unibtc worth about $200,000 in his possession was "temporarily frozen"—he could neither sell it on that chain nor bridge it to other chains. He felt very helpless at this moment, only hoping to smoothly withdraw his principal.

However, the attitude of Bedrock personnel became ambiguous—they neither clearly stated when W could withdraw his principal nor provided any written commitment, delaying the process with reasons such as "risk review" and "technical inspection."

After some delays, Bedrock claimed that the decoupling of unibtc was due to someone on the LayerBank platform borrowing unibtc assets on a large scale and then dumping them, and Bedrock's personnel suggested W "hold LayerBank accountable." However, W did not receive a response from LayerBank for a long time.

In desperation, W had to seek help from friends on Twitter. After more than two weeks of negotiations, he finally received a positive response from both LayerBank and Bedrock officials, successfully retrieving his assets.

W's experience is not an isolated case. According to feedback from other parties involved, last year Bedrock also used similar methods 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 underlying reasons for the aforementioned events, but rather to explain how to avoid and eliminate similar centralized malicious behaviors from a technical perspective.

First, reviewing the aforementioned incident, we can see that Bedrock, as the issuer of unibtc and the initial LP of the secondary market liquidity pool, inherently possesses the authority over the exit channel for unibtc in the secondary market. If there is a need to restrict this power, it should be done more through governance rather than technical means.

However, the collusion between the Free cross-chain bridge and Bedrock to refuse user requests exposes a significant technical flaw in the "issuance—single-chain circulation—multi-chain circulation" process of unibtc: the Free cross-chain bridge, as a partner of Bedrock, is evidently highly centralized.

A truly trustless bridge should ensure that the bridge officials cannot obstruct users' exits, but in the unibtc freezing case, both Bedrock and the Free cross-chain bridge wielded strong centralized authority and did 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 for cross-chain bridges or other types of project parties, there are also numerous instances of utilizing centralized authority. In June 2022, the Harmony Horizon Bridge suspended withdrawal channels for 57 assets due to a hacker attack. Although this action had "justifiable reasons," it still left some feeling deeply unsettled.

In the 2021 StableMagnet incident, the project party exploited a pre-reserved programming vulnerability to steal $24 million, and ultimately, a large number of police forces from Hong Kong and the UK were deployed to recover 91% of the stolen funds with community assistance. These cases fully illustrate that if asset custody platforms cannot provide trustless services, it will inevitably lead to dire consequences.

However, trustlessness is not easily attainable. From payment channels and DLC to BitVM and ZK Rollup, various implementation methods have been attempted. While they can largely ensure user autonomy and provide reliable asset withdrawal exits, there are still unavoidable flaws behind them.

For instance, payment channels require parties to monitor potential malicious behavior from their counterparts, DLC relies on oracles; BitVM incurs high costs and has other trust assumptions in practical applications; and ZK Rollup's escape hatch requires a long window period to trigger and necessitates shutting down the Rollup first, which comes with significant costs.

From the current implementation status of various technical solutions, there has not yet been a perfect asset custody and exit solution, and the market still needs innovation. In the following text, DeepSafe Research will use the asset custody solution launched by DeepSafe as an example to explain a trustless message verification scheme that combines TEE and ZK, MPC. This solution balances the trade-offs among cost, security, and user experience, providing 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 mostly adopt multi-signature or MPC/TSS methods to determine the validity of asset transfer requests. The advantage of this solution lies in its simple implementation, low cost, and fast message verification speed, but the downsides are obvious—it's not secure enough and tends to be centralized. In the 2023 Multichain incident, all 21 nodes participating in the MPC computation were controlled by one person, which is a typical witch attack. This incident is sufficient to prove that merely having dozens of nodes on the surface does not provide a high level of decentralization assurance.

To address 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 admission model, and the mainnet will only officially launch after reaching about 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, to improve the efficiency of MPC/TSS calculations, CRVA will randomly select nodes using a lottery algorithm, such as selecting 10 nodes every half hour to act as validators, verifying whether user requests should be approved, and then generating corresponding threshold signatures for release. To prevent internal collusion or external hacker attacks, CRVA's lottery algorithm employs an original ring VRF, combined with ZK to hide the identities of the selected individuals, making it impossible for outsiders to directly observe who has been selected.

Of course, achieving this level is not enough; although outsiders do not know who has been selected, the selected individuals themselves do know, so there is still a path for collusion. To further eliminate collusion, all nodes in CRVA must run the core code in a TEE hardware environment, effectively placing the core work in a black box. This way, no one can know whether they have been selected unless they can break the TEE trusted hardware, which is extremely difficult to achieve under current technological conditions.

The above describes the basic idea of DeepSafe's CRVA solution. In the actual workflow, there will be a significant amount of broadcast communication and information exchange among nodes in the CRVA network, and the specific process is as follows:

1. All nodes must first stake assets on-chain before entering the CRVA network, leaving a public key as registration information. 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 on-chain recorded "permanent public key"; in other words, everyone must use ZK to prove their presence on the candidate list without revealing who they are.

3. The purpose of the "temporary public key" is privacy protection. If the lottery is conducted directly from the "permanent public key" set, when the results are announced, everyone will directly know who has been selected. If everyone only exposes their one-time "temporary public key" and then selects a few from the "temporary public key" set, you will at most know that you have won but not who the other winning temporary public keys correspond to.

4. To further prevent identity leakage, CRVA intends to ensure that you do not even know what your "temporary public key" is. The generation process of the temporary public key is completed within the TEE environment of the node, and those running the TEE cannot see what happens inside.

5. Then, the temporary public key is encrypted into "garbled text" within the TEE before being sent to the outside world, and only specific Relayer nodes can restore it. Of course, the restoration process also takes place in the TEE environment of the Relayer node, and the Relayer does not know which temporary public keys correspond to which candidates.

6. After the Relayer restores all "temporary public keys," it aggregates them and submits them to the on-chain VRF function to select the winners, who will then verify the transaction requests sent from the user front end, generate threshold signatures based on the verification results, and finally submit them on-chain. (It should be noted that the Relayer here is also hidden in identity 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, each person will generate a "temporary public key" in their local TEE environment. After the lottery results are announced, we directly broadcast the list, and everyone just needs to input the list into the TEE to check whether they have been selected.

The core of DeepSafe's solution lies in that almost all important activities occur within the TEE hardware, making it impossible to observe what happens 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 DeepSafe-based CRVA committee, one would theoretically need to attack the entire CRVA network, and since each node is protected by TEE, the difficulty of the attack increases significantly.

Implementing Asset Self-Custody Solutions with CRVA

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

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, mainstream BTCFi bridges Bitcoin to other chains for interaction with smart contracts. The smart contract portion of HelloBTU is deployed on Ethereum, allowing users to deposit BTC into a designated receiving address of HelloBTU, which is then bridged to the Ethereum chain by the official bridge and interacts with HelloBTU's stablecoin smart contract.

Suppose a user wants to stake 10 BTC on the HelloBTU platform. The specific operation is to first transfer the 10 BTC to a Taproot address on the Bitcoin chain, which requires a 2/2 multi-signature to unlock, with one signature generated by the user and the other by CRVA.

Several scenarios are involved here:

Suppose after the 10 BTC are transferred to the aforementioned Taproot address, the user mints stablecoins with these 10 BTC and now intends to 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 reclaim these 10 BTC, a feature known as "user self-redemption."

Another scenario is that the BTC used as collateral is liquidated. The user should cooperate with CRVA to transfer these BTC and hand them over to CRVA's one-way channel for control. However, the user can refuse to cooperate, and at this point, these BTC will be temporarily stuck, and no one can take them; once the time lock window expires, these funds can be transferred by CRVA to a Taproot address controlled by CRVA (CRVA one-way channel).

A detail here is that the time lock for BTC entering the CRVA one-way channel is relatively short, while the time lock for user self-redemption is longer. In other words, if CRVA and the user cannot cooperate with each other, these BTC will ultimately enter the CRVA one-way channel first. This way, the user's malicious behavior of defaulting can be effectively restricted.

As for the situation where CRVA acts maliciously, since CRVA is an automated node network system, as long as the initial code does not contain malicious logic, there will be no situation where CRVA actively refuses to cooperate with the user, so this can be largely ignored.

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

At this point, if CRVA does not respond for a long time, once 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 to curb the malicious actions of a single entity.

In summary, we have provided a general explanation of DeepSafe's asset self-custody solution for Bitcoin, and for ERC-20 assets, the principle is similar and will not be elaborated here. Regarding the unibtc freezing case mentioned earlier, if the unibtc cross-chain bridge had adopted CRVA's self-custody solution, it would have been difficult for the asset issuer to unilaterally control the situation.