Covenant Emulation Toolset

Overview

The covenant emulation toolset is a set of programs operated by every member of the covenant committee of the BTC staking protocol. The role of the covenant committee is to protect PoS systems against attacks from the BTC stakers and validators. It achieves this by representing itself as an M-out-of-N multi-signature that co-signs BTC transactions with the BTC staker.

More specifically, through co-signing, the covenant committee enforces the following three spending rules of the staked bitcoins, the equivalence of which is common for PoS systems:

1. If the staker is malicious and gets slashed, the percentage of the slashed bitcoins must satisfy the protocol's fractional slashing percentage.

2. If the staker is malicious and gets slashed, the destination address of the slashed bitcoins must be the unique slashing address specified by the protocol, not any other address.

3. when the staker unbonds, the unbonding time must be no shorter than the protocol's minimum stake unbonding time.

Besides enforcing rules via co-signing, the covenant committee has no other duty or power. If it has a dishonest super majority, then

• it can:

  • refuse to co-sign, so that no bitcoin holders can stake. In this case, no bitcoin will be locked because the protocol requires the committee to pre-sign all the transactions, and

  • collude with the stakers, so that the staker can dodge slashing.

• it cannot:

  • steal the staker’s bitcoins, because all the spending transactions require the staker's signature;

  • slash the staker’s bitcoins by itself, because slashing requires the secret key of the finality provider, which the covenant committee does not know in advance, and

  • prevent the staker from unbonding or withdrawing their bitcoins, again, because the protocol requires the committee to pre-sign all the transactions.

In other words, there is no way the committee can act against the stakers, except rejecting their staking requests. Furthermore, the dishonest actions of the covenant committee can be contained by 1) including the staker’s counterparty in the committee, such as the PoS system’s foundation, or 2) implementing a governance proposal to re-elect the committee.

This rule-enforcing committee is necessary for now because the current BTC protocol does not have the programmability needed to enforce these rules by code. This committee can be dimissed once such programmability becomes available, e.g., if BTC's covenant proposal BIP-119 is merged.

Covenant emulation committee members are defined in the Babylon parameters and their public keys are recorded in the genesis file of the Babylon chain. Changing the covenant committee requires a governance proposal. Each committee member runs two components:

1. The covd daemon (short for covenant-emulator-daemon), which constantly monitors staking requests on the Babylon chain, verifies the validity of the Bitcoin transactions that are involved with them, and sends the necessary signatures if verification is passed.
2. The covenant-signer daemon, which securely manages the private key and performs signing operations in an isolated environment.

The staking requests can only become active and receive voting power if a sufficient quorum of covenant committee members have verified the validity of the transactions and sent corresponding signatures.

Covenant Emulator Daemon

Upon a pending staking request being found, the covenant emulation daemon (covd), validates it against the spending rules defined in Staking Script specification, and sends three types of signatures to the Babylon chain:

1. Slashing signature. This signature is an adaptor signature, which signs over the slashing path of the staking transaction. Due to the recoverability of the adaptor signature, it also prevents a malicious finality provider from irrationally slashing delegations.
2. Unbonding signature. This signature is a Schnorr signature, which is needed for the staker to unlock their funds before the original staking time lock expires (on-demand unbonding).
3. Unbonding slashing signature. This signature is also an adaptor signature, which has similar usage to the slashing signature but signs over the slashing path of the unbonding transaction.

For instructions on how to run the Covenant Emulator, please refer to the Covenant Emulator.

Covenant Signer

The Covenant Signer operates in tandem with the Covenant Emulator and is purpose-built to securely manage private keys for signing operations. It prioritizes security through isolation, ensuring that private key handling is confined to an instance with minimal connectivity and simpler application logic compared to the Covenant Emulator daemon.

Previously, private keys were stored in the Bitcoin wallet using PSBT (Partially Signed Bitcoin Transactions) for signing operations. The new design uses a dedicated Covenant Signer that acts as a remote signing service, storing private keys in an encrypted Cosmos SDK keyring. This approach not only improves security through isolation but also enables the creation of both Schnorr signatures and Schnorr adaptor signatures required for covenant operations.

For instructions on how to run the Covenant Signer, please refer to the Covenant Signer.

Interaction Between Emulator and Signer

The Covenant Emulator handles the application logic, including monitoring the Babylon blockchain and validating transactions. When a signature is needed, it forwards the request to the Covenant Signer, which processes the signing operation and returns the necessary cryptographic signature.

The interaction begins with the Covenant Emulator monitoring the Babylon blockchain for new staking requests. The emulator then prepares the necessary signing data, which includes transactions requiring slashing signatures (adaptor signatures), unbonding signatures (Schnorr signatures), and unbonding slashing signatures (adaptor signatures). This data is then forwarded to the Covenant Signer.

This flow ensures that all private key operations remain isolated within the secure Covenant Signer while the emulator handles the blockchain interaction and validation logic.