Assessment reports>Babylon Genesis Chain>Critical findings>Slashed finality provider restoring voting power through pending delegations
GeneralOverview
Audit ResultsAssessment Results
Category: Coding Mistakes

Slashed finality provider restoring voting power through pending delegations

Critical Severity
Critical Impact
High Likelihood

Description

When a finality provider is slashed, it should be removed from the VotingPowerDistCache and lose its ability to participate in finality voting. However, an issue occurs when an FP has a pending BTC delegation at the time of slashing.

If a pending delegation exists when the BTC block height in the btclightclient module is 10, and the FP is slashed before that delegation is processed, the slashed status is not considered when the delegation is later finalized. When the BTC block height reaches 15 and the AddBTCDelegationInclusionProof function in the btcstaking module is called, the pending delegation is converted into an active delegation. However, since this function does not check whether the FP was previously slashed, the slashed FP is reintroduced into the VotingPowerDistCache, regaining voting power and participating in the finality vote.

In contrast, CreateBTCDelegation includes a check to prevent slashed FPs from being considered (source here). The same validation should be added to AddBTCDelegationInclusionProof to ensure that slashed FPs cannot regain voting power through pending delegations.

Impact

A slashed FP that should have been permanently excluded from finality voting can regain its voting power through a delayed delegation event. This weakens the slashing mechanism by allowing penalized entities to return to voting without the required penalty enforcement. If exploited, this could undermine the security of the finality module and create inconsistencies in voting-power distribution.

Recommendations

Modify the AddBTCDelegationInclusionProof and AddCovenantSigs functions to include a check that prevents previously slashed FPs from regaining voting power. The implementation should follow the approach used in CreateBTCDelegation to ensure that any FP with a slashed status is excluded from the voting-power update.

Remediation

This issue has been acknowledged by Babylon Labs, and fixes were implemented in the following commits:

This was remediated by ensuring that the NewFinalityProviderDistInfo function correctly includes the slash and jail status when returning FP information.

Zellic © 2025Back to top ↑