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 had been trapped and could not be withdrawn while he was conducting arbitrage operations on a certain Bitcoin Layer 2 chain.
According to W's disclosure, on April 17, he discovered that the unibtc issued by Bedrock had abnormal prices on a certain Bitcoin L2 chain and had decoupled from BTC. W believed that the decoupling was temporary and would soon re-peg, presenting a good arbitrage opportunity. He then transferred some BTC to this Bitcoin L2, exchanged it for unibtc, and waited to sell it after it was re-pegged.
Only 24 hours after decoupling, unibtc was re-pegged, but when W tried to sell the unibtc in his possession, he found that the unibtc-BTC liquidity pool on that chain had been removed by Bedrock, and this token pair was the only exit channel for unibtc on that chain. Unable to sell the unibtc in his possession, W attempted to transfer it to other chains.
When he found the only cross-chain bridge supporting unibtc on that chain (named Free), he received a prompt—'The transaction requires project party signature authorization.' W contacted the customer service of the Free cross-chain bridge, 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 could only find Bedrock related personnel to inquire about this matter. The initial response was: 'We can allow you to withdraw your principal, but whether you can withdraw the profits generated from 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 U in his hands was 'temporarily frozen'—unable to be sold on this chain or transferred to other chains. He felt very helpless at this time, only hoping to smoothly withdraw his principal.
However, the attitude of BedRock related personnel became ambiguous—they neither clearly stated when W could withdraw his principal nor provided any written commitment, delaying under the pretext of 'risk review' and 'technical inspection'.
After a delay, BedRock claimed that the unibtc decoupling was caused by someone on the LayerBank platform borrowing unibtc assets on a large scale and dumping them. Then BedRock's people suggested to W to 'hold LayerBank accountable'. However, W did not receive a response for a long time after contacting LayerBank.
In desperation, W could only 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. Feedback from other parties indicates that 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 events but aims to explain from a technical perspective how similar centralized malfeasance can be avoided and eliminated.
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 has the authority to exit the unibtc secondary market. If restrictions on its power are to be imposed, it should be done more through governance than technical means.
However, the earlier collaboration between the Free cross-chain bridge and BedRock to refuse user requests exposed 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 evidently highly centralized.
A truly trustless bridge should ensure that the bridge's officials cannot obstruct users' exits. However, in the unibtc freezing case, both BedRock and the Free cross-chain bridge possess strong centralized authority and do not provide censorship-resistant exit channels.
Of course, cases similar to unibtc are not uncommon. The act of cutting off users' exit paths is frequently seen among major exchanges, and for cross-chain bridges or other types of project parties, there are also numerous cases of exercising centralized authority. In June 2022, the Harmony Horizon Bridge suspended the withdrawal channels for 57 assets due to a hacker attack. Although this behavior had 'justifiable reasons', it still made some people feel uneasy.
In the 2021 StableMagnet incident, the project party exploited a pre-reserved program loophole to embezzle $24 million. In the end, a large number of police were dispatched from Hong Kong and the UK, and with the community's assistance, 91% of the stolen funds were recovered. Various cases fully illustrate that if asset custody platforms cannot provide trustless services, it will ultimately lead to disastrous consequences.
However, trustlessness is not easily achievable. From payment channels and DLCs to BitVM and ZK Rollup, people have tried various implementation methods. Although these can largely guarantee user autonomy and provide reliable asset exit channels, there are still unavoidable flaws behind them.
For example, payment channels require parties to monitor the potential malicious actions of their counterparts, DLCs rely on oracles; BitVM has high costs and other trust assumptions in practice; the escape hatch of ZK Rollup requires a lengthy window period to trigger and needs to stop the Rollup first, which comes with significant costs.
From the current implementation status of various technical solutions, there has yet to be a perfect asset custody and exit solution, and the market still needs to innovate. In the following text, DeepSafe Research will take the asset custody solution officially launched by DeepSafe as an example to explain a trustless message verification scheme combining TEE, ZK, and MPC, which balances indicators such as cost, security, and user experience that cannot be simultaneously achieved, providing reliable underlying services for trading platforms, cross-chain bridges, or any asset custody scenarios.
CRVA: Cryptographic Random Verification Network
The most widely used asset management solutions on the market mostly use multi-signature or MPC/TSS methods to determine whether asset transfer requests are valid. The advantage of this solution lies in its simplicity, low cost, and fast message verification speed; the downside is self-evident—it's not secure enough and often tends toward centralization. In the 2023 Multichain case, the 21 nodes participating in the MPC computation were all controlled by one person, which is a typical witch attack. This incident is enough to prove that simply 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 admission model, and the mainnet will only be officially launched after reaching around 500 nodes. It is estimated that the assets staked by these nodes will remain at tens of millions of dollars or more in the long term.
Secondly, to improve the efficiency of MPC/TSS calculations, CRVA will randomly select nodes through a lottery algorithm, such as selecting 10 nodes every half hour, which will act as verifiers to determine whether user requests should be approved, and then generate 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 identity of those selected, making it impossible for the outside world to directly observe the selected individuals.
Of course, achieving this level is not enough. Although the outside world does not know who has been selected, at this time, the selected individuals themselves know, so there are still paths for collusion. To further eliminate collusion, all nodes of CRVA must run the core code in a TEE hardware environment, effectively placing core work inside a black box. This way, no one can know if they have been selected unless they can crack the TEE trusted hardware, which, given current technological conditions, is very difficult to achieve.
What has been discussed above is the basic idea of DeepSafe's CRVA solution. In the actual workflow, a large amount of broadcast communication and information exchange must occur between the nodes within the CRVA network, and the specific process is as follows:
1. Before all nodes enter the CRVA network, they must first stake assets on the chain, leaving a public key as registration information. This public key is also known as the 'permanent public key.'
2. Every hour, the CRVA network randomly selects several nodes. However, before this, all candidates must generate a one-time 'temporary public key' locally and also generate ZKP to prove that the 'temporary public key' is associated with the 'permanent public key' recorded on the chain; in other words, everyone has to prove their existence on the candidate list through ZK without revealing who they are.
3. The role of the 'temporary public key' is privacy protection. If the lottery is directly drawn from the collection of 'permanent public keys', everyone would know who was elected when the results are announced. If everyone only exposes a one-time 'temporary public key', and then selects a few people from the collection of 'temporary public keys', you will at most know that you are selected but not know who the other selected temporary public keys correspond to.
4. To further prevent identity disclosure, 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 nodes, and you operating the TEE cannot see what happens inside.
5. Then, the plaintext of the temporary public key is encrypted into 'gibberish' within the TEE and sent to the outside world, where only specific Relayer nodes can restore it. Of course, the restoration process also takes place within the TEE environment of the Relayer node, and the Relayer does not know which candidates correspond to these temporary public keys.
6. After the Relayer restores all 'temporary public keys', they are collectively gathered and submitted to the VRF function on the chain, which randomly selects the winners. These individuals then verify the transaction requests sent by the user front-end, and based on the verification results, generate threshold signatures, which are then 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 continue? In fact, as mentioned earlier, everyone will generate a 'temporary public key' within the local TEE environment. After the lottery results come out, we simply broadcast the list, and everyone just needs to input the list into the TEE to check whether they have been selected.
The core of the DeepSafe solution is 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 CRVA committee based on DeepSafe, theoretically, one would need to attack the entire CRVA network, and since each node is protected by TEE, the difficulty of the attack increases significantly.
Achieving self-custody of assets in conjunction with the CRVA solution
Above, we introduced the general principles of CRVA, clarifying how CRVA achieves decentralized trustlessness. Next, we will take a Bitcoin algorithmic stablecoin called HelloBTU as a case study to further clarify how CRVA is applied in asset custody solutions.
As is well known, due to the lack of a Turing-complete environment on the Bitcoin chain, it is impossible to directly implement complex smart contract logic such as DeFi, so mainstream BTCFi bridges Bitcoin to other chains for interaction with smart contracts. The smart contract part of HelloBTU is deployed on Ethereum, where users can deposit BTC into a designated receiving address provided by HelloBTU, and then the official bridge will transfer the BTC to the Ethereum chain, allowing interaction with HelloBTU's stable algorithmic smart contract.
Assuming now that a 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 chain, where the corresponding unlocking requires a 2/2 multi-signature, one signature generated by the user and the other by CRVA.
The cases involved here include several situations:
Assuming after 10 BTC is transferred to the aforementioned Taproot address, the user mints stablecoins with these 10 BTC and now intends to redeem the BTC actively. At this point, the user and CRVA will each 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 autonomous redemption.'
Another situation is that the BTC used by the user as collateral has been liquidated, and now he should cooperate with CRVA to transfer these BTC to be controlled by the CRVA unidirectional channel. However, the user can refuse to cooperate, and at this time, these BTC will be temporarily stuck, and no one can take them; once the time lock window period passes, these funds can be transferred away by CRVA to a Taproot address controlled by CRVA (CRVA unidirectional channel).
There is a detail here: the time lock for BTC entering the CRVA unidirectional channel is relatively short, while the time lock for users to autonomously redeem is longer. In other words, if CRVA and the user cannot cooperate with each other, these BTC will ultimately prioritize entering the CRVA unidirectional channel. This way, the user's potential malfeasance can be effectively restricted.
As for the situation where CRVA misbehaves, since CRVA is an automated node network system, as long as the initial code at 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 large-scale node downtime due to force majeure such as power outages or floods, according to the process mentioned above, users still have a way to safely withdraw their assets. The trust assumption here is that we trust CRVA to be sufficiently decentralized and will not actively commit malfeasance (as explained earlier).
If BTC is transferred into the CRVA unidirectional channel, it often indicates that the corresponding on-chain stable position has been liquidated, and at this time, the actual ownership of the 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 them 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 an address controlled by the DAO. This operation is triggered by multi-signature, and subsequent processing will be resolved by DAO governance, which is composed of well-known project parties, security companies, and investment institutions, established with the aim of curbing the malfeasance of a single entity.
In summary, we have roughly explained DeepSafe's asset self-custody solution for Bitcoin, and for ERC-20 assets, its principle is similar, so we will not elaborate further. Regarding the unibtc freezing case mentioned earlier, if the unibtc cross-chain bridge adopts the CRVA self-custody solution, it will be difficult for the asset issuer to unilaterally control the situation.
