Hardcoded Operator Limit Logic
The contract defines some hardcoded limits which is not the right approach for upgradeable contracts and opens doors for accidental mistakes, if not handled with care.\\nThe operators for the current version are limited to 1. If the auditee team decides to open the system to work with more operators but fails to change the limit while upgrading, the upgraded contract will have no effect, and will still disallow any more operators to be added.\\n```\\nfunction addOperator(address \\_operatorAddress, address \\_feeRecipientAddress) external onlyAdmin returns (uint256) {\\n StakingContractStorageLib.OperatorsSlot storage operators = StakingContractStorageLib.getOperators();\\n StakingContractStorageLib.OperatorInfo memory newOperator;\\n\\n if (operators.value.length == 1) {\\n revert MaximumOperatorCountAlreadyReached();\\n }\\n```\\n\\nAlso, the function `_depositOnOneOperator` hardcodes the operator Index as 0 since the contract only supports one operator.\\n```\\nfunction \\_depositOnOneOperator(uint256 \\_depositCount, uint256 \\_totalAvailableValidators) internal {\\n StakingContractStorageLib.setTotalAvailableValidators(\\_totalAvailableValidators - \\_depositCount);\\n \\_depositValidatorsOfOperator(0, \\_depositCount);\\n}\\n```\\n
A better approach could be to constrain the limit of operators that can be added with a storage variable or constant, provided at the time of contract initialization. The contract should also consider supporting dynamic operator deposits for future versions instead of the default hardcoded index.
```\\nfunction addOperator(address \\_operatorAddress, address \\_feeRecipientAddress) external onlyAdmin returns (uint256) {\\n StakingContractStorageLib.OperatorsSlot storage operators = StakingContractStorageLib.getOperators();\\n StakingContractStorageLib.OperatorInfo memory newOperator;\\n\\n if (operators.value.length == 1) {\\n revert MaximumOperatorCountAlreadyReached();\\n }\\n```\\n