Operator incentivization is not implemented properly, making it unlikely new operators will join and destabilization the network.

[code423n4]

Lines of code

https://github.com/code-423n4/2022-10-holograph/blob/f8c2eae866280a1acfdc8a8352401ed031be1373/contracts/HolographOperator.sol#L503

Vulnerability details

Description

Operators can choose which pod level to belong to, with each one having a different bond amount. The docs state :
"The probability of job selection is based on a specific pod being joined, and the number of Operators bonded in the specific Pod. "

This makes sense. Because the operator's only revenue is through fees collection for each operation, which is the same for every pod, the only incentive to go for a higher pod is higher frequency of job execution.

However, the crossChainMessage() code that is in charge of operator scheduling chooses an operator pod uniformally:

/**
 * @dev use job hash, job nonce, block number, and block timestamp for generating a random number
 */
uint256 random = uint256(keccak256(abi.encodePacked(jobHash, _jobNonce(), block.number, block.timestamp)));
/**
 * @dev divide by total number of pods, use modulus/remainder
 */
uint256 pod = random % _operatorPods.length;

As a consequence, operators of different tiers make the same yield but have different bonded amount requirement and risk, making the platform uncompetitive.

Impact

Operator incentivization is not implemented properly, making it unlikely new operators will join and destabilization the network.

Tools Used

Manual audit

Recommended Mitigation Steps

Calculate the next pod to execute using a fairer distribution.

[gzeoneth]

Duplicate of #434

[ACC01ADE]

Refer to #434 for explanation.

[trust1995]

Sorry about the dup, submitted the findings in the last second and accidentally sent twice.

[gzeoneth]

Consider with #433