Original source: DeepSafe Research
On April 23, 2025, a netizen named Brain asked for help on Twitter through a friend, saying that when he was conducting arbitrage operations on a Bitcoin Layer2 chain, more than $100,000 of unibtc assets were trapped by Bedrock officials and could not be withdrawn.
According to the disclosure of party W, on April 17, he found that the price of unibtc issued by Bedrock on a certain Bitcoin L2 chain was abnormal and decoupled from BTC. W believed that the decoupling was temporary and would soon return to the anchor, and there was a good arbitrage opportunity here, so he transferred part of the BTC into the Bitcoin L2, exchanged it for unibtc and sold it after it returned to the anchor.
Within 24 hours after the decoupling, unibtc returned to its anchor, but when W tried to sell his unibtc, he found that the unibtc-BTC liquidity pool on the chain had been removed by Bedrock officials, and this token was the only secondary market exit channel for unibtc on the chain. W was unable to sell his unibtc, so he tried to transfer 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, who explained: "The multi-signature key of the unibtc cross-chain is hosted by Bedrock. Without their permission, users cannot transfer unibtc to other chains."
W had no choice but to find a Bedrock employee to ask about the matter. The employee’s initial response was: “We can allow you to withdraw your principal, but whether you can withdraw the profit generated by arbitrage is still under review.”
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 hands was "temporarily frozen" - there was no way to sell it on this chain, nor could it be transferred to other chains. At this time, he felt very helpless and just wanted to withdraw the principal smoothly.
However, the attitude of BedRock personnel became ambiguous - they neither clearly stated when W could withdraw the principal, nor provided any written commitment, and delayed the process with reasons such as "risk review" and "technical investigation".
After a delay, BedRock claimed that the unibtc decoupling was caused by someone on the LayerBank platform borrowing a large amount of unibtc assets and dumping the market, and then BedRock suggested that W "hold LayerBank accountable". After W found LayerBank, he did not get a response for a long time.
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 and successfully recovered his assets.
W's experience is not an isolated case. According to feedback from other parties involved, BedRock also used similar means to cut off users' unibtc exit paths last year, resulting in these unibtc being "substantially frozen." Of course, this article does not intend to speculate on the reasons behind the above incident, but only explains from a technical perspective how to avoid and eliminate similar centralized evil behaviors.
First, reviewing the above events, we can see that BedRock, as the issuer of unibtc and the initial LP of the secondary market liquidity pool, naturally has the authority to exit the secondary market of unibtc. If its power is to be restricted, it should be more through governance rather than technical means;
However, the collusion between Free Cross-Chain Bridge and BedRock in rejecting user requests mentioned above exposed the obvious technical defects of unibtc in the link of "issuance - single-chain circulation - multi-chain circulation": Free Cross-Chain Bridge, as a partner of BedRock, is obviously highly centralized.
A truly trustless bridge should ensure that the bridge authorities cannot prevent users from exiting. However, in the unibtc freezing case, both BedRock and Free cross-chain bridges have strong centralized authority and do not provide censorship-resistant exit channels.
Of course, cases like Unibtc are not uncommon. Cutting off the user's exit path is common in major exchanges, and for cross-chain bridges or other types of project parties, there are also many cases of using centralized authority. In June 2022, Harmony Horizon Bridge suspended withdrawal channels for 57 assets due to a hacker attack. Although this behavior has "legitimate reasons", it still makes some people feel terrified;
In the StableMagnet incident in 2021, the project owner stole $24 million through a pre-set program loophole. In the end, Hong Kong and the United Kingdom dispatched a large number of police forces and recovered 91% of the stolen money with the help of the community. All these cases fully illustrate that if the asset custody platform cannot provide trustless services, it will inevitably lead to bad consequences.
However, Trustless is not readily available. From payment channels and DLC to BitVM and ZK Rollup, people have tried various implementation methods. Although they can guarantee user autonomy to a great extent and provide a reliable asset withdrawal exit, there are still inevitable flaws behind this.
For example, payment channels require the parties to monitor the potential malicious behavior of the counterparty, and DLC needs to rely on oracles. BitVM is expensive to use, and there are other trust assumptions in practice. ZK Rollup's escape hatch can only be triggered after a long window period, and the Rollup needs to be shut down first, and the cost behind this is huge.
Judging from the current implementation of major technical solutions, there is no perfect asset custody and exit solution, and the market still needs innovation. In the following, DeepSafe Research will take 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 the incompatible indicators 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
At present, the most widely used asset management solutions on the market mostly use multi-signature or MPC/TSS to determine whether the asset transfer request is valid. The advantages of this solution are simple implementation, 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, all 21 nodes participating in the MPC calculation were controlled by one person, which is a typical witch attack. This is enough to prove that a few dozen nodes on the surface alone cannot provide a high degree of decentralization.
In view of 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 not be officially launched until about 500 nodes are reached. According to estimates, the assets pledged by these nodes will be maintained at tens of millions of dollars or more for a long time;
Secondly, in order to improve the efficiency of MPC/TSS calculations, CRVA will randomly select nodes through a lottery algorithm, such as 10 nodes every half an hour, and use them as validators to verify whether the user request should be passed, and then generate the corresponding threshold signature to release it. In order to prevent internal collusion or external hacker attacks, CRVA's lottery algorithm uses an original ring VRF, combined with ZK to hide the identity of the selected person, so that the outside world cannot directly observe the selected person.
Of course, this is not enough. Although the outside world does not know who has been selected, the person who has been selected knows it, so there is still a path for collusion. In order to further prevent collusion, all nodes of CRVA must run the core code in the TEE hardware environment, which is equivalent to putting the core work in a black box. In this way, no one can know whether they have been selected unless they can crack the TEE trusted hardware. Of course, based on current technical conditions, this is extremely difficult to do.
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 a "permanent public key".
2. Every hour, the CRVA network will randomly select several nodes. But before that, all candidates must generate a one-time "temporary public key" locally and 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 that they exist in the candidate list, but do not reveal who they are;
3. The role of "temporary public keys" is to protect privacy. If you draw directly from the "permanent public key" set, when the results are announced, everyone will know who is elected. If everyone only exposes a one-time "temporary public key" and then selects a few people from the "temporary public key" set, you will at most know that you have won the lottery, but you don't know who the other temporary public keys that won the lottery correspond to.
4. To further prevent identity leakage, CRVA intends to make you not know what your "temporary public key" is. The generation process of the temporary public key is completed in the TEE environment of the node, and you who run the TEE cannot see what is happening inside.
5. Then encrypt the temporary public key in plain text into "garbled code" in TEE and send it to the outside world. Only a 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 restores all the "temporary public keys", it collects them together and submits them to the VRF function on the chain, from which the winners are selected. These people verify the transaction request sent by the user's front end, and then generate a threshold signature based on the verification result, and finally submit it to the chain. (It should be noted that the Relayer here is actually also hidden and regularly selected)
Some people may ask, since each node does not know whether it has been selected, 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 come out, we will directly broadcast the list. Everyone only needs to pass the list into TEE and check whether they have been selected.
The core of DeepSafe is that almost all important activities are carried out in TEE hardware, and what is happening cannot be observed from outside TEE. Each node does not know who the selected validators are, which prevents collusion and greatly increases the cost of external attacks. To attack the CRVA committee based on DeepSafe, the entire CRVA network must be attacked in theory. In addition, each node is protected by TEE, which greatly increases the difficulty of attack.
Combined with CRVA's asset self-custody solution
We have introduced the general principles of CRVA above and explained how CRVA can achieve decentralization and trustlessness. Now we will use the Bitcoin algorithmic stablecoin called HelloBTU as an example 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, it is impossible to directly implement complex smart contract logic such as Defi, so the mainstream BTCFi is to bridge Bitcoin to other chains and then interact with smart contracts. The smart contract part of HelloBTU is deployed on Ethereum. Users can deposit BTC into the payment address specified by HelloBTU, and then the official bridge of the latter will cross BTC to the Ethereum chain, and then interact with HelloBTU's stable smart contract.
Suppose a user wants to pledge 10 BTC to the HelloBTU platform. The specific operation is to first transfer the 10 BTC to a Taproot address on the Bitcoin chain. The corresponding unlocking requires 2/2 multi-signature, one of which is generated by the user and the other is generated by CRVA.
There are several situations involved here:
Assume that after 10 BTC are transferred to the above Taproot address, the user mints stablecoins with these 10 BTC and now intends to actively redeem the BTC. At this time, the user and CRVA each generate a signature to unlock the 10 BTC and transfer them back to the user's address. If CRVA does not cooperate with the user for a long time, after the time lock window expires, the user can unilaterally take back the 10 BTC. This function is called "user-initiated redemption".
Another situation is that 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 to the CRVA one-way channel. But the user can refuse to cooperate, and then these BTC are temporarily stuck and no one can take them away; after the time lock window period is over, these funds 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 one-way channel is relatively short, while the time lock for users to redeem it on their own is longer. In other words, if CRVA and users cannot cooperate with each other, these BTC will eventually enter the CRVA one-way channel first. In this way, the behavior of users defaulting on their debts and doing evil can be effectively restricted.
As for the malicious behavior of CRVA, since CRVA is an automatically operated node network system, as long as the code at the initial startup does not contain malicious logic, CRVA will not actively refuse to cooperate with users, so it can basically be ignored;
If CRVA nodes are shut down due to force majeure such as power outages or floods, users can still withdraw their assets safely according to the process mentioned in the above solution. The trust assumption here is that we trust CRVA to be decentralized enough and will not take the initiative to do evil (the reasons have been fully explained above).
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 can initiate a withdrawal request, which will be reviewed by CRVA. If approved, CRVA will generate a signature for it and transfer the corresponding amount of BTC to the liquidator.
At this time, if CRVA does not respond for a long time, after the time lock expires, these BTC will be transferred to the address controlled by the DAO. This operation is triggered by multi-signature, and the subsequent processing is resolved 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 the evil deeds of a single entity.
In summary, we have roughly explained DeepSafe's self-custody solution for Bitcoin assets. For ERC-20 assets, the principle is similar and will not be elaborated here. Regarding the unibtc freezing case mentioned above, if the unibtc cross-chain bridge adopts CRVA's self-custody solution, it is difficult for the asset issuer to unilaterally control the overall situation.
