Description

Babylon’s epoching module maintains a validator-set snapshot at the beginning of each epoch to support checkpoint signing. When a validator is slashed mid-epoch by the Cosmos SDK’s slashing module, the validator’s power reduction is not reflected in the epoching module’s snapshot until the next epoch. As a result, any checks (and VoteExtension logic) in ProcessProposal continue to use the slashed validator’s pre-slash voting power until the next epoch begins.

A malicious validator — who is slashed but retains its old voting power in the epoching store — may continue to exert influence on checkpoint signing. In a worst-case scenario where the adversary holds slightly more than two-thirds of the total voting power, they could send conflicting blocks or checkpoints to different groups of honest validators, leading to temporary forks or confusion. While these forks may be resolved via social consensus and retroactive slashing, it raises concerns about temporary safety risks and potential rollbacks that could affect external participants (like centralized exchanges).

Impact

The influence of slashed validators is extended. Because their voting power remains unchanged until the next epoch, slashed (or otherwise compromised) validators may still meet two-thirds thresholds during mid-epoch checkpoint votes. This can affect checkpoint-validity checks in ProcessProposal, allowing a malicious or compromised validator to exercise undue influence until the epoch update.

Recommendations

Reflect the slashed validator’s reduced voting power as soon as the slashing event occurs, rather than deferring to the next epoch. This would reduce the window of time in which a malicious or misconfigured validator retains full voting power despite being slashed.

Remediation

This issue has been acknowledged by Babylon Labs, who does not plan to apply slashing power changes mid-epoch. The design intends for checkpoint signing to rely on a stable validator set for the entirety of each epoch. Applying immediate power updates within an epoch could endanger liveness, particularly if a supposedly honest validator is accidentally slashed due to a misconfiguration. In such a case, the adversarial share could rise above one-third, jeopardizing the chain’s liveness.

Babylon Labs also does not see an immediate safety violation. If more than two-thirds of the validators become adversarial, Bitcoin timestamping ensures that an earlier checkpoint prevails. Additionally, slashable safety means malicious validators who sign multiple or invalid checkpoints can be clearly identified and punished. In rare cases of a serious fork, instead of relying on social consensus, a runbook will be used to select the correct fork based on an objective rule tied to checkpoints posted on Bitcoin. Therefore, deferring voting power updates until the next epoch is considered an acceptable action for preserving liveness while still guarding against adversarial behavior.