1. Everyone Wants it, Few can Wield it

1.1 The Land of Opportunity: Bitcoin

(Source: companiesmarketcap)

Bitcoin, created in 2008 by an anonymous developer, has grown into a massive asset, ranking 7th in market capitalization among all asset classes. It is now recognized not only by financial institutions but even by the U.S. President. Currently, Bitcoin’s market capitalization is similar to that of silver. Considering that Bitcoin’s adoption is still relatively low and that its market capitalization is only one-tenth that of gold, its future growth potential remains highly promising.

Despite Bitcoin’s immense growth as an asset, there is still a significant shortcoming—its level of utilization. Traditional assets like stocks and bonds can be used in a wide range of financial products, but Bitcoin’s financial applications are still very limited, both technically and practically. Similar to the frontier days of the American West, Bitcoin represents an untapped land of opportunity.

1.2 Attempts to Utilize BTC

Due to its enormous market capitalization, numerous companies and protocols have sought to leverage Bitcoin for additional credit creation. The main attempts to utilize BTC so far include:

• Centralized Finance: Traditional financial institutions offer various Bitcoin-based financial products. CME provides Bitcoin futures and options, Coinbase offers BTC-backed loans, and multiple institutions have launched BTC-based ETFs for investors.
• Custodian Bridging: Services like WBTC and cbBTC wrap BTC in a centralized manner, allowing it to be used on other networks. By depositing BTC with custodians like BitGo or Coinbase, users receive an equivalent amount of WBTC or cbBTC issued on the Ethereum network.
• On-chain Bridging: To eliminate the reliance on centralized custodians, various protocols have attempted to securely bridge BTC to other networks. However, achieving a completely trustless BTC bridging mechanism remains highly challenging, as some level of trust assumptions is inevitable.
• Scaling Solutions: Efforts to use BTC on sidechains and Bitcoin L2 solutions have increased recently. However, these approaches still involve additional trust assumptions. The Taproot Wizards team is working on mitigating this issue using OP_CAT.
• BTC-based Stablecoins: Protocols like Yala and Avalon have emerged, issuing stablecoins backed by BTC in a manner similar to MakerDAO. However, these solutions also face the fundamental issue of requiring trust assumptions when bridging BTC.

Examining these attempts to utilize BTC reveals a common challenge—it is difficult to use Bitcoin in a native manner. One of Bitcoin’s greatest strengths is its security, but if additional trust assumptions weaken this security, it creates a significant entry barrier for BTC holders. This is the primary reason why Bitcoin’s level of utilization remains relatively low.

1.3 Babylon: Native Utilization of BTC

This is where @babylonlabs_io comes into focus. Babylon enables BTC holders to stake their Bitcoin natively on the Bitcoin network and participate in validating other PoS protocols, earning additional rewards.

Thanks to the advantage of utilizing BTC without additional trust assumptions, Babylon has rapidly achieved over $5 billion in TVL. The TVL could have been even higher if there were no staking limits on BTC.

But wait, Bitcoin’s scripting language is non-Turing complete, meaning it cannot easily support complex smart contracts. So, how does Babylon manage to achieve this functionality? In this article, we will explore the specific mechanisms behind Babylon’s operation.

2. Babylon

Like building the Tower of Babel, can we ever reach true native BTC utilization?

2.1 Babylon Overview

Babylon’s mission is scaling Bitcoin to secure the decentralized world. While it is widely known as a BTC staking protocol, Babylon also offers Bitcoin timestamping services, forming a suite of BTC security-sharing protocols.

Babylon is composed of two main protocols:

• Bitcoin Timestamping: This allows PoS chains to checkpoint their block data onto the Bitcoin network. By doing so, PoS chains can mitigate long-range attacks, reduce stake unbonding periods, protect critical transactions, and benefit from Bitcoin’s censorship resistance at the network level.
• Bitcoin Staking: This enables BTC holders to freeze their BTC natively on the Bitcoin network and participate in the validation of other PoS protocols, earning additional rewards in the process.

2.2 Babylon Architecture

(Source: Babylon)

The fundamental architecture of Babylon is illustrated in the diagram above, with the Babylon Chain, built on the Cosmos SDK, at its core. In addition to the Babylon Chain, several peripheral programs facilitate BTC staking and communication with Bitcoin and other Consumer Zones. Consumer Zones refer to PoS chains that record checkpoints on the Bitcoin network through Babylon.

The Babylon Chain consists of various modules that perform essential functions within the ecosystem, including managing the validator set, tracking Bitcoin block headers, submitting checkpoints to the Bitcoin network, and managing the active finality provider set related to BTC staking. For reference, a finality provider is similar to an AVS operator in EigenLayer, meaning it participates in validating other PoS protocols.

Additionally, Babylon has implemented several supporting programs to facilitate smooth communication between the Bitcoin network and the Babylon Chain:

• Vigilantes: A suite of programs that acts as a data relayer between Bitcoin and Babylon.
• Monitors: A suite of programs that ensures the consistency between the Babylon Chain and the Bitcoin network.

Through this ecosystem, Babylon enables the crypto industry to leverage Bitcoin’s strong security and deep liquidity. Now, let’s explore Babylon’s two core features in more detail: Bitcoin Timestamping and Bitcoin Staking.

3. How Bitcoin Timestamping Works

3.1 Why is Stake Unbonding Slow?

Anyone who has staked tokens before would know that unstaking typically requires a waiting period of 1 to 2 weeks. During this time, the tokens cannot be used or earn interest, causing inefficiencies. But why does unstaking require a waiting period? Why not allow instant withdrawals?

The simplest reason is network security. If unstaking were instant, large amounts of tokens could be unstaked in response to market fluctuations, significantly weakening network security. However, beyond security, there is another fundamental reason: to prevent long-range attacks.

3.2 Long-Range Attack

(Source: AP)

A long-range attack refers to an attack in which malicious validators create a new fork starting from past blocks, attempting to replace the current canonical chain. If the malicious forked chain becomes as long as or longer than the canonical chain, newly joining nodes in the network may become confused about which chain is the legitimate one, leading to potential issues. But wait—is this even possible?

In a PoW network, a long-range attack is nearly impossible. To catch up with the current canonical chain, attackers would need to recreate new blocks from the past while exceeding the computing power of the existing network, which is practically infeasible.

Similarly, in a properly functioning PoS network, this attack is also impossible. Creating a new fork would require malicious validators to sign multiple conflicting blocks, which is considered double-signing—a violation of the protocol that results in slashing penalties.

However, what if unstaking were allowed immediately?

Unlike PoW networks, PoS networks do not require massive computational power to generate blocks. This means that if malicious validators unstake their assets from the existing chain and then create a new forked chain from a past block where their validator keys were still valid, they could potentially catch up with the current canonical chain. In this scenario, newly joining nodes in the network might struggle to determine which chain is the legitimate one, leading to potential confusion and security risks.

(Source: Babylon)

If a long-range attack succeeds, malicious validators can exploit bridging mechanisms to steal funds. For example, suppose a malicious attacker named John transfers 1M RUG tokens from the RugPull chain to Osmosis and exchanges them for OSMO tokens. This transfer happens through IBC, which works by locking the original RUG tokens on the RugPull chain while minting an equivalent amount of RUG tokens on the Osmosis chain.

(Source: Babylon)

If we assume that John successfully executes a long-range attack on the RugPull chain, he can maliciously omit the transaction that locked RUG tokens to send them to the Osmosis chain in the new forked chain. As a result, John would effectively acquire OSMO tokens for free.

To prevent long-range attacks, a stake unbonding period of a certain length is necessary. Malicious actors cannot execute a long-range attack during the unbonding period (if they attempt it, they will face slashing penalties). Additionally, during this period, network participants can reach a social consensus regarding which chain is the canonical chain. As a result, even if a long-range attack occurs later, the malicious forked chain is unlikely to be accepted by the network.

3.3 Let’s Reduce Stake Unbonding Time with BTC Timestamping

The stake unbonding period is an effective method for preventing long-range attacks, but it comes with some drawbacks.

The first issue is that it relies on social consensus to counteract attacks. While off-chain communication among participants over a long enough period can play a crucial role, it is not a 100% foolproof solution.

The second issue is that, as mentioned earlier, a longer unstaking period negatively affects user experience and liquidity.

Babylon introduces a solution called Bitcoin Timestamping, which enables PoS chains to significantly reduce unstaking periods to just a few hours. This allows PoS chains to record canonical chain block data onto the Bitcoin network.

With timestamping, even if malicious validators attempt a long-range attack and claim their forked chain is the canonical chain, their attack will not succeed—because the original canonical chain data is already securely recorded on the Bitcoin network. As long as Bitcoin’s security remains intact, the attack is guaranteed to fail. Since this approach eliminates the need for social consensus, it allows for a drastic reduction in the required unbonding period.

(Source: Babylon)

Here, Bitcoin Timestamping is recorded using the OP_RETURN opcode in the Bitcoin network. OP_RETURN is an instruction that allows storing up to 80 bytes of arbitrary data on the Bitcoin network. Unlike regular Bitcoin transactions, OP_RETURN cannot be used for fund transfers and does not generate UTXOs.

One key consideration is whether all PoS chains can directly create checkpoints on the Bitcoin network. Bitcoin blocks are small in size, have a block time of 10 minutes, and OP_RETURN can only store a maximum of 80 bytes of data. If numerous PoS chains were to send frequent checkpointing transactions, the Bitcoin network would not be able to handle the load.

To solve this issue, Babylon introduces the Babylon Chain, which aggregates checkpoints from multiple PoS chains via IBC and then submits a single aggregated checkpoint to the Bitcoin network.

A key component of this process is the Vigilante Relayer, an entity responsible for reading checkpoints from a Babylon node, packaging them into OP_RETURN transactions, and then submitting them to the Bitcoin network. The system requires at least one honest and live Vigilante Relayer to function properly.

(Source: Babylon)

BTC timestamping occurs as follows: PoS chains submit checkpoints containing block information to the Babylon chain. The Babylon chain then submits a checkpoint of Babylon blocks to the Bitcoin network at the final block of each epoch.

(Source: Babylon)

Even if a long-range attack occurs, the malicious forked chain’s checkpoint will always have a timestamp later than the canonical chain’s checkpoint. This means that network participants can simply check the Bitcoin network’s checkpoint to easily identify malicious forks. Since this approach eliminates the need for social consensus, the stake unbonding period can be reduced from several weeks to just a few hours.

3.4 More Than Fast Stake Unbonding

Babylon’s Bitcoin Timestamping does more than just improve UX and liquidity efficiency by reducing PoS chains’ unstaking periods—it also provides various additional benefits.

3.4.1 Slow Finality for Important Transactions

By adopting slow finality through Babylon, PoS chains can achieve a level of security comparable to Bitcoin. When a PoS block containing a specific transaction is timestamped on the Bitcoin network and confirmed by six Bitcoin blocks, the transaction becomes irreversible—as long as Bitcoin’s security remains intact.

This mechanism is useful for processing high-value transactions, such as real estate purchases, where absolute security is necessary. Additionally, for newly launched Cosmos zones, which may have weaker security, implementing slow finality can provide an extra layer of protection for safe transaction processing.

3.4.2 Bitcoin-Level Censorship Resistance

Bitcoin Timestamping can also help restore liveness in the event of a censorship attack on a PoS chain. To address this, Babylon introduces a special concept called rollup mode.

In a traditional PoS chain, at least two-thirds (2/3) of validators must be honest to maintain censorship resistance. However, with Babylon’s rollup mode, only one-half (1/2) of validators need to be honest to achieve censorship resistance, significantly improving the chain’s resilience against attacks.

(Source: Babylon)

If a PoS chain user believes that a specific transaction is being censored, they can submit a censorship complaint (the red section in the diagram) to the Babylon chain, initiating the process of entering rollup mode. The censorship complaint contains the hash of the censored transaction.

If, after six Bitcoin block confirmations, the suspected censored transaction still hasn’t been included in the PoS chain, honest validators will submit their views of the PoS chain to Babylon. If, after an additional six Bitcoin block confirmations, no checkpoint related to the censored transaction is detected in any Bitcoin block, honest validators and users will enter rollup mode.

In rollup mode, any validator can propose a bundle of PoS transactions, and if validators holding at least one-half (1/2) of the total stake sign the bundle, the transaction will be finalized on the Bitcoin network, effectively preventing censorship.

4. How Bitcoin Staking Works

4.1 Bitcoin Staking Overview

Bitcoin Timestamping allows PoS chains to leverage Bitcoin’s security to reduce stake unbonding periods and enhance censorship resistance, but this only partially utilizes Bitcoin’s security.

Beyond Bitcoin Timestamping, Babylon introduces Bitcoin Staking, which natively implements BTC staking using Bitcoin’s script language. This allows other PoS protocols to benefit from staked BTC’s cryptoeconomic security. The staking protocol is designed as a modular plug-in, making it easily adaptable for various PoS consensus protocols.

For BTC holders, Babylon’s Bitcoin Staking is an attractive investment opportunity since they can stake BTC at Bitcoin’s security level without relying on external entities, while also earning rewards from external protocols.

Let’s define some key terms:

• Protocols that leverage staked BTC’s cryptoeconomic security through Babylon’s Bitcoin Staking are called BSNs (Bitcoin Secured Networks)—analogous to @eigenlayer ‘s AVS (Actively Validated Services) concept.
• Entities that receive delegated BTC from stakers and participate in validating BSNs are called Finality Providers—similar to EigenLayer’s AVS operators.

But wait—unlike Ethereum, the Bitcoin network is not Turing-complete, making it difficult to implement complex staking contracts. So how does Babylon achieve this?

Let’s explore the details with an example from Babylon’s blog.

4.2 How Staking Contract is Implemented

4.2.1 Locking

// Contract V0: adding a locking condition to Alice’s staking UTXO

condition-1 (locking): time_lock = 1000 & alice_public_key

Let’s assume that Alice stakes BTC and also acts as a Finality Provider. To implement BTC staking, a mechanism to lock BTC is required. This is achieved by setting one of the UTXO spending conditions so that only Alice (the BTC owner) can withdraw the funds after a certain time period (time_lock = 1000) using her alice_public_key.

4.2.2 Slashing

// Contract V1: adding naive slashing

condition-1 (locking): time_lock = 1000 & alice_public_key; OR

condition-2 (slashing): alice_eots_public_key

One of the essential components that must be implemented in staking is slashing. If a malicious action occurs, an incentive mechanism can be enforced by burning the staked BTC. To achieve this, a second UTXO spending condition is set so that slashing can occur if someone holds Alice’s EOTS key.

Here, EOTS (Extractable One-Time Signature) is a signature implemented using Schnorr signatures, which was introduced after Bitcoin’s Taproot upgrade. Simply put, it is an algorithm that ensures that if a malicious actor double-signs two different blocks at the same height using the same key, their secret key is publicly revealed.

Looking at this in more detail, a Schnorr signature consists of a private key x, a public key P=xG, and a random nonce k. The signing process is as follows: a random nonce k is generated, and the public value R=kG is computed from the nonce. Then, a hash value e is computed from the message M and R, and the signature value s is computed based on the nonce and e, where s = k + ex. The final Schnorr signature consists of (s, R).

The core idea of EOTS is that if the same key is used twice for signing, the private key is exposed. If Alice signs two different messages using the same nonce k, then the first signature is s1= k + e_1x and the second signature is s2= k + e_2x. Since s1, s2, e1, e2 are publicly known, anyone can solve for Alice’s private key x using the equation x=(s1 - s2)/(e1 - e2).

Using this mechanism, if Alice maliciously signs two different messages using the same EOTS key during the BSN validation process, anyone who detects this can extract Alice’s EOTS secret key. Once the EOTS secret key is revealed, the attacker can either steal Alice’s staked BTC or burn Alice’s staked BTC as a penalty.

4.2.3 Enforcing Burning

// Contract V2

condition-1 (locking): time_lock = 1000 & alice_public_key; OR

condition-2 (slashing): alice_eots_public_key & covenant_committee_quorum

// Slashing transaction V0

inputs:

• input-1: the staking UTXO, spent using condition-2 above

outputs:

• output-1: value = 0.99 Bitcoin, owner = 0000...0000

// Pre-approval V0: enforcing burning

// Covenant committee pre-signs the above slashing tx as its pre-approval

Since we have previously discussed the conditions under which slashing occurs, let’s now examine how slashing is actually enforced. Enforcing slashing is crucial because, if Alice engages in malicious behavior, she might attempt to withdraw her BTC before someone detects the misconduct, extracts her EOTS secret key, and burns her BTC.

To prevent this, slashing must be implemented in a way that forcibly transfers the BTC to a pre-defined burn address (0000…0000). To achieve this, the second UTXO spending condition includes a Covenant Committee Quorum. The Covenant Committee is responsible for verifying whether slashing is legitimate. By incorporating a multi-signature (M-of-N) scheme, the system ensures that Alice cannot unilaterally withdraw her BTC to her own wallet before slashing is executed.

The advantage of this approach is that, as long as Alice behaves honestly, her EOTS signature is never exposed, meaning the Covenant Committee cannot seize her funds. Therefore, Alice does not need to trust the Covenant Committee, as they cannot act against her unless she engages in malicious behavior.

4.2.4 Safe Delegation

// Contract V3: enabling safe delegation

condition-1 (locking): time_lock = 1000 & alice_public_key; OR

condition-2 (slashing): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Slashing transaction V0

inputs:

• input-1: the staking UTXO, spent using condition-2 above

outputs:

• output-1: value = 0.99 Bitcoin, owner = 0000...0000

// Pre-approval V1

// Alice pre-signs the slashing tx as her pre-approval.

// Covenant committee pre-signs the slashing tx as its pre-approval.

Alice can directly stake BTC and participate in validating other PoS protocols as a finality provider. However, most users will choose to delegate their BTC staking.

To implement this, adding the validator’s EOTS key to the second condition ensures that if the validator engages in malicious behavior, Alice’s BTC can be burned. However, the issue here is that if the validator colludes with the covenant committee, they could steal Alice’s BTC, forcing Alice to trust the validator.

A simple solution to this problem is to also include Alice’s public key in the second condition. This way, burning BTC would require Alice’s signature as well, preventing unauthorized BTC theft.

To achieve this, Alice pre-signs a transaction stating that “if slashing occurs, BTC must be sent to a burn address.” In this case, if the validator acts maliciously and their EOTS key is exposed, and if the covenant committee executes a multi-signature, the BTC will be sent to the burn address, enforcing the slashing process.

4.2.5 Preventing Malicious Attack with Enforcing Atomic Slashing

/ Contract V3

condition-1 (locking): time_lock = 1000 & alice_public_key; OR

condition-2 (slashing): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Slashing transaction V0

inputs:

• input-1: the staking UTXO, spent using condition-2 above

outputs:

• output-1: value = 0.99 Bitcoin, owner = 0000...0000

// Pre-approval V2: enforcing atomic slashing when delegate

// Alice’s pre-approval is an adaptor signature of the slashing tx

// she generated using the validator’s EOTS public key.

// Covenant committee pre-signs the slashing tx as its pre-approval.

What if a malicious validator targets only specific stakers for slashing? To prevent this, Babylon introduces Adaptor Signatures.

Alice encrypts her signature using the validator’s EOTS public key as an adaptor signature. If the validator attempts to slash only Alice, they must use their EOTS private key. Due to the nature of Adaptor Signatures, this would result in the exposure of the validator’s EOTS private key, removing any incentive for validators to engage in malicious behavior.

4.2.6 Implementing Partial Slashing

// Contract V3

condition-1 (locking): time_lock = 1000 & alice_public_key; OR

condition-2 (slashing): alice_public_key & validator_eots_public_key & covenant_committee_quorum

// Slashing transaction V1: enabling partial slashing

inputs:

• input-1: the staking UTXO, spent using condition-2 above

outputs:

• output-1: value = 0.09 Bitcoin, owner = 0000...0000

• output-2: value = 0.9 Bitcoin,

conditions:

• condition-1: time_lock = 500 & alice_public_key

// Pre-approval V2

// Alice’s pre-approval is an adaptor signature of the slashing tx

// she generated using the validator’s EOTS public key.

// Covenant committee pre-signs the slashing tx as its pre-approval.

But don’t you think burning all the Bitcoin in the event of slashing is too extreme? To address this, only a portion of the Bitcoin (e.g., burning just 10% while returning the remaining 90% after a certain period) can be burned. This can be implemented by splitting the outputs of the slashing transaction into two, as described above.

4.2.7 Restaking More!

// Contract V4: Enabling restaking

condition-1 (locking): time_lock = 1000 & alice_public_key; OR

condition-2 (slashing): alice_public_key & any signature from list[validator_eots_public_key] & covenant_committee_quorum

Alice’s delegated BTC can participate in the validation of multiple PoS protocols, not just a single one. If a validator participates in the validation of different PoS protocols using the same EOTS key, any leakage in one place could affect the other systems. Therefore, Babylon’s finality providers must use different EOTS keys for different PoS systems, and a list of EOTS keys is introduced in the second condition.

4.3 Summary

Unlike PoS networks such as Ethereum or Solana, Bitcoin’s network operates on PoW, so the concept of staking doesn’t inherently exist. However, Babylon has implemented BTC locking, slashing, and delegation features necessary for staking through the characteristics of UTXOs, Bitcoin’s scripting language, and various signature algorithms. This allows BTC holders to earn additional profits natively by utilizing BTC, without needing bridges or custody services.

5. Unleashing BTC’s Potential to the Decentralized World

Aside from the Lightning Network, no other protocol fully inherits the security of the Bitcoin network. However, just like the Bitcoin network, the functionality of the Lightning Network is quite limited, and it’s too precious to give up Bitcoin’s robust security and massive liquidity.

Babylon has enabled the use of Bitcoin’s security in two different ways through Bitcoin Timestamping and Bitcoin Staking. The former uses Bitcoin as a timestamp server to prevent transaction reverts or malicious forks, while the latter leverages BTC’s powerful liquidity as crypto-economic security, allowing BTC holders to earn additional profits in a native way.

Currently, approximately 55,000 BTC are deposited in Babylon, which is even with a deposit cap set by Babylon. Around 3.9% of the total ETH supply is re-staked on EigenLayer. Considering this, even though BTC holders may be conservative about utilizing BTC, the growth potential of Babylon, with only around 0.2% of the total BTC supply currently staked, is worth considering.

Disclaimer:

1. This article is reprinted from [100y.eth]. All copyrights belong to the original author [100y.eth]. If there are objections to this reprint, please contact the Gate Learn team, and they will handle it promptly.
2. Liability Disclaimer: The views and opinions expressed in this article are solely those of the author and do not constitute any investment advice.
3. The Gate Learn team does translations of the article into other languages. Copying, distributing, or plagiarizing the translated articles is prohibited unless mentioned.