Babylon Q2 2025 Genesis v2 Upgrade Audit Report Final

Security Audit Report

BABYLON Q2 2025: GENESIS V2 UPGRADE

Authors: Karolos Antoniadis, Mirel Dal- Last Revised cekovic, Ivan Gavran, Martin Hutle, 2025/06/12 Aleksandar Ljahovic, Andrija Mitro- vic Babylon Q2 2025 Genesis v2 Upgrade

Contents Audit overview 2 The Project . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Scope of this report . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Audit plan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

Audit Dashboard 4 Target Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 Engagement Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 Severity Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

System Overview 6 Integration scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Rewards distribution fix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Event based BTC staking tracker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Unlocking EOTSD keyring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Small fixes, genesis and non functional changes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

Threat Model 8 Event based BTC staking tracker threat model . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Genesis related PRs threat inspection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Rewards distribution, vigilante, EOTSD manager . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Threats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

Findings 20 VIG - Enforce monotonic block height processing on Vigilante . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 VIG - Vigilante processes Babylon Genesis data using unsynchronized block snapshots tracked . . . . . . 23 VIG - Potential duplicate event processing due to overlapping block height ranges . . . . . . . . . . . . . . . 24 VIG - Bootstrapping and block fetching race condition risk . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25 VIG - Suggestion to track UNBONDED and EXPIRED delegation statuses in Vigilante . . . . . . . . . . . . . 27 BAB - Missing validation for haltingHeight smaller than or equal to currentHeight in finality provider halting logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28 BAB - Minor code improvements in x/finality module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29 BAB - ValidateBasic functions explicitly called in x/btcstaking msgServer . . . . . . . . . . . . . . . . . . . . . 30 GEN - Missing validation for epoch existence in SubmissionEntry during InitGenesis . . . . . . . . . . . . . . 31 GEN - Missing Minter validation in InitGenesis of x/mint module . . . . . . . . . . . . . . . . . . . . . . . . . . . 32 GEN - x/btcstaking genesis state is not entirely validated with ValidateGenesis . . . . . . . . . . . . . . . . . 33 FP - A lock missing in getKeyFromMap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34 FP - The TestEotsdUnlockCmd does not test unlocking properly . . . . . . . . . . . . . . . . . . . . . . . . . . . 35 Miscellaneous Comments . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

Appendix: Vulnerability classification 37

Disclaimer 40

Audit overview The Project In May 2025, Babylon Labs has engaged Informal Systems ↗ to conduct a security audit of an upgrade with key features aimed at delivering significant quality-of-life improvements as part of the Babylon Genesis v2 Upgrade. The consultants will provide auditing services for the changes introduced in this upgrade, which have been categorized by priority into four classes, as agreed with the Babylon Labs team.

Scope of this report The scope of this audit is limited to the changes introduced in the pull requests listed in detail in the Audit Dashboard section of this report. Our review and threat modeling efforts are focused exclusively on this new or modified logic. While our analysis centers on the specific code diffs, we have considered the broader context of the Babylon protocol to evaluate how these changes may affect the system as a whole. The pre-existing implementation is considered correct and out of scope for this audit; however, some code outside of the listed PRs was reviewed as necessary to support our threat modeling efforts, though this was not the primary focus of our review. The newly introduced changes were categorized into four classes based on their significance and potential impact on the protocol:

● Class 1 – High Priority Functional Changes: Includes the reward distribution fix, unlocking of the EOTSD keyring feature, and optimizations in the Vigilante BTC staking tracker.

● Class 2 – Medium Priority Functional Changes: Covers integration of the Token Factory module, PFM, and IBC middleware. The review focuses on wiring correctness and potential negative impacts on the Babylon protocol, including modifications to Genesis logic.

● Class 3 – Low Priority Fixes: Minor bug fixes and adjustments.

● Class 4 – Non-Functional Changes: Includes refactoring, comments, formatting, and other non-functional updates.

The consultants will conduct a threat model, threat analysis, and comprehensive code inspection for changes classified under Class 1 and Class 2. For Class 3 and Class 4, the audit scope is limited to a comprehensive code inspection.

Audit plan The audit was conducted between May 19, 2025 and June 3, 2025 by the following personnel:

● Martin Hutle

● Ivan Gavran ● Karolos Antoniadis ● Aleksandar Ljahović

● Andrija Mitrović

● Mirel Dalčeković

Conclusions The auditing team’s conclusions regarding protocol design and code implementation quality are organized by scope and by categories of PRs reviewed during this audit. The changes to the reward distribution module were adding a simple mechanism to a complex existing code. Our analysis was thus focused on checking that the changes that were introduced indeed implement the change of semantics that was intended, and that the new mechanism provides the right inputs to the existing computation. There was no findings surfaced in the code, which seems to be well written and robust. In regards to the “Unlocking EOTSD keyring” scope: The code is well written and the move to a file-backend keyring is meaningful. Besides minor informational findings, we did not find any issue. However, future changes to cosmos/crypto/keyring ↗ or cosmos/keyring ↗ may introduce compatibility issues for the EOTS manager, so care needs to be taken when upgrading those dependencies. The BTC staking tracker Vigilante was audited following recent optimization changes. The audit identified a few minor issues, along with one notable bug in the periodic block-fetching logic, where the condition for fetched blocks was incorrect. Additionally, a race condition - unlikely but possible - was discovered. Overall, the Vigilante tracker is considered a robustly designed and implemented off-chain component. It reliably handles delegation status updates and avoids unintended duplicate actions on the Babylon Genesis chain, thanks to consistent validation of delegation status transitions. The pull requests, grouped into genesis init/export logic, small fixes, and non-functional changes, were overall well-implemented and aligned with the goals of the v2 backport effort. While most of the changes appear solid and raise no major concerns, a few areas were identified where improvements could be made - primarily around edge case handling and input validation. All identified findings are documented in the Findings section of this report.

Audit Dashboard Target Summary ● Type: Protocol & Implementation

● Platform: Go

● Artifacts, organized per class: - Artifacts, organized per class: The audit will be based on the analysis of:

– commit hash d95f863 ↗ in the babylon repository ↗, with a focus on pull requests introducing changes as part of the new Genesis v2 Upgrade. – commit hash 5da4342 ↗ in the finality-proider repository ↗ with a focus on the: Unlocking eotsd keyring PR ↗. – commit hash 33ba9b4 ↗ in the vigilante repository ↗ with a focus on the: Optimization in Vigilante BTC staking tracker PR ↗

Pull requests containing changes were classified in:

– Class 1 - critical features: ➞ Reward distribution fix PR ↗ - fix introduced in the babylon repository ↗. ➞ Unlocking eotsd keyring PR ↗ - feature introduced in the finality-provider repository ↗. ➞ Optimization in Vigilante BTC staking tracker PR ↗ - optimization introduced in the vigilante repository ↗. – Class 2 - integrations and genesis PRs: ➞ Babylon Labs’ fork of Strangelove’s token factory ↗ module integration PR ↗ ➞ IBC middlewares integration · IBC callbacks ↗ · PFM integration PR ↗ · rate limiter ↗ · ICA and ICQ modules ↗ ➞ Genesis logic PRs: · Backport: chore(x/btccheckpoint): add import/export genesis logic ↗ · Backport: chore(x/btcstaking): add AllowedStakingTxHashes and LargetsBTCReorg to import/ex- port genesis logic ↗ · Backport: chore(x/epoching): add init/export genesis logic ↗ · Backport: chore(x/finality): Update init/export genesis logic ↗ · backport: chore(x/mint): update gen logic ↗ · [backport] chore(x/monitor): Add init/export genesis logic ↗ – Class 3 - small fixes PRs: ➞ [release/v2.x] add v1.1 upgrade data ↗ ➞ backport: v2x fix inactive fp signing info ↗ ➞ chore: backport #850 BLS improvement including permission and and verification ↗ ➞ backport(bugfix): add checks for slashed fp in gov resume finality ↗ ➞ [backport] chore: add bank wrapper for distribution mod account ↗ · Security fix ↗; review that the addition of token factory doesn’t have similar impact as reported in SA ➞ [backport] chore: Add ValidateBasic for CommitPubRandList ↗ ➞ [backport] fix: update tokenfactory params to use ubbn as fee denom ↗

– Class 4: non-functional changes ➞ [backport] chore: upgrade the make file: release and build ↗ ➞ fix: wire btcstaking to btc light client hooks ↗ ➞ [backport] chore: Add e2e test for v2 upgrade ↗ ➞ fix: remove protobuf from make file ↗ ➞ [Backport v2] chore: move goreleaser job to release workflow ↗ ➞ [release/v2.x] chore: ensure release workflow build the released tag ↗ ➞ [release/v2.x] chore: Add btcstaking with new testing framework ↗ ➞ [release/v2.x] fix: btcstaking test fix ↗ ➞ [backport] chore(x/ibc-fee): remove deprecated mod ↗ ➞ [backport]1.1 Changelog to v2.x ↗ ➞ fix: missing proto version bumps ↗

Engagement Summary ● Dates: May 19, 2025 - June 3, 2025 ● Method: Manual code review, protocol analysis

Severity Summary

Finding Severity Number

Critical 0 High 0 Medium 5 Low 4 Informational 5 Total 14

System Overview The main goal of Babylon’s Genesis v2 upgrade is not to introduce new Babylon protocol features, but to enhance cross-chain composability and prepare the chain for broader ecosystem integration. Key additions include IBC Callbacks, Packet Forwarding Middleware (PFM), Token Factory, and Rate Limiting. These features are mostly imports of established modules from the broader Cosmos ecosystem, but were carefully delayed until now due to their wide-reaching implications on IBC behavior and security. While the features are not yet in use, projects building on Babylon protocol are actively waiting for them and are expected to start integrating them soon after the upgrade. The upgrade includes several critical changes: a fix for rewards distribution, optimizations to the Vigilante BTC staking tracker, and support for unlocking the EOTSD keyring -enabling keys to be stored in an encrypted file and unlocked with a password. Additional changes include the introduction of genesis logic, non-functional improvements, and minor fixes related to the upgrade and backported bug fixes. Each of the critical areas will be described in a dedicated system overview section below.

Integration scope The integration scope includes additions of following modules:

● Packet Forward Middleware (PFM) ● TokenFactory ● IBC Callbacks

● Rate Limiter

● ICA and ICQ

And also the removal of ibc-fee module. In this release, the modules were only enabled to be used, but without introducing new features using them.

Rewards distribution fix The reward distribution module uses a mechanism similar to x/distribution to allocate the delegator’s rewards to the finality providers and then distribute these rewards to the delegators once the delegation changes. The basic change of the PR under audit is that previously the wrong distribution table was used. If rewards for height h are distributed later at some height h’, the distribution table and voting information of height h (and not h’) should be used. This is implemented by tracking all delegation changes for h in BeginBlocker, and when rewards are distributed at height h’ in EndBlocker, the tracked information is fed into the existing reward mechanism. The audit is using a threat model that covers the whole mechanism, while the inspection was focusing on the changes, assuming that the calculation mechanism itself was audited before. The basic properties are therefore that the input to these calculations is correct with respect to height and order.

Event based BTC staking tracker The new, optimized BTC staking tracker introduces an event-based monitoring system that significantly optimizes how Vigilante tracks delegation state changes on Babylon Genesis chain. Previously, Vigilante inefficiently polled all pending delegations from Babylon Genesis chain on a recurring basis, resulting in substantial data overhead -reportedly around 20TB per month on testnet, according to the Babylon Labs team. The new implementation adopts an event-driven model: rather than polling all delegations, Vigilante now listens to CometBFT block events (e.g., delegation activation events) and updates its internal state incrementally on a block-by-block basis. This allows it to track only the relevant delegations and subsequently fetch related data from the Bitcoin side. While this approach improves performance and scalability, it introduces potential failure modes. If Vigilante misses or misprocesses a key event, it may fail to track specific delegations, leading to incorrect behavior. Vigilante maintains two in-memory tracking structures -pendingTracker and unbondingTracker- to monitor active and pending delegations. These structures are then used by the BTC staking tracker component to determine which unbonding messages to send to Babylon Genesis chain. Ensuring reliable event processing and accurate population of these tracking structures is now critical to correctness, as failures could result in missed activation and unbonding of delegations. Evaluating the correctness and completeness of this delegation-tracking logic -and identifying any scenarios where delegations may be missed- was one of the primary focuses of this security audit.

Unlocking EOTSD keyring Up until this version, the EOTSD keyring has been using the test ↗ keyring backend, where keys are stored unencrypted on disk (and is thus unsuitable for production). This release changes the keyring backend into the production-ready file backend ↗. As a part of this change, support for reading a passphrase from the user, unlocking with the passphrase, and storing keys in an in-memory map needed to be implemented.

Small fixes, genesis and non functional changes Several smaller backported changes were introduced to improve correctness, validation, and developer experience across modules. These include fixes for inconsistent finality provider signing info, enhanced BLS signature handling with proper permission checks and verification, validation logic for governance messages, updates to token factory parameters, and utility improvements such as a bank wrapper for the distribution module. As part of the v2 upgrade backporting effort, multiple modules (x/btccheckpoint, x/btcstaking, x/epoching, x/finality, x/mint, and x/monitor) have been updated to implement or extend their InitGenesis and ExportGe- nesis logic. These changes ensure that all relevant module states are correctly initialized and persisted. In addition to standard serialization, several modules also introduced or improved validation of genesis fields to maintain consistency and prevent runtime issues during chain initialization. Several non-functional changes were introduced as part of the v2 backport process to improve development workflows, testing infrastructure, and release consistency. These include version bumps, Makefile updates and cleanup, relocation of release and GoReleaser jobs to dedicated workflows, and addition of an E2E upgrade test for the v2 transition.

Threat Model Our threat analysis begins by defining a set of properties essential for the correctness of the audited scope. For each property, we identify one or more associated threats and analyze the conditions under which they might be violated. The results of this analysis are presented in the Findings section.

Event based BTC staking tracker threat model BTC staking tracker Vigilante’s failure to capture or process an event - whether due to bugs in event tracking or delegation tracking on vigilante, or due to missed blocks - can result in incomplete or incorrect delegation state tracking. Such issues can cause critical operational failures, such as skipped delegation activation, duplicated or missing undelegation processing. This threat model focuses on identifying potential failure modes introduced by the recent PR ↗ containing opti- mizations to Vigilante’s delegation retrieval logic. To thoroughly assess correctness the analysis slightly extended beyond the immediate pull request scope. Our objectives were to:

● Understand the BTC staking tracker implementation. ● Compare the original and event-based, optimized Babylon Genesis delegations processing logic on Vigilante. ● Understand delegation status transitions on Babylon Genesis and the corresponding event emissions (as

implemented in x/btcstaking and x/finality), in order to determine whether the original implementation can serve as a reliable reference point for expected behavior. ● Identify whether any new logic introduces inconsistencies or risks.

Genesis related PRs threat inspection In our

Excerpt (19988 of 94484 characters). Read the whole page on informalsystems/audits ↗

← Back to Documentation