Babylon Chain Launch (Phase-2) Contest

Connect

Contests

Total Rewards

Status

Scope

Start Time

End Time

Lead Senior Watson

Lead Judge

Contests

Babylon Chain Launch (Phase-2)

Babylon Chain Launch (Phase-2)Sherlock Judging

Phase-2 of the Babylon mainnet will launch a Babylon PoS blockchain as the first Bitcoin Secured Network (BSN). This will be accompanied by the registration of the stakes created during Phase-1 to the Babylon blockchain allowing them to provide finality service for the it and earn PoS rewards for the service.

Details

Scope

If you are integrating tokens, are you allowing only whitelisted tokens to work with the codebase or any complying with the standard? Are they assumed to have certain properties, e.g. be non-reentrant? Are there any types of weird tokens you want to integrate?

The Babylon Phase-2 network will involve two tokens:

Babylon token: A Cosmos SDK token serving as the native token of the Babylon chain. Only the Babylon token can be used for governance and for gas payments.
Bitcoin: Used for Bitcoin staking. It is not bridged or transferred to Babylon. Instead it remains on the Bitcoin ledger and the Babylon blockchain learns about it through associated proofs. Action on the Babylon ledger can lead to the Bitcoin's spending on the Bitcoin blockchain.

Are there any limitations on values set by admins (or other roles) in the codebase, including restrictions on array lengths?

The Babylon x/btclightclient module parameters specify a list of Babylon addresses that are the only ones that can submit Bitcoin headers to the Babylon on-chain Bitcoin light client. If the list is empty, then anyone can submit Bitcoin headers. This parameter is specified for when the Babylon network interacts with the Bitcoin Signet network which has reduced work requirements due to only certain entities being able to produce blocks and therefore a trusted Bitcoin headers reported is required. For the mainnet, this is not the case and the list of allow-listed reporters is expected to be empty so that anyone can act as a reporter.

All APIs, including for transaction submission and querying have public access. There are no Admin or other privileged roles within Babylon.

Bitcoin staking transactions on the Bitcoin ledger should adhere to the parameters specified in the x/btcstaking module. These are Bitcoin-height versioned parameters that even include Bitcoin heights prior to the Babylon chain launch in order to accommodate staking transactions created during phase-1 (which followed versioned parameters in a JSON file, e.g. for the phase-1 mainnet the ones here https://github.com/babylonlabs-io/networks/tree/main/bbn-1/parameters)

Are there any limitations on values set by admins (or other roles) in protocols you integrate with, including restrictions on array lengths?

Are there any off-chain mechanisms involved in the protocol (e.g., keeper bots, arbitrage bots, etc.)? We assume these mechanisms will not misbehave, delay, or go offline unless otherwise specified.

These components are off-chain but in scope and we should cover the cases in which they misbehave.

Listing the major off-chain components and the Github repositories for which their documentation can be found:

Covenant Emulator: https://github.com/babylonlabs-io/covenant-emulator/
Vigilante: https://github.com/babylonlabs-io/vigilante
BTC Staker CLI: https://github.com/babylonlabs-io/btc-staker
Finality Provider: https://github.com/babylonlabs-io/finality-provider

There are also web service components that index blockchain data in order to serve a Bitcoin staking web application.

What properties/invariants do you want to hold even if breaking them has a low/unknown impact?

We want to ensure staked bitcoins cannot be spent outside one of these authorized operations

Unbonding
Slashing
Timelock expiry

Please discuss any design choices you made.

n/a

Please provide links to previous audits (if any).

Phase-1 Audits

Please list any relevant protocol resources.

Docs website: https://docs.babylonlabs.io/docs/introduction/overview
White papers: https://docs.babylonlabs.io/docs/papers
Bitcoin Staking Protocol and Litepaper: https://docs.babylonlabs.io/docs/introduction/btc-staking
Introductory reading: Bitcoin staking 101 Series
https://babylonlabs.io/blog/what-is-bitcoin-staking
https://babylonlabs.io/blog/technical-preliminaries-of-bitcoin-staking
https://babylonlabs.io/blog/babylon-s-bitcoin-staking-contract
Bitcoin Staking Scripts: https://github.com/babylonlabs-io/babylon/blob/main/docs/staking-script.md
Testnet Information: https://github.com/babylonlabs-io/networks/tree/main/bbn-test-5
Wallet integration guide.
Finality providers registration guide
CometBFT Validators registration guide.
Stake Registration Eligibility Criteria.
Registering phase-1 stakes with the staker CLI.
Bitcoin Stake Registration.

Additional audit information.

Focus Points:

Protection of staked Bitcoins against theft or freezing.
Correct and secure implementation of the Bitcoin Staking and Unbonding Scripts with only the expected paths being executable.
Correct and secure implementation of slashing and finality provider voting.
Cryptography implementation and their correct usage:
https://github.com/babylonlabs-io/babylon/tree/main/crypto
Transition from phase-1 to phase-2

Impact Descriptions:

Blockchain/DLT

High

Direct loss of funds
Permanent freezing of funds
Causing the chain to halt/panic
Causing an honest finality provider to sign two conflicting messages using the same EOTS randomness leading to key exposure.
Retrieve the BTC private key of a covenant
Inability for a non-malicious covenant to submit signatures for valid staking registrations for more than 24h.
Leakage of the EOTS private key without signing conflicting votes/messages (double-signing)
Ability to slash a single delegation without the delegatee's EOTS private key getting exposed
Generation of invalid keys for validators or finality providers
Generation of invalid signatures/Invalid verification of signatures for validators or finality providers
Generation of unbonding, withdrawal, or slashing transactions that cannot be confirmed by the Bitcoin ledger
Inability to slash BTC stake for which the voting power was involved in double-signing.
Temporary freezing of funds for more than the timelock of the corresponding staking, unbonding, or slashing transaction.
Babylon node recognising staking registration with invalid staking protocol transactions as valid.
Causing finality to permanently stall
Native staking operations being executed inside an epoch instead of at the end of it
Babylon node getting notified about a stake being on-demand unbonded in more than 24h
Causing >= 1/3 of finality voting power to skip voting for a block.
Causing the chain to not receive Bitcoin headers for the light client for more than 24h
Causing the vigilante submitter to not submit Bitcoin timestamps on Bitcoin for more than 24h

Medium

Generation of staking transactions that cannot be confirmed by the Bitcoin ledger
Causing finality to temporarily stall
Babylon node getting notified about a stake being on-demand unbonded in more than 3h
Causing \<1/3 of finality voting power to skip voting for a block.
Causing the chain to not receive Bitcoin headers for the light client for more than 3h
Causing the vigilante submitter to not submit Bitcoin timestamps on Bitcoin for more than 3h

Web

High

Execute arbitrary system commands
Subdomain takeover with already-connected wallet interaction
Taking state-modifying authenticated actions (with or without blockchain state interaction) on behalf of other users without any interaction by that user, such as: Making trades
Direct theft of user funds or causing their freezing
Retrieve sensitive data/files from a running server, such as: /etc/shadow, database passwords, blockchain keys (this does not include non-sensitive environment variables, open source code, or usernames etc with no operational impact)
Malicious interactions with an already-connected wallet without user interaction, such as: Modifying transaction arguments or parameters, Submitting malicious transactions
Subdomain takeover without already-connected wallet interaction
Taking down the API/website
Injecting/modifying the static content on the target application without JavaScript (persistent), such as: HTML injection without JavaScript, Replacing existing text with arbitrary text, Arbitrary file uploads etc

Medium

Invalid identification of the state of a stake delegation
Invalid identification of pending rewards
Redirecting users to malicious websites (open redirect)
Changing non-sensitive details of other users (including modifying browser local storage) without already-connected wallet interaction and with up to one click of user interaction, such as their stored pending transactions.
Injecting/modifying the static content on the target application without JavaScript (reflected), such as: Reflected HTML injection, Loading external site data