Description

A critical issue was identified in the delegation status evaluation logic, which could result in unintended event processing order, ultimately leading to a panic and chain halt. The condition statement in GetStatus ( code reference↗ ) utilizes > instead of >=, leading to an incorrect delegation status evaluation.

If the MsgCreateBTCDelegation message handler is executed with a valid proof, the EXPIRED event is scheduled to be emitted at EndHeight - UnbondingTime ( code reference↗ ). At the same time, the MsgAddCovenantSigs message handler invokes the GetStatus function to determine the delegation status ( code reference↗ ). If the message is processed at EndHeight - UnbondingTime, the delegation is incorrectly classified as ACTIVED due to the use of > instead of >=.

As a result, the EXPIRED event is processed before the ACTIVED event, as the events are iterated in a predetermined order ( code reference↗ ). This sequence leads to an incorrect deduction of Delegated Satoshi before the activation of delegation is recognized.

Impact

If the Finality Provider’s TotalBondSat is zero at the time of processing the EXPIRED event, the deduction results in a negative balance, leading to a panic and subsequent chain halt. The incorrect processing order introduces a scenario in which an ACTIVED event, which should acknowledge the delegation, is not processed before the EXPIRED event that deducts the delegation amount.

Recommendations

The condition for checking expired in GetStatus should be modified to use >= instead of > to ensure proper delegation status evaluation

Remediation

This issue has been acknowledged by Babylon Labs, and a fix was implemented in commit ef141cd3↗.

This was remediated by modifying the expiration condition in GetStatus to use >= instead of >.