States are not automatically synced
Description
The OmniAVS contract forwards the current validators from one side of the chain to the other via the OmniPortal. Currently, the only way of performing the sync between both sides of the chain is to call the syncWithOmni
function manually, by essentially querying the current total stake for all the currently registered validators.
/**
* @notice Sync OmniAVS operator stake & delegations with Omni chain.
*/
function syncWithOmni() external payable whenNotPaused {
Operator[] memory ops = _getOperators();
omni.xcall{ value: msg.value }(
omniChainId,
ethStakeInbox,
abi.encodeWithSelector(IEthStakeInbox.sync.selector, ops),
_xcallGasLimitFor(ops.length)
);
}
Impact
A potential issue may arise here if an operator has deregistered from one side of the chain, and no calls to syncWithOmni
would occur in the meanwhile. In this case, the operator would still be considered valid on the other side of the chain, even though they have completely removed their stake.
Recommendations
We recommend syncing with the Omni chain on every operation that has to do with the update of the operator's stake or status (i.e., registration/deregistration).
Remediation
Omni Network stated that they will take one of the following actions:
move the
deregisterOperator
function out of the AVS contract, to a separate contract on Omni's EVM.keep the
deregsiterOperator
function in the AVS contract, but transform it into a two-step process. In this case, Omni's EVM contract must acknowledge the de-registration before the actual removal from the AVS contract.
For the current release, Omni Network has removed the deregisterOperator
function from the AVS contract, as per commit b4e82eb↗. Therefore, the only way for an operator to deregister is to contact the Omni team, who will then perform the deregistration via ejectOperator
.
Additionally, Omni Network stated that:
If users can undelegate from operators freely, without being subject to any delay, we must consider this when designing how to incorporate user delegations into validator set updates. Granting voting power 1:1 with user delegations would not be appropriate. If operators can deregister / withdrawal at any time, and immediately remove their capital from risk of slashing, our AVS design is incompatible with EigenLayer. We do not believe this will be the case, as their current communications / documentation / source code suggest operator withdrawals / de-registrations will be subject to some delay, to account for slashing. We hope that user delegations are subject to this same delay.