Introducing Finality Bridge: A Trust-minimized Bridge for Bitcoin

What is Finality Bridge

The Finality Bridge stands as a transformative innovation in Bitcoin bridging technology, meticulously developed by Bitlayer and underpinned by the advanced BitVM smart contract framework. This pioneering solution draws upon critical low-level components inherited from the BitVM project, a collaborative endeavor shaped by the combined efforts of the BitVM Alliance and the broader BitVM community. Together, these contributors have laid the foundation for a powerful and reliable protocol that bridges the gap between Bitcoin and decentralized finance ecosystems.

As the inaugural step toward the realization of the Bitlayer rollup, the Finality Bridge facilitates the secure migration of Bitcoin into the Bitlayer ecosystem, enabling it to be seamlessly integrated into BTCFi, a rapidly expanding decentralized financial infrastructure for Bitcoin. By operating in parallel with the Bitlayer rollup, the Finality Bridge ensures not only the safety and efficiency of Bitcoin transfers but also its active participation in a programmable and decentralized financial environment. What distinguishes the Finality Bridge from earlier iterations of BTC bridges is its trust-minimized architecture, which significantly reduces reliance on centralized entities or intermediary trust assumptions.

At its core, the Finality Bridge protocol is built upon a sophisticated combination of BitVM smart contracts, fraud proofs, and zero-knowledge proofs. While the concept of BitVM smart contracts is rooted in the original BitVM protocol, the specific implementation employed by the Finality Bridge represents a refined and optimized adaptation, as outlined in the BitVM2 paper. This extensible architecture allows the bridge to support a wide range of environments, making it a versatile solution for cross-chain interoperability. Initially, the bridge facilitates seamless interaction with the Bitlayer rollup and Ethereum, with plans to extend its compatibility to other EVM-compatible chains and even non-EVM ecosystems such as Solana. The token minted through this process, YBTC (Yield BTC), serves as the bridge’s native representation of Bitcoin, enabling its use across these programmable environments.

Finality Bridge as a 3rd Generation BTC Bridge

To fully appreciate the significance of the Finality Bridge, it is essential to contextualize its place within the evolutionary trajectory of BTC bridges, which can be categorized into distinct generations based on their custodial mechanisms and underlying trust models.

The first generation of BTC bridges relied on centralized custodians, where the bridge funds were locked in addresses controlled by either a single entity or a fixed group of entities. Examples such as wBTC exemplify centralized control by a single custodian, while solutions like MPC-based BTC bridges employed distributed control among a predefined group. However, despite their utility, these systems were fundamentally constrained by their reliance on centralized trust, which introduced significant risks and undermined the decentralized ethos of blockchain technology.

The second generation sought to address these limitations by introducing distributed custodianship, wherein funds were managed by groups of entities selected randomly from a larger pool. This approach aimed to mitigate collusion risks by employing incentive mechanisms, such as requiring participants to stake assets on a middleware blockchain. If a participant was found to be acting dishonestly, their stake would be forfeited, thereby aligning their behavior with the protocol’s security goals. A notable example of this model is the tBTC bridge, supported by the Keep Network. Nevertheless, even with these advancements, second-generation bridges continued to rely on assumptions of majority honesty, which limited their ability to fully eliminate trust dependencies.

In contrast, the third generation, epitomized by the Finality Bridge, represents a paradigm shift by leveraging trust-minimized smart contract custodianship. In this model, funds are locked in addresses controlled by a BitVM smart contract, which operates under the assumption that at least one honest participant exists. This drastically reduces the trust assumptions required, making the system inherently more secure and resilient. By addressing critical challenges such as the reliance on honest majorities and the mismatch in security levels between wrapped BTC and other DeFi assets, the Finality Bridge significantly enhances the robustness of decentralized financial ecosystems, ensuring that Bitcoin can play a central role in these environments.

Looking to the future, the fourth generation of BTC bridges remains a theoretical concept, contingent on the introduction of covenant opcodes in a future Bitcoin upgrade. Such an advancement would enable truly trustless smart contract custodianship, where funds are managed by covenant-style smart contracts that inherit Bitcoin’s native security model without any external assumptions. Until then, the Finality Bridge stands at the forefront of BTC bridging technology, offering an unparalleled combination of security, efficiency, and trust minimization.

YBTC

YBTC, the token minted through the Finality Bridge, serves as a secure and trust-minimized representation of Bitcoin within programmable environments. Upon successfully locking BTC into the BitVM smart contract, users receive YBTC on the Bitlayer rollup or other supported environments, with each YBTC maintaining a strict 1:1 peg with Bitcoin. This design ensures that YBTC is not merely a derivative asset but a robust and secure token directly tied to Bitcoin’s value, safeguarded by the trust-minimized architecture of the BitVM smart contract.

Unlike liquid staking tokens (LSTs), YBTC ensures that the locked BTC remains entirely inaccessible to any party, further reinforcing its security model and eliminating the risks associated with centralized custodianship. This unique characteristic positions YBTC as a programmable Bitcoin, enabling it to serve as a foundational asset within a wide range of decentralized financial applications, including yield farming, lending, and other DeFi protocols. Furthermore, on the Bitlayer rollup, YBTC is designed as a native yielding asset, allowing users to unlock additional value while maintaining the security and stability of their Bitcoin holdings. By bridging the gap between Bitcoin’s unparalleled security and the flexibility of programmable environments, YBTC exemplifies the transformative potential of the Finality Bridge in shaping the future of Bitcoin’s role in decentralized finance.

How Finality Bridge Works

The Finality Bridge operates through a carefully orchestrated protocol that defines the interactions between participants and two key smart contracts—one deployed on Bitcoin and the other on the target chain. This architecture enables the secure transfer of Bitcoin into programmable environments, leveraging a trust-minimized framework to ensure security and efficiency.

Protocol Roles and Participants

The protocol relies on a diverse set of roles, each contributing to the seamless operation of the bridge:

• Peg-in User: A Bitcoin holder who locks BTC into Bridge Contract A on Bitcoin and mints YBTC on Bridge Contract B, deployed on the target chain. Each bridge instance involves a single peg-in user.
• Peg-out User: A YBTC holder who burns their tokens on Bridge Contract B to withdraw the equivalent BTC from Bridge Contract A. The number of peg-out users corresponds to the number of fund exits in Bridge Contract A.
• Broker: An intermediary who provides short-term liquidity to fulfill peg-out requests. Brokers front the requested funds to peg-out users and later reclaim the equivalent BTC from Bridge Contract A, earning a fee for their service.
• vigilante: A participant who monitors on-chain activity for fraudulent behavior, such as invalid reclaim requests, and initiates challenges when necessary to uphold the protocol’s integrity.

In addition to these participants, two key smart contracts underpin the protocol:

• Bridge Contract A: Deployed on Bitcoin, it acts as the trust-minimized custodian of the locked funds for each bridge instance.
• Bridge Contract B: Deployed on the target chain (e.g., Bitlayer rollup), it serves as the management console for the minted YBTC tokens.

Bridge Contract A on Bitcoin

Bridge Contract A, deployed on Bitcoin, forms the foundation of the Finality Bridge’s trust-minimized security model. Built using the BitVM smart contract framework, it is not a single monolithic contract but rather a collection of independent contract instances created on demand for each new bridge instance.

The BitVM framework offers several advantages for bridge protocols:

• Controlled Deployment: Peg-in users only deposit funds after verifying that the correct smart contract instance has been generated and published. If no deposit occurs, no party is at risk.
• Defined Exit Paths: The transaction graph specifies all possible exit paths for the locked funds, ensuring that unauthorized withdrawals are impossible.
• Trust-minimized Assumption: The framework relies on the principle that as long as one participant deletes their private key, malicious actions, such as fund theft, are prevented.

By leveraging these features, Bridge Contract A ensures that the funds are secured by the smart contract itself, rather than relying on a traditional custodian.

Bridge Instances and Lifecycle

Each peg-in request triggers the creation of a new bridge instance, which manages the lifecycle of the pegged funds. The process unfolds as follows:

1. Creation: A new bridge instance begins when participants jointly propose and cosign a transaction graph, which specifies all possible fund exit paths. Once the signed transaction graph is published, the BitVM smart contract is considered deployed.
2. Activation: The bridge instance transitions from an inactive to an active state once the peg-in fund is locked in Bridge Contract A.
3. Completion: When all pegged funds are returned to Bitcoin, the bridge instance enters a finished state.

This modular approach ensures that each bridge instance operates independently, with its own set of participants and transaction graph, while maintaining the overall trust-minimized security model.

Handling Dynamic Participation and the Role of Brokers

One of the key challenges in designing Bridge Contract A is managing the dynamic and unpredictable nature of peg-out requests. Since the identities of peg-out users are unknown at the time of contract creation, the transaction graph must presign all possible exit paths, including the beneficiaries and amounts for each potential withdrawal. While this approach ensures flexibility, it introduces a significant limitation: only a predefined set of users can receive exit funds.

To address this issue, the protocol introduces brokers, who serve as liquidity providers. Brokers fulfill peg-out requests by fronting the requested funds to peg-out users and later reclaiming their equivalent BTC from Bridge Contract A. This front-and-reclaim scheme shifts the operational complexity to brokers, who charge a fee to cover their costs and risks. By acting as intermediaries, brokers ensure the smooth functioning of the protocol while maintaining its trust-minimized design.

Presigning Committee and Smart Contract Custodian

The creation of a BitVM smart contract for each bridge instance involves a presigning committee, which includes the peg-in user, brokers, and a group of neutral members elected from a larger pool. This committee plays a critical role in ensuring the security of the pegged funds:

• Transaction Graph Signing: The committee jointly signs the transaction graph, which defines all possible exit paths for the funds.
• Multisig Wallet Creation: The committee generates an N-of-N multisig wallet, which acts as the custodian of the pegged funds. The funds are transferred to this wallet, and the trust-minimized properties of the BitVM framework ensure that collusion among committee members is prevented as long as at least one member deletes their private key.

To further enhance security, the size of the presigning committee $N_{\text{signer}}$ is standardized across all bridge instances, ensuring that funds remain fungible and that no single instance becomes a weak point in the system.

Fraud Proofs and Reclaim Process

Fraud proofs are integral to maintaining the integrity of the reclaim process, which brokers use to recover funds from Bridge Contract A. The process is designed to prevent invalid reclaim attempts while minimizing on-chain footprint:

1. Reclaim Request: Brokers initiate a reclaim request by committing to the result of a Reclaim Checker, which verifies the validity of the request (e.g., whether the peg-out user burned the corresponding YBTC and whether the broker fronted the correct amount of BTC).
2. Challenge Period: If no challenge is raised within a specified period, the reclaim request is approved, and the broker retrieves the funds.
3. Fraud Proofs: In the event of a dispute, vigilantes can initiate a fraud proof by demonstrating that the broker’s reclaim request is invalid. This is achieved using a chunked implementation of the Groth16 verifier, which allows disputes to be resolved on Bitcoin’s limited scripting environment.

By leveraging fraud proofs, the protocol ensures that invalid reclaim requests are identified and rejected, with brokers forfeiting their stakes in cases of proven fraud.

End-to-End Operations

The Finality Bridge facilitates seamless interactions between Bitcoin and the target chain through a structured sequence of operations that encompass the peg-in, peg-out, and reclaim processes. These operations are designed to uphold the trust-minimized principles of the protocol while ensuring security, efficiency, and transparency for all participants. Below, we explore these processes in detail, highlighting their intricate workflows and the mechanisms that ensure their integrity.

Peg-in: Locking BTC in Bridge Contract A

The peg-in process begins with the presigning committee collaboratively generating a BitVM smart contract and jointly establishing an N-of-N multisig wallet, which serves as the custodian of the pegged BTC. This multisig wallet is a critical component of the system’s trust-minimized design, as it ensures that the funds remain secure from collusion among committee members. The protocol’s security is underpinned by the principle that as long as at least one committee member deletes their private key, it becomes computationally infeasible for the remaining members to manipulate the funds or tamper with the contract.

Before transferring their BTC, the peg-in user must verify that the BitVM smart contract is correctly constructed and consistent with the agreed-upon transaction graph. Once convinced of its validity, the peg-in user deposits their funds into the multisig wallet, effectively locking them within the bridge contract. This action activates the bridge instance, transitioning it from an inactive to an active state, and marks the beginning of the pegged fund’s lifecycle. The trust-minimized nature of the protocol ensures that the user’s funds are safeguarded throughout the operation, relying solely on the decentralized cryptographic guarantees of the BitVM framework.

Peg-out: Fronting the Peg-out Request

The peg-out process, which enables the withdrawal of BTC from Bridge Contract A, introduces an additional layer of operational complexity due to its reliance on brokers to provide short-term liquidity. This process unfolds in a series of carefully coordinated steps:

1. The peg-out user initiates the process by burning a specified amount of YBTC on Bridge Contract B, signaling their intent to withdraw the corresponding BTC from the Bitcoin network.
2. Following the burn, the peg-out user partially signs a Bitcoin transaction representing the peg-out request and broadcasts it to the network. This transaction serves as a claim for the requested funds, awaiting a broker to fulfill it.
3. The broker, upon receiving the peg-out request, verifies its validity by checking two key conditions: whether the peg-out user has indeed burned the specified amount of YBTC on the target chain and whether the request remains unfulfilled by any other broker, thereby preventing double-spending.

Once the broker confirms the legitimacy of the request, they front the requested BTC to the peg-out user directly on the Bitcoin network. This straightforward operation ensures that the user receives their funds promptly, while the broker assumes the responsibility of reclaiming the equivalent amount from Bridge Contract A at a later stage. The reliance on brokers to facilitate this process not only addresses the unpredictability of peg-out user participation but also streamlines the protocol by offloading operational complexity to liquidity providers.

Reclaim: An Optimistic Process

The reclaim process enables brokers to recover the BTC they fronted during the peg-out operation. Designed as an optimistic mechanism, this process leverages the trust-minimized nature of the protocol while incorporating safeguards to prevent fraudulent claims. The workflow follows these steps:

1. The broker initiates the reclaim process by submitting a KICKOFF transaction on the Bitcoin network. This transaction serves as a formal reclaim request and includes the broker’s commitment to the result of the Reclaim Checker, a mechanism that verifies the validity of the reclaim.
2. If no challenges are raised within a predefined dispute window—typically one week—the reclaim request is approved, and the broker retrieves the funds from Bridge Contract A. Each successful reclaim consumes one exit path in the transaction graph associated with the bridge instance. However, if all funds in the bridge instance have already been withdrawn, any remaining unused exit paths (reclaim sub-graphs) are invalidated, rendering further reclaims impossible.
3. In cases where a vigilante disputes the reclaim request, the protocol initiates an on-chain dispute resolution game. The vigilante triggers this process by presenting evidence that the reclaim request is invalid, such as proof that the peg-out user did not burn the claimed YBTC or that the broker did not front the corresponding BTC.

The dispute resolution process is central to maintaining the integrity of the reclaim mechanism. If the vigilante successfully demonstrates that the reclaim request is invalid, the request is rejected, and no funds are unlocked from Bridge Contract A. Furthermore, the broker forfeits their stake, reinforcing the protocol’s deterrence against fraudulent behavior. Conversely, if the broker’s reclaim request is upheld, the funds are released, and the reclaim process concludes.

Cohesion of Operations

The peg-in, peg-out, and reclaim processes together form the backbone of the Finality Bridge’s operational framework. Each step is meticulously designed to ensure that the system remains secure, trust-minimized, and efficient, even in the face of dynamic and unpredictable user behavior. By leveraging the unique properties of the BitVM smart contract, the protocol achieves a balance between decentralization and usability, enabling seamless interoperability between Bitcoin and programmable environments on the target chain.

Conclusion

The Finality Bridge represents a significant advancement in Bitcoin bridging technology, offering a trust-minimized, secure, and efficient framework for interoperating between Bitcoin and programmable environments. By leveraging the innovative BitVM smart contract framework, the protocol eliminates reliance on traditional custodians, instead relying on cryptographic guarantees and decentralized mechanisms to safeguard user funds. Through its well-orchestrated peg-in, peg-out, and reclaim processes, the bridge not only ensures seamless asset transfers but also introduces a robust system for dispute resolution and fraud prevention.

As the Bitcoin ecosystem continues to evolve, the Finality Bridge stands as a testament to the possibilities unlocked by combining Bitcoin’s inherent security with cutting-edge cryptographic advancements. It paves the way for more trustless and scalable solutions, bridging the gap between Bitcoin and the broader blockchain ecosystem while maintaining the principles of decentralization and transparency.