Recently, Babylon has launched the staking activity on Testnet-4. Chakra has become the Top 1 finality provider in Babylon Testnet-4, confirming a TVL of 258 Signet BTC, which accounts for 36% of Babylon's total TVL. We appreciate the trust users have placed in us by delegating their BTC to Chakra!

Today, Chakra will guide you through what exactly happens when you stake your BTC through Babylon and delegate your voting rights to Chakra.

In the latest Testnet-4 of Babylon, the staking process is divided into three types of transactions: Staking Tx, Unbonding Tx, and Slashing Tx. These transactions generate three types of Bitcoin outputs respectively: Staking Output, Unbonding Output, and Slashing Output. The transformation process is illustrated in the diagram below.

A staking transaction has to include two special outputs. One is the output holding the staked assets, which is of the Taproot type and must contain the BTC staking scripts defined by Babylon. The other is a zero amount output that holds information recognisable by Babylon staking via an OP_RETURN.

The diagram below shows an example of a Staking Transaction, where the first output is the Staking Output, the second is the OP_RETURN Output, and the third is a change output.

Staking Output is a Taproot output, as previously mentioned in a crypto 101 article by Chakra:

Taproot outputs have two payment methods: key spending path and script spending path. Babylon disables the key spending path by setting the internal key to a "Nothing Up My Sleeve" (NUMS) point, making the Staking Output only spendable via the script spending path.

Staking Output can be spent by three script paths, corresponding to the process diagram:

1、Timelock Path

The Timelock Path implements the staking feature and also serves as a liveness assurance.

<Staker_PK> OP_CHECKSIGVERIFY <Timelock_Blocks> OP_CHECKSEQUENCEVERIFY

The Timelock script locks the staker's BTC for a specified duration, denoted by a number of blocks. No other entities are required in the Timelock Path, thus it provides a liveness guarantee for the staker. Even if the Finality Provider and Covenant become inactive, the staker can still retrieve their BTC assets after the lock period expires.

2、Unbonding Path

How can a user end their staking early if the BTC is locked by a timelock? Babylon addresses this issue by introducing an Unbonding Path.

<StakerPk> OP_CHECKSIGVERIFY
<CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD
<CovenantThreshold> OP_NUMEQUAL

This path requires not only the signature of the Staker but also signatures from more than the CovenantThreshold number of members from the covenant committee. The main reason for introducing the covenant committee is to artificially create an unbonding period, preventing the staker from avoiding punishment by escaping through the Unbonding Path before being slashed.

3、Slashing Path

Slashing is a crucial factor for ensuring the security of PoS. If the Finality Provider acts maliciously, it is necessary to confiscate both their own and delegated funds to provide economic security. Babylon provides the slashing functionality by introducing a Slashing Path.

<StakerPk> OP_CHECKSIGVERIFY
<FinalityProviderPk> OP_CHECKSIGVERIFY
<CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD
<CovenantThreshold> OP_NUMEQUAL

Before the stake becomes Active, the staker must pre-sign the Slashing Path transaction to prevent withholding their signature to avoid BTC loss in case the Finality Provider acts maliciously. After receiving the staker's signature, the Covenant committee first verifies it and, once confirmed as valid, will release their own signatures.

The slashable offence in BTC staking is that the finality provider signs two conflicting blocks at the same height, enabling any user to obtain the malicious Finality Provider's private key via EOTS. Because the staker and the covenant have already pre-signed the Slashing Tx, users who obtain the malicious Finality Provider's private key can then sign the transaction to send a portion of the staked funds to a burn address as a penalty through the Slashing Path.

While Taproot outputs express complex usage conditions with smaller ScriptPubKeys, It's challenging to distinguish between staking transactions and other transactions in the Bitcoin network. Therefore, it is necessary to disclose the staking-related information through other means so that users can identify the slashing Tx based on this information.

Babylon serializes the information that needs to be disclosed, embeds the information in an OP_RETURN script, and attaches the script in another output of the staking tx. The format is shown in the diagram below, and the data must correspond to the data in the Taproot script.

type V0OpReturnData struct {
    MagicBytes                []byte
    Version                   byte
    StakerPublicKey           []byte
    FinalityProviderPublicKey []byte
    StakingTime               []byte
}

Based on previous transaction snapshots, the valid data carried by the OP_RETURN Output indeed totals 4+1+32+32+2=71 Bytes. In the diagram, the FinalityProviderPublicKey of the staking transaction is f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81, which belongs to Chakra.

The MagicBytes are used for quickly locating the staking Tx, while the Version is a field reserved for future updates to facilitate differentiation.

When a staker wants to prematurely unlock their staked BTC, they can do so by spending through the unbonding path in the staking output, submitting an unbonding Tx. The unbonding Tx requires that it only takes a single staking Tx as input and outputs a single Taproot output committing to unbonding scripts.

Below is a screenshot of an unbonding Tx, which corresponds to the previous staking output.

In the screenshot, the penultimate field starting with '20' represents the unbonding path's tapscript, and the one starting with 'c1' is the Taproot Internal Key and the Merkle Proof for the unbonding path. Here, it is evident that the NUMS point 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0 is observed. In the Witness field of the Unbonding Tx, we can observe the signature of the staker and the signatures of the Covenant committee.

The unbonding output can be spent under two conditions: the Timelock path and the Slashing path, both of which are identical to those in the Staking output. On a higher level, the Unbonding output is an intermediate state set up to prevent stakers from immediately withdrawing their stake and evading a slash, ultimately leading to the stable state of a Withdrawal Tx.

A Slashing Tx takes a staking Tx or an unbonding Tx as input, spends through the Slashing Path in the Taproot script, and produces two outputs. One output sends a portion of the staked BTC to a burn address, while the other returns the remaining BTC to the staker.

In a stricter sense, Babylon implements partial confiscation for misconduct rather than burning all the BTC staked by the staker at once. This approach provides higher fault tolerance and protects the interests of the staker.

A Slashing Tx can only occur with the joint signature of the staker, the Covenant Committee, and the Finality Provider. Thus, even if an individual party is compromised, it will not lead to the collapse of the entire staking system. The Slashing Tx serves as a deterrent, economically disincentivizing participants from acting maliciously. As long as the penalties for misconduct exceed any potential gains, participants are likely to adhere to the rules.

There are two types of security associated with Babylon.

The first type of security pertains to the stakers, ensuring that as long as the staker and the finality provider he delegates to do not perform any malicious action, his staked assets will never be slashed.

The second type of security relates to the PoS system itself, guaranteeing that if participants act maliciously, then the protocol must be able to identify and slash them.

For stakers, once BTC is staked through Babylon's staking Tx, there are only three ways the funds can be transferred.

The first is the Timelock Path, which requires only the user's own signature for spending. This ensures that even if the FP and Babylon cease operations, stakers can still reclaim their original BTC after the staking period expires.

The second is the Unbonding Path, which serves as an intermediate state, creating an Unboding Output and allowing a shorter unlocking time. This provides stakers with the functionality to retrieve their staked funds ahead of schedule.

The third is the Slashing Path, the only route that can harm the interests of stakers. If external parties attempt to attack the Slashing Path, they must simultaneously provide the staker’s signature, the Finality Provider’s signature, and signatures from the Covenant Committee exceeding the threshold, which is extremely difficult to achieve. Even if covenant committee is malicious, as long as FP is honest then staker's BTC is safe.

From the perspective of the PoS system, its security arises from the ability to slash the Finality Provider when they act maliciously.

Babylon employs the EOTS mechanism, where if the Finality Provider double-signs a block, any user can extract the Finality Provider's private key from these two differing signatures on the same block. This allows them to sign and submit a Slashing Tx, partially slashing the BTC corresponding to all the voting rights held by the Finality Provider.

This punitive measure disincentivizes the Finality Provider from acting maliciously, thereby aligning their incentive to provide finality for the PoS consensus services connected to Babylon, securing the PoS system with a substantial staked TVL.

In the future, Chakra will continue to collaborate with Babylon to launch a series of staking activities, offering users multiple yields while addressing liquidity and interoperability challenges, unleashing the immense value of Bitcoin across all crypto ecosystems.

Recently, Babylon has launched the staking activity on Testnet-4. Chakra has become the Top 1 finality provider in Babylon Testnet-4, confirming a TVL of 258 Signet BTC, which accounts for 36% of Babylon's total TVL. We appreciate the trust users have placed in us by delegating their BTC to Chakra!

Today, Chakra will guide you through what exactly happens when you stake your BTC through Babylon and delegate your voting rights to Chakra.

In the latest Testnet-4 of Babylon, the staking process is divided into three types of transactions: Staking Tx, Unbonding Tx, and Slashing Tx. These transactions generate three types of Bitcoin outputs respectively: Staking Output, Unbonding Output, and Slashing Output. The transformation process is illustrated in the diagram below.

A staking transaction has to include two special outputs. One is the output holding the staked assets, which is of the Taproot type and must contain the BTC staking scripts defined by Babylon. The other is a zero amount output that holds information recognisable by Babylon staking via an OP_RETURN.

The diagram below shows an example of a Staking Transaction, where the first output is the Staking Output, the second is the OP_RETURN Output, and the third is a change output.

Staking Output is a Taproot output, as previously mentioned in a crypto 101 article by Chakra:

Taproot outputs have two payment methods: key spending path and script spending path. Babylon disables the key spending path by setting the internal key to a "Nothing Up My Sleeve" (NUMS) point, making the Staking Output only spendable via the script spending path.

Staking Output can be spent by three script paths, corresponding to the process diagram:

1、Timelock Path

The Timelock Path implements the staking feature and also serves as a liveness assurance.

<Staker_PK> OP_CHECKSIGVERIFY <Timelock_Blocks> OP_CHECKSEQUENCEVERIFY

The Timelock script locks the staker's BTC for a specified duration, denoted by a number of blocks. No other entities are required in the Timelock Path, thus it provides a liveness guarantee for the staker. Even if the Finality Provider and Covenant become inactive, the staker can still retrieve their BTC assets after the lock period expires.

2、Unbonding Path

How can a user end their staking early if the BTC is locked by a timelock? Babylon addresses this issue by introducing an Unbonding Path.

<StakerPk> OP_CHECKSIGVERIFY
<CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD
<CovenantThreshold> OP_NUMEQUAL

This path requires not only the signature of the Staker but also signatures from more than the CovenantThreshold number of members from the covenant committee. The main reason for introducing the covenant committee is to artificially create an unbonding period, preventing the staker from avoiding punishment by escaping through the Unbonding Path before being slashed.

3、Slashing Path

Slashing is a crucial factor for ensuring the security of PoS. If the Finality Provider acts maliciously, it is necessary to confiscate both their own and delegated funds to provide economic security. Babylon provides the slashing functionality by introducing a Slashing Path.

<StakerPk> OP_CHECKSIGVERIFY
<FinalityProviderPk> OP_CHECKSIGVERIFY
<CovenantPk1> OP_CHECKSIG <CovenantPk1> OP_CHECKSIGADD ... <CovenantPkN> OP_CHECKSIGADD
<CovenantThreshold> OP_NUMEQUAL

Before the stake becomes Active, the staker must pre-sign the Slashing Path transaction to prevent withholding their signature to avoid BTC loss in case the Finality Provider acts maliciously. After receiving the staker's signature, the Covenant committee first verifies it and, once confirmed as valid, will release their own signatures.

The slashable offence in BTC staking is that the finality provider signs two conflicting blocks at the same height, enabling any user to obtain the malicious Finality Provider's private key via EOTS. Because the staker and the covenant have already pre-signed the Slashing Tx, users who obtain the malicious Finality Provider's private key can then sign the transaction to send a portion of the staked funds to a burn address as a penalty through the Slashing Path.

While Taproot outputs express complex usage conditions with smaller ScriptPubKeys, It's challenging to distinguish between staking transactions and other transactions in the Bitcoin network. Therefore, it is necessary to disclose the staking-related information through other means so that users can identify the slashing Tx based on this information.

Babylon serializes the information that needs to be disclosed, embeds the information in an OP_RETURN script, and attaches the script in another output of the staking tx. The format is shown in the diagram below, and the data must correspond to the data in the Taproot script.

type V0OpReturnData struct {
    MagicBytes                []byte
    Version                   byte
    StakerPublicKey           []byte
    FinalityProviderPublicKey []byte
    StakingTime               []byte
}

Based on previous transaction snapshots, the valid data carried by the OP_RETURN Output indeed totals 4+1+32+32+2=71 Bytes. In the diagram, the FinalityProviderPublicKey of the staking transaction is f4940b238dcd00535fde9730345bab6ff4ea6d413cc3602c4033c10f251c7e81, which belongs to Chakra.

The MagicBytes are used for quickly locating the staking Tx, while the Version is a field reserved for future updates to facilitate differentiation.

When a staker wants to prematurely unlock their staked BTC, they can do so by spending through the unbonding path in the staking output, submitting an unbonding Tx. The unbonding Tx requires that it only takes a single staking Tx as input and outputs a single Taproot output committing to unbonding scripts.

Below is a screenshot of an unbonding Tx, which corresponds to the previous staking output.

In the screenshot, the penultimate field starting with '20' represents the unbonding path's tapscript, and the one starting with 'c1' is the Taproot Internal Key and the Merkle Proof for the unbonding path. Here, it is evident that the NUMS point 0x50929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0 is observed. In the Witness field of the Unbonding Tx, we can observe the signature of the staker and the signatures of the Covenant committee.

The unbonding output can be spent under two conditions: the Timelock path and the Slashing path, both of which are identical to those in the Staking output. On a higher level, the Unbonding output is an intermediate state set up to prevent stakers from immediately withdrawing their stake and evading a slash, ultimately leading to the stable state of a Withdrawal Tx.

A Slashing Tx takes a staking Tx or an unbonding Tx as input, spends through the Slashing Path in the Taproot script, and produces two outputs. One output sends a portion of the staked BTC to a burn address, while the other returns the remaining BTC to the staker.

In a stricter sense, Babylon implements partial confiscation for misconduct rather than burning all the BTC staked by the staker at once. This approach provides higher fault tolerance and protects the interests of the staker.

A Slashing Tx can only occur with the joint signature of the staker, the Covenant Committee, and the Finality Provider. Thus, even if an individual party is compromised, it will not lead to the collapse of the entire staking system. The Slashing Tx serves as a deterrent, economically disincentivizing participants from acting maliciously. As long as the penalties for misconduct exceed any potential gains, participants are likely to adhere to the rules.

There are two types of security associated with Babylon.

The first type of security pertains to the stakers, ensuring that as long as the staker and the finality provider he delegates to do not perform any malicious action, his staked assets will never be slashed.

The second type of security relates to the PoS system itself, guaranteeing that if participants act maliciously, then the protocol must be able to identify and slash them.

For stakers, once BTC is staked through Babylon's staking Tx, there are only three ways the funds can be transferred.

The first is the Timelock Path, which requires only the user's own signature for spending. This ensures that even if the FP and Babylon cease operations, stakers can still reclaim their original BTC after the staking period expires.

The second is the Unbonding Path, which serves as an intermediate state, creating an Unboding Output and allowing a shorter unlocking time. This provides stakers with the functionality to retrieve their staked funds ahead of schedule.

The third is the Slashing Path, the only route that can harm the interests of stakers. If external parties attempt to attack the Slashing Path, they must simultaneously provide the staker’s signature, the Finality Provider’s signature, and signatures from the Covenant Committee exceeding the threshold, which is extremely difficult to achieve. Even if covenant committee is malicious, as long as FP is honest then staker's BTC is safe.

From the perspective of the PoS system, its security arises from the ability to slash the Finality Provider when they act maliciously.

Babylon employs the EOTS mechanism, where if the Finality Provider double-signs a block, any user can extract the Finality Provider's private key from these two differing signatures on the same block. This allows them to sign and submit a Slashing Tx, partially slashing the BTC corresponding to all the voting rights held by the Finality Provider.

This punitive measure disincentivizes the Finality Provider from acting maliciously, thereby aligning their incentive to provide finality for the PoS consensus services connected to Babylon, securing the PoS system with a substantial staked TVL.

In the future, Chakra will continue to collaborate with Babylon to launch a series of staking activities, offering users multiple yields while addressing liquidity and interoperability challenges, unleashing the immense value of Bitcoin across all crypto ecosystems.