063.md

Scruffy Gingerbread Cormorant

High

Slashed Finality Providers Can Receive Incorrect Voting Power Distribution Leading to Chain Halt

Summary

Flawed voting power distribution logic in ProcessAllPowerDistUpdateEvents and missing slashing checks in AddBTCDelegationInclusionProof will cause issue for Babylon consensus as slashed malicious finality providers can regain voting power. This can lead to incorrect voting power distribution and potentially cause a chain halt.

Root Cause

In babylon/x/finality/keeper/power_dist.go at https://github.com/sherlock-audit/2024-12-babylon/blob/main/babylon/x/finality/keeper/power_dist_change.go#L272, the ProcessAllPowerDistUpdateEvents function uses a dual-loop structure that creates a fundamental vulnerability:

// First loop processes existing providers from previous cache
for i := range dc.FinalityProviders {
    // create a copy of the finality provider
    fp := *dc.FinalityProviders[i]
    fpBTCPKHex := fp.BtcPk.MarshalHex()

    // if this finality provider is slashed, continue to avoid
    // assigning delegation to it
    _, isSlashed := slashedFPs[fpBTCPKHex]
    if isSlashed {
        fp.IsSlashed = true
        continue
    }
    // ... other processing
}

// Second loop processes "new" providers - with critical flaws
for _, fpBTCPKHex := range fpActiveBtcPkHexList {
    // Only checks if slashed in current batch of events
    _, isSlashed := slashedFPs[fpBTCPKHex]
    if isSlashed {
        continue
    }
    // ... creates new provider entry with no historical slashing data
    newFP := k.loadFP(ctx, fpByBtcPkHex, fpBTCPKHex)
    fpDistInfo := ftypes.NewFinalityProviderDistInfo(newFP)
    // ... adds to active set
}

This creates a critical gap: finality providers slashed in previous blocks (not in the current batch) can appear as "new" providers in the second loop if there are delegations and can be added back to active set with voting power.

This issue is also enabled by a missing check in babylon/x/btcstaking/keeper/msg_server.go: the AddBTCDelegationInclusionProof function doesn't verify if finality providers in the delegation have been slashed and hence a pending delegation can be processed for a slashed FP.

Internal Pre-conditions

NA

External Pre-conditions

NA

Attack Path

1. Malicious finality provider creates delegations or receives delegations from users
2. Provider gets slashed for malicious behavior and is removed from the active set
3. Inclusion proofs are submitted for the delegations after slashing
4. System activates these delegations in AddBTCDelegationInclusionProof
5. During BeginBlock processing, the slashed provider appears as "new" in the voting power distribution
6. Provider bypasses slashing state in the second loop of ProcessAllPowerDistUpdateEvents
7. Slashed provider regains voting power and rejoins the active set
8. Chain potentially halts as slashed finality provider can not vote and quorum may not get met even with less than 1/3 non-slashed finality providers misbehaving

Impact

This vulnerability can cause catastrophic consensus failures:

1. Incorrect Quorum Calculations: Slashed providers gain voting power in distribution calculations but cannot actually vote
2. Consensus Deadlock: As more voting power is assigned to slashed providers who cannot vote, reaching quorum becomes increasingly difficult
3. Chain Halt: If enough voting power is allocated to slashed providers, reaching the required quorum thresholds becomes mathematically impossible

If a significant portion of the total voting power is assigned to slashed providers who cannot participate in consensus, the chain may permanently halt as the required quorum (2/3+) becomes unachievable with the remaining active validators. Even otherwise, It violates the failure assumptions as now less than 1/3 finality providers misbheavior can cause chain halt.

PoC

No response

Mitigation

No response