Assessment reportsPublic findings
Back to Zellic site
↗
Assessment reports>Babylon Genesis Chain>Design>Vigilante BTC staking tracker
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

Vigilante BTC staking tracker

Description

BTC staking tracker is a daemon program that relays information between Babylon and Bitcoin for facilitating the Bitcoin staking protocol. This includes three routines:

  1. Staking Event Watcher↗. Upon observing an unbonding transaction of a BTC delegation on Bitcoin, the routine reports the transaction's signature from the staker to Babylon, such that Babylon will unbond the BTC delegation on its side. Will also monitor for delegations and include the eventual proof.

  2. BTC slasher↗. Upon observing a slashable offense launched by a finality provider, the routine slashes the finality provider and its BTC delegations.

  3. Atomic slasher↗. Upon observing a selective slashing offense where the finality provider maliciously signs and submits a BTC delegation's slashing transaction to Bitcoin, the routine reports the offense to BTC slasher and Babylon.

Invariants

The unbonding watcher, now named Stakingeventwatcher, enforces several invariants:

  • It must wait for the BTC node to be ahead of the Babylon chain; otherwise, the blocks it reads are old.

  • It must send the relevant messages for delegations on the BTC chain & unbonding txs.

The slasher is responsible for the catching validator equivocation, and must ensure that any double signing is caught.

The atomic slasher is responsible for monitoring selective slashing, consequently slashing every single delegation of the relevant FP, it must ensuer that it can correctly parse and retry the slashing for every single delegation of the FP.

Test coverage

Cases covered

  • Fuzzing tests with various randomly generated checkpoints and data, then invariants, are checked to ensure that all the checkpoints are submitted in the correct order.

  • E2E tests of the Staking event watcher ensure that eventually the delegations were uploaded; if they were delegated, the relevant MsgAddBTCDelegationInclusionProof is also sent. Another E2E test verifies the same condition however it also verifies the validity of staking/unbonding TXs in the same block.

  • E2E test, slasher — general actions, shutdown, slashing finality-provider vote equivocation

  • E2E test, atomic slasher — general tests on selective slashing for unbonding/slashing TXs

Attack surface

Due to the large amount of shared functionalities, all the slashers and event watchers have the same relevant possible issues. Any issue that could overload (pagination requests, parsing issues) the slasher could cause it to miss selective slashing, and that would allow selective slashing. It also includes any problem that could cause issues in slashing, especially the submission of relevant messages. Likewise would apply to the Staking Event Watcher missing delegations/undelegations

Zellic © 2025Back to top ↑