Dialogue with Bool Network and its ecosystem projects: How to provide secure asset custody for BTCFi?
TechFlow Selected TechFlow Selected
Dialogue with Bool Network and its ecosystem projects: How to provide secure asset custody for BTCFi?
The BTCFi narrative is more valuable than Bitcoin Layer 2, as most Layer 2 solutions can't escape the WBTC+ Ethereum mindset.
Navigating Web3 tides with focused insightsInterviewee: Jeffrey, Bool Network
Kai, Bool Network
Witter, Hibit
Buffalo, ChainSwift
Compiled by: Geek web3
Since the "Summer of Inscriptions" in 2023, the Bitcoin ecosystem has remained a focal point. However, after a brief boom, BTC Layer2 has once again hit rock bottom, causing some to question the validity of the BTC Layer2 narrative. Moreover, most BTC custody solutions remain stuck in multi-sig or MPC models, undoubtedly becoming a major bottleneck restricting the development of the BTC ecosystem.
In response, Geek web3 invited Bool Network and its ecosystem projects—Hibit, an application-chain-based exchange, and ChainSwift, a BTCFi project—to discuss the current state of the Bitcoin ecosystem and Layer2 architecture, challenges in Bitcoin asset custody, Bool Network's unique custody design, and the technical principles of Hibit and ChainSwift and how they integrate with Bool. During the discussion, Jeffrey from Bool emphasized that most Bitcoin Layer2s are pseudo-concepts, and what truly matters is expanding BTC’s use cases, especially in BTCFi.
Below is the transcript of this conversation. Enjoy reading!
1. Faust: Recently, we’ve heard from many sources that numerous VCs and project teams believe the Bitcoin Layer2 narrative has hit rock bottom, losing much of its earlier momentum. Some even argue that EVM-based Bitcoin Layer2s have failed to prove their value. Many are now turning their attention toward BTCFi. What are your thoughts on this?
Jeffrey: From what I’ve observed, many people have lost confidence in Bitcoin Layer2s. Several projects that were actively promoting themselves within the Bitcoin ecosystem have stopped updating their Twitter accounts altogether. Ultimately, the vast majority of Bitcoin Layer2s haven’t moved beyond the "WBTC-Ethereum" model—especially EVM-based Layer2s—which simply lock assets on the source chain and mint wrapped versions on the destination chain. How is this different from bridging Bitcoin to Ethereum via WBTC? And in many cases, these Layer2 bridges aren’t even as secure or reliable as WBTC.
For Bitcoin, pure "scaling" is a pseudo-concept and a false need. The real demand lies in expanding its application scenarios. It’s not enough to just build an independent chain, set up a bridge, and create something like WBTC. Babylon, for example, is an excellent case of unlocking Bitcoin’s potential—it enables Bitcoin to enhance the economic security of PoS chains, thereby extending Bitcoin’s functionality.
As for BTCFi, it’s more about expanding Bitcoin’s financial applications. This narrative is more refined and focused than that of BTC Layer2. There’s always a large amount of BTC sitting idle on-chain, and many seasoned holders prefer to keep their Bitcoin in cold wallets rather than participate in financial activities. The root causes are twofold: first, most platforms can’t genuinely guarantee asset security; second, there’s a lack of compelling incentives. If BTCFi matures, I believe it will resolve many issues within the Bitcoin ecosystem.
For Bool Network, we firmly believe in the immense potential of both BTCFi and Bitcoin itself. Our current focus is on unlocking BTC’s asset potential in the most trustless way possible. Babylon has already demonstrated that Bitcoin assets are needed across Web3—there’s still huge room for innovation here.
2. Faust: In fact, Kevin, co-founder of Bitlayer, previously mentioned that many large BTC holders want yield opportunities—but only if their assets are placed in sufficiently secure environments. Currently, many projects in the Bitcoin ecosystem carry significant risks. What are your thoughts on asset security?
Jeffrey: Asset security is a complex topic. Some believe users don’t care about whether a project is secure, but those holding this view usually aren’t high-net-worth individuals. Many large holders and institutions take asset security extremely seriously—they tread carefully. Whether they’re willing to place their assets on a platform depends entirely on its security.
Let me use Babylon as an example. Babylon has a flaw that could deter large BTC holders—the slashing mechanism. In Babylon’s model, my BTC provides economic security for a PoS application chain through staking, and in return, I receive the app chain’s tokens as rewards.
But compared to my actual BTC, those app chain tokens are essentially "air coins." If my BTC gets slashed during staking, I risk losing real value for speculative tokens—an unacceptable trade-off for big players.
Similarly, since most BTCFi projects offer altcoins as incentives, if you want such users to engage, your system must be exceptionally secure—that’s where asset security becomes paramount.
3. Wuyue: Let’s turn back to Bool Network itself. How do you define your role? Technically speaking, how does Bool ensure asset security? I recall you mentioned that nodes participating in threshold signatures in the Bool Network don’t know the specific computation content—how is this achieved?
Jeffrey: What Bool does is provide trustless asset custody for BTC, offering users mechanisms like forced withdrawals and escape hatches so BTC can securely participate in BTCFi and similar scenarios. We provide BTC custody infrastructure for cross-chain bridges, restaking, BTC-backed stablecoins, oracles, and on-chain trading platforms—not just simple bridging, but enabling deeper functionalities.
To put it more plainly: since almost all BTCFi applications rely on off-chain components, how do we ensure BTC remains secure when interacting with off-chain systems? This comes down to custody methods. Most cross-chain bridges, trading platforms, and DeFi protocols revolve around asset custody—requiring users to entrust their assets to third parties. But how do we prevent custodians from stealing or freezing funds? And how can users permissionlessly force their Bitcoin back onto the BTC chain? These are critical questions.
To address this, we leverage technologies like pre-signing, Taproot, and timelocks to build trustless forced withdrawal and escape hatch functions directly on the BTC chain, giving users full control over their BTC and enabling them to forcibly withdraw assets when needed.
Additionally, we introduced the concept of a "Dynamic Hidden Committee" (DHC), based on ZK and TEE. Let me explain how DHC works. First, Bool Network is a permissionless network based on asset staking—anyone who purchases the required hardware and stakes a certain amount of assets can become a node in the Bool Network.
Suppose there are currently 1,000 nodes distributed globally. How do we form a DHC? Say an asset management platform uses Bool’s service and requests a temporary MPC/TSS committee valid for 10 minutes with a threshold of 7/10 (a higher-security multisig). We temporarily select 10 out of the 1,000 nodes to form a threshold signature committee, which disbands and rotates after 10 minutes.
We developed an original Ring VRF algorithm combined with ZK privacy protection, ensuring that during each committee’s term, the identities of the 10 selected members are completely hidden—even the selected members themselves don’t know (using TEE).
This design has two key benefits: First, because the DHC is dynamic, temporary, and confidential, any attacker would need to compromise or bribe 7 out of 10 members within a limited time—but due to privacy protection, they wouldn’t even know who these 10 people are. Second, since committee members are mutually anonymous, collusion is nearly impossible, effectively preventing coordinated attacks—a critical weakness in traditional centralized multisig setups.
In this setup, unless an attacker compromises the majority of Bool Network nodes or breaks our core mechanism, the security of asset custody via DHC is equivalent to the overall security of the entire network.
Wuyue: Could you elaborate further on the use of TEE (Trusted Execution Environment)?
Jeffrey: TEE is essentially a black box—programs and data run encrypted inside it, and even the device operator cannot see what’s happening inside.
Earlier, I mentioned that Bool uses TEE. Without TEE, node operators could potentially observe or infer the identities of current DHC participants, or even attack the election process. With TEE, programs and data run inside this sealed environment, making account details, keys, and other sensitive information inaccessible to node operators.
Some have asked why we use ZK and MPC/TSS alongside TEE. The reason is to enhance overall system security. If a node running on TEE fails, MPC/TSS provides strong fault tolerance, allowing the network to continue operating normally—thus enhancing resilience atop TEE. Meanwhile, ZK protects the privacy of DHC participants and prevents collusion. Overall, we combine TEE+MPC+ZK to maximize system security.
Critics often point out that TEE relies on relatively centralized remote attestation methods—for example, using SGX involves dependence on Intel. But we’ve implemented the attestation process as a smart contract, decentralizing the verification method (similar to approaches used by Scroll and Taiko). Even if Intel faces issues in the future, our system can still function normally.
Kai: Let me add some context. The program running on Bool nodes is highly automated. The main role of TEE is to isolate the confidential parts of the Bool client—its sensitive logic and data—from regular human-machine interaction interfaces, while preserving basic functions like login and user interaction. Once launched, the entire validation process—including submitting SGX proofs to the chain—runs automatically within the TEE black box.
TEE hardware attaches a verifiable tag to every message sent by a Bool node, allowing external parties to confirm whether the node is truly running inside TEE. If a node isn’t operating within TEE, the smart contracts deployed by Bool on-chain will slash its staked assets.
4. Faust: Today, we also have projects from the Bool ecosystem present. For instance, Hibit aims to build a decentralized orderbook trading platform, leveraging Bool Network and ICP as infrastructure to solve asset custody, data verification, and asset snapshot challenges.
In this context, consider Degate, a trading platform structured as an Ethereum Layer2, similar to Loopring. Compared to Degate and Loopring, what are the similarities and differences?
Witter: This question touches on transparency and asset withdrawability. CEXs have well-known flaws—misuse of user funds, manipulation of internal liquidity, and dumping. While DEXs largely mitigate these issues, they face limitations in TPS and fragmented liquidity across chains.
An ideal trading platform should deliver centralized-level performance while maintaining decentralized trust, verifiable data, and seamless interoperability across all chains—including assets and wallets. That’s exactly our goal.
How do we achieve this? First, we employ a hybrid architecture combining aspects of Layer2 and application-specific chains. The Hibit network has fixed sequencer nodes and hundreds of validators. These validators don’t reach direct consensus among themselves; instead, they independently receive transaction data from the sequencer, execute transactions, and generate blocks.
How do we ensure consistency across validator nodes? We deploy Verifier smart contracts on high-performance blockchains like ICP and Solana. Hibit nodes send their locally generated block headers to these Verifier contracts. Consensus is reached when most nodes submit identical block headers. This approach minimizes communication overhead between validators, maximizing TPS.
Notably, we synchronize block headers—or Block Hashes—onto the Bitcoin chain using opcodes like OP_RETURN, effectively anchoring Hibit blocks to Bitcoin blocks and preventing rollbacks.
Faust: I’d like to ask—Degate and Loopring both offer forced withdrawal/escape hatch features, allowing users to bypass platform approval and forcibly withdraw assets. Do you have a similar mechanism?
Witter: In the context of a trading platform, we must consider extreme scenarios—like censorship attacks where the platform refuses to process a user’s request. In such cases, users need a way to forcibly withdraw their assets. That’s the purpose of the escape hatch.
Ethereum ZK Rollups rely on state snapshots for their escape hatches—if you want to forcibly withdraw assets from Layer2 to Ethereum, you must first present a snapshot proving your balance at a given time. But where are these snapshots stored?
To address this, Hibit adopts a modular asset management solution. We store user balance snapshots on low-cost storage platforms like ICP, IPFS, or Arweave. When needed, users can retrieve these snapshots. As mentioned earlier, Hibit records Block Hashes on the Bitcoin chain—users can verify the integrity of their snapshots stored on Arweave against these hashes.
Regarding forced withdrawals, we’ve built this module on top of Bool Network. Smart contracts across multiple chains can verify asset snapshots to confirm your balance on Hibit, then allow you to forcibly withdraw your funds from Hibit’s custody wallet. The deeper technical details—such as how the snapshot verification contract interacts with Hibit’s custody wallet—are better explained by someone from Bool Network, so I’ll leave that aside for now.
Faust: One follow-up question—how do you ensure Hibit nodes actually publish state snapshots to ICP and Arweave instead of being lazy?
Witter: Specific designated nodes are responsible for submitting snapshot data. These nodes handle the submissions. Note: Hibit validators first submit block headers for verification by the Verifier contracts on ICP and Solana. Only after confirmation do dedicated nodes upload corresponding state snapshots to ICP and Arweave. If snapshots are missing for too long or don’t match the block headers, the nodes will be slashed.
5. Faust: Now, let Chainswift introduce your project? You seem to be building a BTC-backed stablecoin protocol—can you walk us through your mechanism?
Buffalo: Chainswift allows users to collateralize BTC to borrow stablecoins—similar to MakerDAO. But such platforms inherently involve asset management, meaning BTC must be secured in a safe address, which is crucial. Bool Network perfectly addresses this security need—we can directly leverage Bool’s MPC/TSS services to deposit BTC into a Bitcoin Taproot address managed by the Bool Network. Once users send BTC to this Taproot address, they can bridge it to other platforms to mint stablecoins. That’s the basic framework of Chainswift.
Faust: How do you select your oracle for price feeds?
Buffalo: Oracles are essentially about providing accurate BTC pricing to the platform. On one hand, we reference WBTC prices from liquid DEXs on-chain. On the other, we select a dozen nodes that pull price data from external sources. Finally, we compute a median value—similar in principle to Chainlink.
Because it’s on-chain pricing, the feed won’t be second-by-second precise like CEXs—accuracy is roughly hourly. Short-term price spikes are smoothed out by the median algorithm, preventing erroneous liquidations. The liquidation mechanism itself works similarly to MakerDAO.
6. Faust: Finally, let’s talk more about Bool Network itself. As far as I know, Bool Network consists of two parts: the main component is the DHC candidate network we discussed earlier, and the other is a beacon-chain-like Bool Chain, responsible for managing registration and governance of DHC candidate nodes. What are the current准入 thresholds for Bool Chain and DHC candidate nodes?
Jeffrey: Bool Chain is a standard POS public chain built on Polkadot’s Substrate framework. We chose Substrate because, among POS consensus algorithms, Polkadot’s is the most decentralized, supporting thousands of nodes. Additionally, Substrate allows us to reuse many existing tools—such as its robust on-chain governance system—making it easier to transition into a DAO structure later.
Currently, joining the DHC node network only requires asset staking—simply purchase a TEE-enabled device. The hardware is general-purpose and low-cost. Although both types of nodes require staking, we keep the barrier as low as possible to maintain decentralization.
Join TechFlow official community to stay tuned
Telegram:https://t.me/TechFlowDaily
X (Twitter):https://x.com/TechFlowPost
X (Twitter) EN:https://x.com/BlockFlow_News
@godrealmx
