Description

When an operator registers into OmniAVS, it is checked that the operator's stake is greater than the minimum amount of staking.

function registerOperator(
    bytes calldata pubkey,
    ISignatureUtils.SignatureWithSaltAndExpiry memory operatorSignature
) external whenNotPaused {
    address operator = msg.sender;

    // ...
    require(_getTotalDelegations(operator) >= minOperatorStake, "OmniAVS: min stake not met");
    // ...
}

Due to the nature of EigenLayer's architecture, the stake can change throughout the lifetime of a contract and should thus constantly be checked against the minimum threshold. There are multiple reasons for a possible decrease in stake, though the most likely scenario is that a staker (i.e., the normal user that delegates to operators) withdraws their stake from the operator.

Impact

An operator who does not have enough stake would remain in the list of operators, unless they are manually ejected by the owner of OmniAVS.

If the allowlist is disabled and anyone is allowed to register into OmniAVS, a malicious user can fill the maximum number of operators in order to interrupt the registration function without actually staking the minimum amount of staking for each user.

Recommendations

Consider performing the check when generating the list of operators and/or automatically deregistering operators who have stake below the threshold.

Alternatively, prune the list of authorized operators whenever syncWithOmni is called, so that the other side of the chain only allows legitimate and healthy operators.

Remediation

Omni Network stated that the minimum threshold to obtain the voting power on the consensus chain will be separately managed and checked. Omni Network also stated that they will enable the allowlist mechanism and work with trusted operators during the first phase, and they plan to implement the pruning operation, which ejects operators below the minimum amount of stake and/or the direct ejection from the consensus chain. Moreover, Omni Network has stated the following:

In the long term, ejecting operators that are not actively validating (zero voting power), may be necessary. When our AVS operator set is less permissioned (allowlist disabled), it will be important to address scenario you’ve outlined - in which “malicious user can fill the maximum number of operators in order to interrupt the registration function without actually staking the minimum amount of staking for each user.” Though we are hopeful EigenLayer’s slashing design will restrict the ease with which users can undelegate to operators.

Additionally, depending on EigenLayer’s reward mechanism, it may be important to quickly prune operators that are no longer validating, so that rewards are not paid to inactive operators.

For both cases, we can introduce consensus chain controlled ejections. Our consensus chain already relays validator set updates to portal contracts. Extending this mechanism to remove operators without voting power from our AVS contract is feasible.