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 by the Bedrock officials and could not be withdrawn while he was arbitraging on a certain Bitcoin Layer 2 chain.
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 that the decoupling was temporary and would soon re-anchor, presenting a good arbitrage opportunity. He then transferred some BTC to the Bitcoin L2, exchanged it for unibtc, and planned to sell it after it re-anchored.
Within just 24 hours after the decoupling, unibtc had re-anchored. However, when W attempted to sell his unibtc, he found that the unibtc-BTC liquidity pool on that chain had been removed by the 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 stating, "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 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 U he held was "temporarily frozen"—he could neither sell it on that chain nor transfer it to other chains. He felt very helpless at this moment, only hoping to smoothly withdraw his principal.
However, the attitude of the 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 borrowing unibtc assets on the LayerBank platform in large quantities and then dumping them, and Bedrock's personnel suggested 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 positive responses from both LayerBank and Bedrock officials and successfully retrieved 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 aims 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 case of unibtc freezing, both Bedrock and the Free cross-chain bridge hold strong centralized powers and do not provide an anti-censorship 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 powers. 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 people 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 various cases fully illustrate that if asset custody platforms cannot provide trustless services, it will inevitably lead to adverse consequences.
However, trustlessness is not easily attainable. From payment channels and DLC to BitVM and ZK Rollup, people have attempted various implementation methods. While these can significantly safeguard 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 behaviors of their counterparts, DLC relies on oracles; BitVM has high usage costs and involves other trust assumptions in practical applications; and ZK Rollup's escape hatch requires a long window period to trigger and necessitates halting the Rollup first, which comes with substantial costs.
From the current implementation status of various technical solutions, there has not yet emerged 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 solution that combines TEE and ZK, MPC. This solution balances the indicators of 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 in 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 drawbacks are evident—it is not secure enough and often tends toward centralization. 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.
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 officially launch after reaching about 500 nodes. It is estimated that the assets staked by these nodes will remain at tens of millions of dollars or higher for the long term.
Secondly, to improve the efficiency of MPC/TSS calculations, CRVA will randomly select nodes through a lottery algorithm, for example, selecting 10 nodes every half hour to act as validators to verify 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 circular VRF combined with ZK to hide the identities of the selected individuals, making it impossible for the outside world to directly observe who has been selected.
Of course, achieving this level is not enough. Although the outside world does 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. As a result, no one can know whether they have been selected unless they can break the TEE trusted hardware, which is extremely difficult to achieve given 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 the nodes within the CRVA network, and the specific process is as follows:
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."
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-chain; in other words, everyone must use ZK to prove their existence on the candidate list without revealing who they are.
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 elected. If everyone only exposes the 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 but not know who the other winning temporary public keys correspond to.
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 you running the TEE cannot see what happens inside.
Then, the temporary public key is encrypted into "garbled text" 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 nodes, and the Relayer does not know which temporary public keys correspond to which candidates.
After the Relayer restores all "temporary public keys," they are collectively gathered and submitted to the VRF function on-chain, which selects the winners. These individuals then verify the transaction requests sent from the user front end and generate threshold signatures based on the verification results, which are finally submitted to the chain. (It is important to note that the Relayer here is also hidden in identity and selected periodically.)
Some may wonder, since each node does not know whether it has been selected, how does the work proceed? As mentioned earlier, each person generates 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 whether they have been selected.
The core of DeepSafe's solution lies in the fact 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.
Implementation of Asset Self-Custody Solution Combined with CRVA
We have introduced the general principles of CRVA and clarified how CRVA achieves decentralized trustlessness. Next, we will use a Bitcoin algorithm stablecoin called HelloBTU as a case study 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, 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. The official bridge then transfers the BTC to the Ethereum chain, where it interacts with HelloBTU's algorithmic stablecoin smart contract.
Assuming 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 for unlocking, with one signature generated by the user and the other by CRVA.
Several scenarios are involved here:
Assuming that 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 for control via a one-way channel. However, the user can refuse to cooperate, causing these BTC to 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, these BTC will ultimately enter the CRVA one-way channel first. This way, the user's potential malicious behavior 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 CRVA experiences a large number of node outages due to power outages, floods, or other force majeure events, users still have a way to safely withdraw their assets according to the processes mentioned above. The trust assumption here is that we trust CRVA to be sufficiently decentralized and will not act maliciously (as previously explained).
If BTC is transferred to the CRVA one-way channel, it often indicates that the corresponding on-chain stable position has been liquidated, and at this point, 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 subsequent processing 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 roughly outlined DeepSafe's asset self-custody solution for Bitcoin, and for ERC-20 assets, the principle is similar, so we will not elaborate further. Regarding the unibtc freezing case mentioned earlier, if the unibtc cross-chain bridge adopted CRVA's self-custody solution, it would be difficult for the asset issuer to unilaterally control the situation.
免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。
