Babylon vulnerable to chain halt when a message modifies the validator set at the epoch boundary
Sending a message that modifies the validator set at the epoch boundary halts the chain.
Sending a message that modifies the validator set at the epoch boundary halts the chain.
Sending transactions with fees different than native Babylon genesis denom (ubbn) leads to chain halt.
Sending transactions with fees different than native Babylon genesis denom (ubbn) leads to chain halt.
Minting large amount of tokens through ibc transfer and then depositing them in validator rewards pool (via DepositValidatorRewardsPool message) can lead to integer overflow panic when calculating cumulative_reward_ratio for the validator. This calculation happens in x/epoching module EndBlocker, thus the panic will halt the chain.
A high vulnerability exists in the Babylon protocol's x/finality module due to a lack of domain separation in signed messages, combined with insufficient validation in the MsgCommitPubRandList handler. Specifically, the handler does not enforce that the submitted Commitment field is 32 bytes long. This allows an attacker to replay a signature originally generated for a different message (e.g., a Proof-of-Possession in MsgCreateFinalityProvider) as a MsgCommitPubRandList. By crafting the message parameters, …