Description

The MaxWithdrawalsPerBlock value in the application configuration is set to 0:

// app/app_config.go
defaultEvmEngineConfig = EvmEngineConfig{
    ...
    MaxWithdrawalsPerBlock: 0, // In original Omni chain, this value is set to 32
    ...
}

When MaxWithdrawalsPerBlock is set to 0, the system iterates over all entries in the withdrawal table without any limit:

// octane/evmengine/keeper/db.go
func (k *Keeper) EligibleWithdrawals(ctx context.Context, optimisticBuild bool) ([]*types.Withdrawal, error) {
    ...
    var limit int
    if optimisticBuild {
        limit = 0 // In optimistic build mode, we just build this as early as possible.
    } else {
        limit = k.cfg.MaxWithdrawalsPerBlock // When == 0, we include all withdrawals.
    }
    ...
    // Iterate over all eligible withdrawals until limit
    cnt := 0
    var withdrawals []*types.Withdrawal
    for iter.Valid() {
        ...
        withdrawals = append(withdrawals, withdrawal)
        cnt++
        if limit > 0 && cnt >= limit {
            break // Stop after reaching limit
        }
        ...
    }
    ...
}

This differs from the original Omni-chain implementation, which sets this value to 32.

Impact

This configuration does not pose a practical security risk.

The fallback logic in event procedures that would lead to withdrawal table entries is not triggered in normal operation due to existing validation mechanisms. Proper verification logic exists on the contract side (ValidatorManager.sol), ensuring that functions like registerValidator and depositCollateral function as expected.

This is purely a code-quality consideration rather than a security issue.

Recommendations

It is recommended to explicitly set the MaxWithdrawalsPerBlock parameter to an appropriate value (such as 32, as used in the original Omni chain) as a best practice.

Remediation

This issue has been acknowledged by Mitosis, and a fix was implemented in commit 195c4e8d↗.