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 Bedrock officials and could not be withdrawn during an arbitrage operation on a certain Bitcoin Layer2 chain. This article is based on a piece by DeepSafe Research, reorganized by PANews.
(Background: Bitcoin Foundation elder: working hard to restart free BTC faucet, 21million.com is now online)
(Context: Cambridge report: Bitcoin mining “clean energy” usage has reached 52.4%, will Tesla restart BTC payments?)
According to the disclosure by the involved party W, on April 17, he discovered that unibtc issued by Bedrock had experienced a price anomaly on a certain Bitcoin L2 chain and was decoupled from BTC. W believed that the decoupling was temporary and would soon re-peg, seeing a good arbitrage opportunity, he transferred some BTC to the Bitcoin L2, exchanged it for unibtc, and waited to sell it after it re-pegged.
Within just 24 hours after the decoupling, unibtc had re-pegged, but when W attempted to sell the unibtc he held, he found that the unibtc-BTC liquidity pool on the chain had been removed by Bedrock officials, which was the only exit channel for unibtc on the chain. Unable to sell his unibtc, W tried to bridge unibtc 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’s signature authorization.” W contacted the customer service of the Free cross-chain bridge, who explained: “The multi-signature key for unibtc cross-chain is held by Bedrock, and users cannot move unibtc to other chains without their permission.”
With no other options, W reached out to relevant personnel at Bedrock 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 needs to be temporarily reviewed.”
At this point, W realized that the exit path for unibtc on this chain had been completely cut off, and the unibtc worth approximately $200,000 in his possession was “temporarily frozen”—he could neither sell it on the chain nor transfer it to other chains. He felt very helpless, only hoping to recover his principal smoothly.
However, the attitude of Bedrock personnel became ambiguous—they neither clarified when W could withdraw his principal nor provided any written commitments, 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 conducting a dump, then Bedrock personnel suggested W “hold LayerBank accountable.” However, after W contacted LayerBank, he received no response for a long time.
Feeling helpless, W sought help on Twitter from friends. After more than two weeks of back-and-forth, 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 means to cut off users’ exit paths for unibtc, resulting in those unibtc being “substantially frozen.” Of course, this article does not intend to speculate on the reasons behind the aforementioned events; it merely aims to explain from a technical perspective how to avoid and eliminate similar centralized malpractices.
First, reviewing the aforementioned incident, we can see that Bedrock, as the issuer of unibtc and the initial LP of the liquidity pool in the secondary market, naturally possesses the authority over the exit channel for unibtc in the secondary market. If there is a need to limit its power, it should be primarily through governance rather than technical means.
However, the collusion between the Free cross-chain bridge and Bedrock to refuse user requests exposes significant technical flaws 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 prevent users from exiting, yet in the case of unibtc freezing, both Bedrock and the Free cross-chain bridge wield strong centralized authority without providing an anti-censorship exit channel.
Of course, cases similar to unibtc are not uncommon; cutting off users’ exit paths is frequently seen among major exchanges, and this kind of centralized authority usage is also not rare among cross-chain bridges or other types of project parties. In June 2022, the Harmony Horizon Bridge temporarily 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 StableMagnet incident in 2021, the project party embezzled $24 million through a pre-reserved programming vulnerability, and ultimately, a large police force from Hong Kong and the UK, with community assistance, managed to recover 91% of the stolen goods.
These various cases fully illustrate that if asset custody platforms cannot provide trustless services, it will inevitably lead to dire consequences.
However, achieving trustlessness is not easily attainable. From payment channels and DLC to BitVM and ZK Rollup, various implementation methods have been attempted, which can greatly safeguard user autonomy and provide reliable asset withdrawal exits, but there are still unavoidable flaws behind them.
For instance, payment channels require the parties to monitor potential malicious actions from the counterpart; DLC relies on oracle; BitVM has high costs and other trust assumptions in practical application; ZK Rollup’s escape pods require a long window period to trigger and necessitate shutting down the Rollup, which entails significant costs.
Currently, among the various technological solutions available, no perfect asset custody and exit plan has emerged, and the market still needs to innovate. In the following sections, DeepSafe Research will take the asset custody solution launched by DeepSafe as an example to explain a trustless message verification scheme that combines TEE and ZK, MPC, balancing indicators such as cost, security, and user experience, which can provide reliable underlying services for trading platforms, cross-chain bridges, or any asset custody scenarios.
CRVA: Crypto Random Verification Network
The most widely used asset management solutions on the market today mainly adopt multi-signature or MPC/TSS methods to determine whether asset transfer requests are valid. The advantage of this solution lies in its simple implementation, low cost, and fast message verification speed, while the disadvantages are self-evident—insufficient security, often tending towards centralization. In the 2023 Multichain incident, all 21 nodes participating in MPC computation were controlled by a single individual, constituting a typical witch attack. This incident sufficiently demonstrates that merely having dozens of nodes on the surface does not provide a high level of decentralized 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 over the long term.
Secondly, to enhance the efficiency of MPC/TSS computation, CRVA will randomly select nodes through a lottery algorithm, for instance, selecting 10 nodes every half hour to serve as verifiers, validating whether user requests should be approved, and then generating corresponding gate limit signatures for release.
To prevent internal collusion or external hacker attacks, CRVA’s lottery algorithm employs an original circular VRF, combined with ZK to hide the identities of those selected, allowing external parties to be unaware of who has been chosen.
The Inability to Directly Observe the Selected Participants
Of course, merely achieving this level is not enough. While the outside world does not know who has been selected, the selected individuals themselves are aware, thus leaving room for collusion. To further eliminate collusion, all nodes in the CRVA must run the core code within a TEE hardware environment, which is equivalent to conducting core operations in a black box. Consequently, no one can know whether they have been selected unless they can crack the TEE trusted hardware, which, under current technological conditions, is extremely difficult to accomplish.
The above describes the basic idea behind DeepSafe’s CRVA solution. In the actual workflow, there is a significant amount of broadcasting communication and information exchange among the nodes within the CRVA network. The specific process is as follows:
1. All nodes must first pledge assets on-chain before entering the CRVA network, leaving a public key as registration information. This public key is also referred to as the “permanent public key.”
2. Every hour, the CRVA network randomly selects several nodes. However, prior to 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 “permanent public key.” In other words, everyone must use ZK to prove their existence on the candidate list without revealing their identity.
3. The purpose of the “temporary public key” is privacy protection. If the lottery is drawn directly from the “permanent public key” set, when the results are announced, everyone would immediately know who has been elected. If individuals only disclose their one-time “temporary public key,” then after selecting a few from the “temporary public key” set, the most one can know is that they have won, but they won’t know to whom the other winning temporary public keys correspond.
4. To further prevent identity disclosure, the CRVA intends to ensure that you do not even know what your “temporary public key” is. The process of generating the temporary public key is completed within the node’s TEE environment, where you executing TEE cannot see what happens inside.
5. The temporary public key is then plaintext encrypted into “nonsense” within the TEE before being 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, which does not know which candidates correspond to these temporary public keys.
6. After the Relayer restores all “temporary public keys,” they are uniformly collected and submitted to the on-chain VRF function, which then selects the winners. These selected individuals verify the transaction requests sent from the user front end, and based on the verification results, generate threshold signatures to finally submit them on-chain. (It should be noted that the Relayer here is also hidden and selected regularly.)
Some may ask, since each node does not know whether it has been selected, how will the work be done? In fact, as mentioned earlier, everyone will generate a “temporary public key” in their local TEE environment. Once the lottery results are announced, we will directly broadcast the list, and everyone only needs to input the list into the TEE to check whether they are selected.
The core of the DeepSafe solution lies in the fact that almost all significant 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, theoretically, one would need to attack the entire CRVA network, and given that each node is protected by TEE, the difficulty of the attack significantly rises.
Combining CRVA’s Asset Self-Custody Solution
We have introduced the general principles of CRVA and clarified how it achieves decentralized trustlessness. Below, we will take a Bitcoin algorithm stablecoin named HelloBTU as a case study to further clarify how CRVA applies 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 HelloBTU’s designated collection address, which then bridges the BTC to the Ethereum chain and interacts with HelloBTU’s stablecoin smart contract.
Suppose a user wishes to pledge 10 BTC to the HelloBTU platform. The specific operation involves first transferring the 10 BTC to a Taproot address on the Bitcoin chain, with the corresponding unlocking requiring a 2/2 multi-signature, one signature generated by the user and the other by CRVA.
Several scenarios are involved here:
If the 10 BTC are transferred to the aforementioned Taproot address, and the user mints stablecoins with these 10 BTC, they may now wish 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 fails to cooperate with the user for an extended period, once the time-lock window expires, the user can unilaterally reclaim the 10 BTC. This functionality is called “User Autonomous Redemption.”
Another scenario involves the BTC used as collateral being liquidated. In this case, the user should cooperate with CRVA to transfer these BTC and hand them over to the CRVA’s one-way control channel. However, the user can refuse to cooperate. At this point, these BTC are temporarily locked, and no one can access them. Once the time-lock window expires, these funds can be transferred by CRVA into 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 shorter, while the time-lock for user autonomous redemption is longer. In other words, if CRVA and the user cannot cooperate, these BTC will eventually be prioritized to enter the CRVA one-way channel. This way, the user’s malicious behavior can be effectively restricted.
Regarding potential malfeasance from CRVA, since CRVA is an automated operating node network system, as long as the initial code does not contain malicious logic, CRVA will not actively refuse to cooperate with users, making such scenarios virtually negligible. If CRVA experiences widespread node downtime due to power outages, floods, or other force majeure, users still have ways to safely retrieve their assets according to the processes mentioned above.
The trust assumption here lies in our belief that CRVA is sufficiently decentralized and will not act maliciously (as previously explained).
If BTC is transferred into the CRVA one-way channel, it usually indicates that the corresponding on-chain collateral position has been liquidated, at which 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 the corresponding amount of BTC and transfer it to the liquidator.
If CRVA does not respond for an extended period and the time-lock expires, these BTC will be transferred to an address controlled by the DAO, triggered by multi-signature. The subsequent handling will be resolved by DAO governance, composed of well-known project parties, security companies, and investment institutions, established to curb malfeasance by any single entity.
In summary, we have broadly explained DeepSafe’s self-custody solution for Bitcoin assets, and for ERC-20 assets, the principles are similar and will not be elaborated further. Regarding the previously mentioned unibtc freezing case, if the unibtc cross-chain bridge employs CRVA’s self-custody solution, it would be difficult for the asset issuer to unilaterally control the situation. In the future, DeepSafe will continuously iterate its self-custody solution technology for Bitcoin and ERC-20 assets, and we hope you will stay tuned!
