Assessment reportsPublic findings
Back to Zellic site
↗
Assessment reports>Babylon Genesis Chain>Design>Module: mint
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

Module: mint

Description

Babylon's x/mint module is based on the Cosmos SDK x/mint↗ and includes modifications to the inflation mechanism. The code is adapted from Celestia’s mint module↗ and introduces changes to how the inflation rate is calculated and applied.

ABCI++ handlers

BeginBlock

During the beginning of each block, the BeginBlocker function updates the inflation rate and annual provisions then mints the necessary tokens for that block’s provision. The process is as follows:

  1. maybeUpdateMinter

    This step recalculates the InflationRate and updates AnnualProvisions. The inflation rate is adjusted once per year on the anniversary of the genesis block. It gradually decreases until reaching a target inflation rate (TargetInflationRate) specified in the mint module. If the existing annual provisions are nonzero and the inflation rate remains unchanged, the function skips recalculation to avoid unnecessary computation.

  2. mintBlockProvision

    The function computes the number of tokens to be minted for the current block. It considers the time elapsed since the previous block and uses the updated annual provisions to determine the appropriate block provision. The newly minted tokens are then sent to the fee collector.

  3. setPreviousBlockTime

    After tokens are minted, the system records the current block’s timestamp. This timestamp is used in future calculations to determine the time-based portion of the block-provision formula.

Upon successful completion, the module emits an event containing the updated inflation rate, annual provisions, and the total tokens minted for the current block.

Test coverage

The x/mint package has moderate test coverage (69.7%), with the keeper module slightly higher (71.1%), while the types module remains largely untested (2.4%).

ok      github.com/babylonlabs-io/babylon/x/mint        1.383s  coverage: 69.7% of statements
ok      github.com/babylonlabs-io/babylon/x/mint/keeper 1.443s  coverage: 71.1% of statements
ok      github.com/babylonlabs-io/babylon/x/mint/types  2.189s  coverage: 2.4% of statements

Attack Surface

The mint module is responsible for adjusting the amount of rewards distributed to participants in the Babylon chain. Due to interactions with external modules, the amount of rewards that the mint module distributes to Babylon chain participants could potentially be manipulated.

Zellic © 2025Back to top ↑