
Interpreting Bool Network: The Truly Centralized Bitcoin Cross-Chain Bridge?
TechFlow Selected TechFlow Selected

Interpreting Bool Network: The Truly Centralized Bitcoin Cross-Chain Bridge?
Bool Network may offer a breakthrough hope for Bitcoin cross-chain bridges.
Authors: Faust & Abyss, Geeker Web3
Abstract: Since the emergence of various cross-chain bridges, a series of hacking incidents have followed closely behind. The 2022 Axie Infinity official bridge hack, which resulted in a loss of $620 million, shocked the world and prompted widespread reflection on how to achieve secure and trustless cross-chain interoperability. Yet to this day, many fundamental challenges in this domain remain unresolved.
Like public blockchain development, cross-chain bridge designs face their own "impossible triangle," one that still cannot be fundamentally broken. To gain advantages in cost and user experience (UX), most cross-chain bridges adopt a witness model similar to multi-signature schemes—precisely the kind of setup that has been a prime target for hackers since its inception.
Painful historical lessons tell us that unprotected witness-based bridges will eventually be compromised. Yet such models have become commonplace across the Bitcoin ecosystem—an alarming reality.
The project introduced in this article, Bool Network, aims to improve upon traditional witness bridge security by providing dynamically rotating witnesses combined with privacy computing and TEE-protected key management. This approach attempts to address decentralization issues inherent in current cross-chain bridges and may offer a breakthrough path forward for Bitcoin bridging solutions.
The State of the Bitcoin Ecosystem: Multi-Signatures Are Everywhere
At its core, a cross-chain bridge proves on Chain B that someone initiated a cross-chain request on Chain A and paid the required fees. There are multiple ways to implement this proof.
Light client bridges deploy smart contracts on-chain to natively verify cross-chain messages. These offer the highest level of security but come at high costs and are not feasible on Bitcoin (current projects claiming to be ZK bridges for Bitcoin can only use zero-knowledge proofs when moving BTC out; returning BTC cannot go through a ZK bridge).
Optimistic bridges represented by BitVM rely on fraud proofs to ensure correct message processing, but these are extremely difficult to implement in practice. As a result, most Bitcoin cross-chain bridges resort to the witness model—designating several off-chain validators who verify and confirm all cross-chain transactions.
DLC bridges like DLC.link introduce payment channel concepts atop multi-sig oracles/witnesses, limiting potential malicious behaviors by witnesses. However, they still fail to eliminate multi-sig risks at their root.

Ultimately, before BitVM becomes viable, aside from Lightning Network/payment channels or client-side validated/homomorphic binding projects like RGB++, nearly all other Bitcoin cross-chain bridges are fundamentally based on multi-signature schemes.
History has already shown that if we don't solve the trustlessness problem of multi-sig bridges and large asset custodians, fund theft is merely a matter of time.
Some projects attempt to mitigate risk by requiring over-collateralization of assets from witnesses, using slashing conditions as punishment, or having major institutions act as trusted validators. But ultimately, witness-based bridges share the same security model as multi-sig wallets—both depend on threshold mechanisms (e.g., M-of-N signatures) for trust assumptions, offering limited fault tolerance.

How to configure and manage multi-sigs, how to make them more trustless, and how to prevent collusion among witnesses or raise external attack costs—these are long-term challenges that must be addressed in Bitcoin Layer 2 cross-chain bridge design.
Is there a way to prevent collusion among signers and make it harder for hackers to steal keys externally? Bool Network proposes an integrated solution leveraging ZKP-RingVRF algorithms and TEE technology to enhance the security of witness-based bridges.
Bool Network: A Privacy Computing Infrastructure Designed for Cross-Chain Bridges
In essence, whether it's KYC, PoS, or PoW, the goal is decentralization and Sybil resistance—to prevent critical control rights from being concentrated in a few hands. Using multi-sig/MPC on top of PoA or KYC may reduce security risks via institutional credibility, but this model differs little from centralized exchanges—you still have to trust designated validators not to misuse funds in the bridge pool. This is essentially a consortium chain, fundamentally violating the trustless principle of blockchain.
PoS-based multi-sig/MPC offers greater trustlessness than PoA, with much lower entry barriers. However, it faces its own problems—such as node identity exposure.
Imagine a network of dozens of nodes serving as witnesses for a specific cross-chain bridge. Because these nodes frequently exchange data, their public keys, IP addresses, or other identifying information may be exposed. Attackers can then craft targeted attacks, potentially compromising some nodes’ private keys. Additionally, insiders may collude—especially dangerous when the number of nodes is small.
How do we solve these issues? One instinctive response is to strengthen key protection against external surveillance. A reliable method is encapsulating keys within a TEE (Trusted Execution Environment).
TEE allows software to run securely within isolated regions on a device, inaccessible to other system components. Sensitive data or programs can thus be protected from leakage or tampering.
But here’s the catch: How can we prove that a witness actually stores their key and generates signatures inside a TEE? The answer lies in remote attestation—witnesses provide cryptographic proof that they're running inside a TEE. Verifying this proof on any blockchain incurs negligible cost.

However, even with TEE, challenges remain. Suppose the total number of witnesses is small—say five. Even if keys are securely stored in TEEs, a small committee still lacks censorship resistance and availability. For example, if all five nodes suddenly disappear, the bridge halts operation—locking or redeeming assets becomes impossible, effectively freezing funds permanently.
After considering compatibility, decentralization, and cost, Bool Network proposes the following architecture:
Using staking, build a permissionless candidate witness network—anyone who stakes sufficient assets can join. Once the network scales to hundreds or thousands of devices, randomly select a subset of nodes periodically to serve as temporary witnesses for a cross-chain bridge, avoiding the "entrenchment" of power (a concept also seen in today’s PoS Ethereum).
How do we ensure randomness in the selection algorithm? Traditional PoS blockchains like Algorand and Cardano use VRF functions to generate pseudorandom numbers and elect block producers cyclically. However, standard VRFs often lack privacy—the identities of participants and selected validators are largely exposed.

Dynamic witness selection for cross-chain bridges differs significantly from dynamic block producer selection in PoS chains. Even if a block producer’s identity is revealed, the damage potential is limited due to built-in constraints.
But for cross-chain bridge witnesses, identity exposure is catastrophic—if attackers obtain a validator’s key or if insiders collude, the entire asset pool is at risk. In short, the security models of cross-chain bridges and PoS chains differ vastly; witness anonymity must be prioritized.
Ideally, we’d hide the list of selected witnesses entirely. Bool Network uses an original ring-VRF algorithm to conceal the identities of chosen validators within the full set of candidates. While the full details are complex, we simplify it below:
1. Before joining the Bool Network, each candidate must stake assets on Ethereum or Bool’s own chain, registering a public key—called a “permanent public key.” This key serves as their identity and is publicly visible on-chain.
2. Every few minutes to half an hour, Bool Network uses a VRF function to randomly select several witnesses. Prior to this, each candidate generates a one-time “ephemeral public key” locally and creates a ZKP proving its association with their registered “permanent public key,” thereby proving eligibility without revealing identity.
3. Why use ephemeral public keys? For privacy. If selections were made directly from the permanent public key set, revealing winners would expose their identities, weakening security.
By submitting one-time ephemeral keys and selecting winners from that hidden set, even elected validators only know they’ve been chosen—not who else was selected.
4. It gets better: Bool Network ensures you don’t even know your own ephemeral public key. How? Generate it inside the TEE and encrypt it into ciphertext before transmission.

Generating the ephemeral public key inside the TEE keeps both data and computation secret. Once created, it is encrypted into unreadable “garbled” form before leaving the TEE. You only see the ciphertext—not the original key (note: the ZKP linking the ephemeral key to a permanent key is also encrypted along with it).
5. Candidates send the encrypted ephemeral public key to designated Relayer nodes. The Relayer decrypts these ciphertexts and recovers the original ephemeral public keys.
Here's the issue: The Relayer knows which ciphertext came from whom. If decrypted naively, it could map each ephemeral key back to its sender. Therefore, decryption must also occur within a TEE—hundreds of encrypted keys enter, plaintext keys emerge scrambled, acting like a mixer to preserve privacy.
6. After collecting the decrypted ephemeral public keys, the Relayer submits them to the on-chain VRF function, which selects winners to form the next cross-chain bridge witness committee.
Thus, the logic becomes clear: We periodically and randomly select a few nodes from the ephemeral public key pool to serve as temporary, anonymous witnesses—a mechanism called DHC (Dynamic Hidden Committee).
Since every node runs TEE, MPC/TSS private key shards, core validation programs, and all computations are hidden within the TEE environment. No participant—including elected validators—knows whether they’ve been selected, preventing collusion and external compromise at the root level.

Lifecycle of a Bool Network Cross-Chain Message
Having outlined Bool’s approach to hiding witness identities and protecting keys, let’s walk through its operational workflow. Assume the left side is the source chain and the right is the destination chain. The diagram below illustrates the complete lifecycle of assets moving from source to target chain. From a data flow perspective, we break down Bool Network’s cross-chain process into four stages:

First, after a withdrawal is initiated on the source chain, the message is relayed to the Messaging Layer. Upon arrival, the dynamic committee verifies that the transaction exists and is valid on the source chain, then signs it.
One might ask: If no one knows who’s on the committee, how can messages reach the right people for signing? The solution is simple: broadcast the message network-wide. Since no one knows who the selected validators are, just send the pending cross-chain message to everyone.
Recall that each node’s ephemeral public key is generated and sealed inside the local TEE. To check if their key was selected, the verification logic resides entirely within the TEE. By feeding the pending cross-chain message into the TEE, the internal program determines whether to sign it.

After signing inside the TEE, the digital signature cannot be sent out directly. Doing so would reveal participation, allowing others to infer membership in the committee. Thus, we must hide whether a node signed the message—achieved by encrypting the signature itself, similar to how ephemeral public keys were encrypted earlier.
In summary: Bool Network uses P2P propagation to deliver unsigned cross-chain messages to all nodes. Selected witnesses validate and sign within their TEEs, then broadcast encrypted signatures. Other nodes receive the ciphertexts, decrypt them inside their own TEEs, and repeat until all selected members have signed. Finally, the Relayer reconstructs the full TSS signature in its original format, completing the confirmation and signing process.
The key point: nearly all operations happen inside TEEs. Externally, nothing is visible. No node knows who the witnesses are—or even whether they themselves were selected—preventing collusion and drastically increasing the cost of external attacks.
To attack a Bool-based bridge, you’d need to identify the members of the dynamic committee—but you can’t. That means you’d have to attack the entire Bool network. In contrast, infrastructure like ZetaChain—based purely on PoS and MPC—exposes all witness identities. With a threshold like 100/200, an attacker needs to compromise only half the nodes.
But with Bool’s privacy layer, theoretically, you’d need to compromise *all* nodes. And since every Bool node runs TEE, the difficulty increases further.
Moreover, Bool remains a witness bridge at its core—requiring only a single signature submission on the destination chain, minimizing cost. Without redundant relay chains like Polkadot, it avoids second-layer verification overhead, enabling fast cross-chain settlement. This model supports both asset and general message transfers, offering strong compatibility.
Evaluating Bool’s Product Design Philosophy
We offer two perspectives: First, asset bridging is a consumer-facing (ToC) product. Second, cross-chain bridges compete more than they cooperate. Over the long term, due to high barriers to entry and homogenized demand, capital concentration in cross-chain protocols will increase, driven by strong moats including economies of scale and switching costs.
As a foundational infrastructure layer beneath cross-chain bridges, Bool Network holds broader commercial potential than upper-layer bridge projects. Beyond cross-chain message validation, it can also serve as an oracle, entering the omnichain oracle space and truly building decentralized, privacy-preserving oracle services.
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












