Original Source: 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 official and could not be withdrawn while he was conducting arbitrage operations 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 abnormal pricing on a certain Bitcoin L2 chain and had 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 official, and this token pair was the only exit channel for unibtc on 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 in his possession 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. They suggested W "hold LayerBank accountable." However, W did not receive a response from LayerBank for a long time after reaching out.

In desperation, W turned to friends on Twitter for help. After more than two weeks of negotiations, he finally received a positive response from both LayerBank and Bedrock officials, successfully recovering his assets.

W's experience is not an isolated case. According to feedback from other parties involved, Bedrock had previously 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 deny 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 wield strong centralized authority and do not provide a censorship-resistant 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 authority. 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 embezzled $24 million through a pre-reserved programming vulnerability, 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 DLCs to BitVM and ZK Rollup, various implementation methods have been attempted. While they can significantly safeguard user autonomy and provide reliable asset withdrawal channels, there are still unavoidable flaws behind them.

For instance, payment channels require parties to monitor potential malicious behavior from their counterparts, DLCs rely on oracles; BitVM incurs high costs and has 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 withdrawal solution, and the market still needs innovation. In the following text, DeepSafe Research will use 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 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 case, all 21 nodes participating in the MPC computation were controlled by one person, 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.

To address 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 employs an original circular VRF combined with ZK to hide the identities of the selected individuals, making it impossible for outsiders to directly observe who has been chosen.

Of course, achieving this level is still not enough. Although outsiders do not know who has been selected, the selected individuals themselves do know, so there remains a path for collusion. To further eliminate collusion, all nodes in CRVA must run the core code within 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, given current technological conditions, is extremely difficult to achieve.

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:

1. 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."

2. 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.

3. The purpose of the "temporary public key" is to protect privacy. If the selection were made directly from the "permanent public key" set, everyone would directly know who was elected when the results were announced. If everyone only exposes a one-time "temporary public key" and then selects a few individuals from the "temporary public key" set, you would at most know that you were selected but not who the other selected temporary public keys correspond to.

4. 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 node's TEE environment, and you running the TEE cannot see what happens inside.

5. Then, the temporary public key is plaintext encrypted into "garbled text" within the TEE before being sent to the outside world, and 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 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 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 selected periodically and has a hidden identity.)

Some may wonder, since each node does not know whether it has been selected, how does the work proceed? In fact, as mentioned earlier, each person generates a "temporary public key" within their local TEE environment. Once the lottery results are out, we simply broadcast the list; everyone just needs to input the list into the TEE and 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, which is then bridged to the Ethereum chain by the official bridge, enabling interaction with HelloBTU's algorithmic stablecoin smart contract.

Assuming a user wants to stake 10 BTC on the HelloBTU platform, the specific operation involves first transferring the 10 BTC to a Taproot address on the Bitcoin chain, where unlocking requires a 2/2 multi-signature, with one signature generated by the user and the other by CRVA.

Several scenarios are involved here:

Assuming 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, the user and CRVA 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 self-redeem."

Another scenario is that the BTC used as collateral is liquidated. In this case, 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, resulting in these BTC being temporarily stuck and inaccessible to anyone; 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-redeem is longer. In other words, if CRVA and the user cannot cooperate, these BTC will ultimately prioritize entering the CRVA one-way channel. 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, 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 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 a DAO. This operation is triggered by multi-signature, and subsequent handling will be resolved by DAO governance. This DAO is composed of well-known project parties, security companies, and investment institutions, established to curb malicious actions by a single entity.

In summary, we have provided a general explanation of DeepSafe's asset self-custody solution for Bitcoin. The principles for ERC-20 assets are similar and will not be elaborated on here. Regarding the previously mentioned unibtc freezing case, if the unibtc cross-chain bridge had adopted the CRVA self-custody solution, it would have been difficult for the asset issuer to unilaterally control the situation.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。