Skip to content

Latest commit

 

History

History
69 lines (42 loc) · 3.01 KB

055.md

File metadata and controls

69 lines (42 loc) · 3.01 KB

Slow Misty Iguana

High

Delegation can perform an Unbonded operation on the BTC chain to evade the penalty of being slashed.

Summary

Delegation can perform an Unbonded operation before the FP is about to be slashed, thereby resulting in no funds on the FP being penalized.

Root Cause

https://github.com/sherlock-audit/2024-12-babylon/blob/main/babylon/x/btcstaking/keeper/msg_server.go#L586

// BTCUndelegate adds a signature on the unbonding tx from the BTC delegator
// this effectively proves that the BTC delegator wants to unbond and Babylon
// will consider its BTC delegation unbonded
func (ms msgServer) BTCUndelegate(goCtx context.Context, req *types.MsgBTCUndelegate) (*types.MsgBTCUndelegateResponse, error) {
	defer telemetry.ModuleMeasureSince(types.ModuleName, time.Now(), types.MetricsKeyBTCUndelegate)
//skip
	// all good, add the signature to BTC delegation's undelegation
	// and set back
@>	ms.btcUndelegate(ctx, btcDel, delegatorUnbondingInfo)

	// At this point, the unbonding signature is verified.
	// Thus, we can safely consider this message as refundable
	ms.iKeeper.IndexRefundableMsg(ctx, req)

	return &types.MsgBTCUndelegateResponse{}, nil
}

The unstake operation of Delegation is carried out on the BTC chain. Although the Unbonding signature of the Covenant Emulator is required, it can still be obtained.

The MsgBTCUndelegate message is used for unbonding bitcoin from a given finality provider. It is typically reported by the BTC staking tracker program which proactively monitors unbonding transactions on Bitcoin.

In the btcUndelegate() function, addPowerDistUpdateEvent is sent, and the vote power of Delegation is removed. It will be processed only after the BeginBlock() of the k + 1 block.

Moreover, for the finality provider to be slashed, it is necessary to wait for the completion of the second signature voting. At this time, there may be no BTC funds on the finality provider to be penalized.

Internal pre-conditions

External pre-conditions

When the finality provider (FP) and the Delegation belong to the same user, the attack can succeed almost 100%.

Attack Path

  1. In each block, the finality provider (FP) first signs through AddFinalitySig().
  2. An Unbonded operation is carried out on the BTC chain. When the transaction (tx) is completed on BTC, assume the current Babylon block is k.
  3. The BTC staking tracker reports the Unbonded event through BTCUndelegate(). Even if there is no delay in the off-chain process, it is assumed to have been submitted at the Babylon block k.
  4. Since the vote power needs to be removed in the k + 1 block, at this time, in block k, the FP can safely cast a second vote within the voting range including block k and k - 1, etc. Because even if the FP is slashed, its BTC funds have already been transferred away.

Impact

The slash mechanism has been broken, and FPs can act maliciously without worrying about being penalized.

PoC

Mitigation

There are currently no straightforward suggestions that can definitively solve this problem.