Assessment reportsPublic findings
Back to Zellic site
↗
Assessment reports>Babylon Genesis Chain>Design>btc-staker
GeneralOverview
Findings
Critical (10)
High (4)
Medium (4)
Low (7)
Informational (7)
DiscussionBabylon node module-wise reviewed parametersDependency management and vulnerability assessmentPanic handling in ABCI++ handlersBehavior of MissedBlocksCounter on consecutive windows
DesignModule: btclightclientModule: btccheckpointModule: checkpointingModule: epochingModule: finalityModule: incentiveModule: monitorModule: mintModule: btcstakingbtc-stakerstaking-expiry-checkerbtc-staking-tsVigilante reporterVigilante submitterVigilante monitor (BTC timestamping monitor)Vigilante BTC staking trackerCryptographyFinality providerCovenant emulatorModule: staking-queue-clientstaking-api-servicebabylon-staking-indexersimple-staking
Audit ResultsAssessment Results
AddendumAddendumNonce reuse in adaptor signatures allows recovering signing key testsKey recovery succeeding on output from a btc-delegations query test

btc-staker

Description

This toolset is designed for seamless Bitcoin staking by managing staking transactions, interacting with the Bitcoin network, and monitoring system performance. It is composed of several modules:

  • stakerd — the core daemon responsible for managing staking transactions, processing verification requests, and monitoring system health

  • staker-cli — a command-line interface for users to interact with the staking system

  • stakerservice — handles staking logic, validation, and transaction management

  • walletcontroller — manages interactions with Bitcoin wallets, transaction signing, and unspent transaction output (UTXO) management

  • metrics — collects and exposes system performance metrics via Prometheus

  • stakercfg — manages system configuration and provides settings for the modules

Each module works together to facilitate the staking process securely and efficiently.

Invariants

  • All staking transactions must comply with predefined staking rules, including amount, duration, and output constraints.

  • The system ensures that UTXOs are correctly tracked and managed.

  • Transactions must be signed correctly before broadcasting to the Bitcoin network.

  • The system must always reflect the correct staking status based on blockchain data.

These invariants are enforced through transaction validation, UTXO checks, cryptographic signing, and real-time blockchain synchronization.

Test coverage

Cases covered

  • Staking transaction creation — validating user input for staking transactions, ensuring transactions comply with network parameters, and successfully creating staking transactions

  • Transaction signing and broadcasting — ensuring valid transactions are signed correctly and verifying transactions are broadcasted and confirmed on the Bitcoin network

  • UTXO and balance management — correctly handling UTXO selection and balance updates and validating that staking rewards are correctly allocated

Cases not covered

  • There are no specific tests for handling large numbers of concurrent staking transactions.

Attack surface

Attackers could try to input invalid staking amounts or durations. The system mitigates this by strict validation rules.

Transactions could be altered before broadcasting. This is prevented by signing transactions and verifying signatures before submission.

An attacker could try to double-spend or manipulate UTXOs. The system mitigates this by checking UTXO consistency before every transaction.

Zellic © 2025Back to top ↑