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 Bedrock's official team on a certain Bitcoin Layer 2 chain and could not be withdrawn.
According to the disclosure by person W, on April 17, he discovered that uniBTC issued by Bedrock showed abnormal pricing on a certain Bitcoin L2 chain and had decoupled from BTC. W believed the decoupling was temporary and would soon re-anchor, presenting a good arbitrage opportunity. He then cross-chained some BTC into this Bitcoin L2, exchanged it for uniBTC, and planned to sell it after re-anchoring.
Within 24 hours of decoupling, uniBTC had already re-anchored. However, when W tried to sell his uniBTC, he found that the uniBTC-BTC liquidity pool on the chain had been removed by Bedrock's official team, which was the only secondary market exit channel for this token. Unable to sell his uniBTC, W attempted to cross-chain it to another chain.
When he found the only cross-chain bridge (named Free) supporting uniBTC on this chain, he received a prompt - "Transaction requires project party signature authorization". W contacted Free cross-chain bridge's customer service, who explained: "The multi-signature key for uniBTC cross-chain is hosted by Bedrock, and users cannot transfer uniBTC to other chains without their permission."
With no other option, W approached Bedrock personnel, who initially replied: "We can allow you to withdraw the principal, but whether you can withdraw the arbitrage profits will be temporarily under review."
At this point, W realized that the exit path for uniBTC on this chain had been completely cut off, and his uniBTC worth around 200,000 USDT was "temporarily frozen" - unable to be sold on this chain or transferred to another chain. He felt helpless, only seeking to withdraw his principal.
However, Bedrock personnel's attitude became ambiguous - neither clearly stating when W could withdraw his principal nor providing any written commitment, delaying with reasons like "risk review" and "technical investigation".
After a period of delay, Bedrock claimed that the uniBTC decoupling was due to someone borrowing uniBTC assets on LayerBank in large quantities and dumping them, and suggested W "hold LayerBank accountable". However, W found that LayerBank did not respond for a long time.
Helpless, W sought help from friends on Twitter. After more than two weeks of negotiation, he finally received a positive response from LayerBank and Bedrock's official team and successfully recovered his assets.
W's experience is not an isolated incident. According to feedback from other parties, Bedrock had previously used similar methods to cut off users' uniBTC exit paths, effectively freezing these uniBTC. Of course, this article does not intend to speculate on the reasons behind these events, but merely aims to explain from a technical perspective how such centralized malicious behaviors can be avoided and prevented.
2. Every hour, the CRVA network will randomly select several nodes. Before this, 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 prove through ZK that they exist in the candidate list without revealing their identity;
3. The purpose of the "temporary public key" is privacy protection. If drawing directly from the "permanent public key" set, the result would reveal who was selected. By only exposing the one-time "temporary public key" and selecting from its set, you can only know if you were selected, but not who else was selected.
4. To further prevent identity disclosure, CRVA plans to make you unaware of your own "temporary public key". The temporary public key generation process is completed within the node's TEE environment, and you running the TEE cannot see what happens inside.
5. Then, within the TEE, the temporary public key is encrypted into "gibberish" before being sent externally, which only specific Relayer nodes can restore. Of course, the restoration process is also completed in the Relayer node's TEE environment, and the Relayer does not know which candidates these temporary public keys correspond to.
6. After the Relayer restores all "temporary public keys", they are collectively submitted to the on-chain VRF function to select the winners, who will verify user front-end transaction requests and generate threshold signatures based on the verification results, then submit them to the chain. (Note that this Relayer also has a hidden identity and is periodically selected)
You might wonder how work proceeds if no node knows if they are selected. As mentioned earlier, each person generates a "temporary public key" in their local TEE environment. After the lottery results are announced, we broadcast the list, and each person only needs to pass the list into their TEE to check if they were selected.
The core of DeepSafe is that almost all important activities occur within the TEE hardware, which cannot be observed from the outside. Each node is unaware of the selected validators, preventing collusion and significantly increasing external attack costs. Theoretically, attacking the CRVA committee based on DeepSafe would require attacking the entire CRVA network, and with each node protected by TEE, the attack difficulty rises dramatically.
Implementation Combined with CRVA's Self-Custody Asset Solution
We have introduced the basic principles of CRVA and how it achieves decentralized trustlessness. Next, we will use HelloBTU, a Bitcoin algorithm stablecoin, to further clarify CRVA's application in asset custody.
As is well known, since the Bitcoin chain lacks a Turing-complete environment and cannot directly implement complex DeFi smart contract logic, mainstream BTCFi bridges Bitcoin to other chains for smart contract interaction. HelloBTU's smart contract is deployed on Ethereum, where users can deposit BTC into HelloBTU's designated receiving address, which is then bridged to the Ethereum chain by the official bridge for interaction with HelloBTU's algorithmic stablecoin smart contract.
Suppose a user wants to stake 10 BTC on the HelloBTU platform. They first transfer 10 BTC to a Taproot address on the Bitcoin chain, which requires 2/2 multisig for unlocking, with one signature generated by the user and the other by CRVA.
Here are several scenarios:
Assuming 10 BTC are transferred to the above Taproot address and the user has minted stablecoins, they now want to actively redeem the BTC. At this point, the user and CRVA each generate a signature to unlock and transfer the 10 BTC back to the user's address. If CRVA does not cooperate for an extended period, once the timelock window expires, the user can unilaterally reclaim these 10 BTC, a function called "user-initiated redemption".
In another scenario, the user's BTC collateral is liquidated, and they should cooperate with CRVA to transfer these BTC under CRVA's unidirectional channel control. However, the user might refuse to cooperate, causing the BTC to be temporarily stuck. Once the timelock window passes, these funds can be transferred by CRVA to a Taproot address under CRVA's unidirectional channel.
A key detail is that the timelock for BTC entering the CRVA unidirectional channel is shorter than the user's self-redemption timelock. In other words, if CRVA and the user cannot cooperate, these BTC will ultimately enter the CRVA unidirectional channel, effectively limiting user-side malicious behavior.
Regarding potential CRVA malicious actions, since CRVA is an automated node network system, as long as its initial startup code does not contain malicious logic, CRVA will not actively refuse to cooperate with users, so this can be largely ignored.
If CRVA experiences mass node shutdowns due to force majeure like power outages or floods, users can still safely withdraw assets according to the previously mentioned process. The trust assumption here is that we trust CRVA to be decentralized enough not to actively act maliciously (reasons already thoroughly explained).
If BTC is transferred to the CRVA unidirectional channel, it often indicates that the corresponding on-chain algorithmic stablecoin position has been liquidated, and the BTC's actual ownership belongs to the liquidator. The liquidator can initiate a withdrawal request, which CRVA will review. If approved, CRVA will generate a signature and transfer the corresponding BTC amount to the liquidator.
If CRVA does not respond for an extended period, once the timelock expires, these BTC will be transferred to a DAO-controlled address, triggered by multisig, with subsequent handling resolved through DAO governance. This DAO is composed of well-known project parties, security companies, and investment institutions, established with the aim of deterring malicious actions by any single entity.
In summary, we have outlined DeepSafe's asset self-custody solution for Bitcoin, and the principle for ERC-20 assets is similar and will not be elaborated further. Regarding the previously mentioned unibtc freezing case, if the unibtc cross-chain bridge adopts CRVA's self-custody solution, it would be difficult for the asset issuer to unilaterally control the entire process.
