Chiliz - V2 Genesis Contracts

In the contract `ChainConfig` the role `_fromgovernance` has authority over the functions shown in the diagram below. Any compromise to the `_fromgovernance` account may allow the hacker to take advantage of this authority and set `activeValidatorsLength`, `epochBlockInterval`, `misdemeanorThreshold`, `felonyThreshold`, `validatorJailEpochLength`, `undelegatePeriod`, `minValidatorStakeAmount`, `minStakingAmount`  In the contract `DeployerProxy` the role `_fromcoinbase` has authority over the functions shown in the diagram below. Any compromise to the `_fromcoinbase` account may allow the hacker to take advantage of this authority and register deployed contracts.  In the contract `DeployerProxy` the role `_fromgovernance` has authority over the functions shown in the diagram below. Any compromise to the `_fromgovernance` account may allow the hacker to take advantage of this authority and add/remove/ban/unban the deployer and disable/enable the contract  In the contract `Governance` the role `_fromgovernance` has authority over the functions shown in the diagram below. Any compromise to the `_fromgovernance` account may allow the hacker to take advantage of this authority and add/remove the proposer and activate the proposer registry.  In the contract `Governance` the role `_proposer` has authority over the functions shown in the diagram below. Any compromise to the `_proposer` account may allow the hacker to take advantage of this authority and propose a new proposal and execute the proposal.  In the contract `RuntimeUpgrade` the role `_fromgovernance` has authority over the functions shown in the diagram below. Any compromise to the `_fromgovernance` account may allow the hacker to take advantage of this authority and upgrade/deploy the system smart contract.  In the contract `SlashingIndicator` the role `_fromcoinbase` has authority over the functions shown in the diagram below. Any compromise to the `_fromcoinbase` account may allow the hacker to take advantage of this authority and slash the validator.  In the contract `Staking` the role `_fromcoinbase` has authority over the functions shown in the diagram below. Any compromise to the `_fromcoinbase` account may allow the hacker to take advantage of this authority and deposit fee.  In the contract `Staking` the role `_fromgovernance` has authority over the functions shown in the diagram below. Any compromise to the `_fromgovernance` account may allow the hacker to take advantage of this authority and add/remove/activate/disable the validator,pause/unpause the contract and fix the validator epoch.  In the contract `Staking` the role `_fromslashingindicator` has authority over the functions shown in the diagram below. Any compromise to the `_fromslashingindicator` account may allow the hacker to take advantage of this authority and slash the validator.  In the contract `SystemReward` the role `_fromgovernance` has authority over the functions shown in the diagram below. Any compromise to the `_fromgovernance` account may allow the hacker to take advantage of this authority and update distribution share. 

The “Governance” contract inherits multiple upgradeable contracts, indicating that it’s part of an upgradeable system. Upgradeable contracts often pair with a proxy contract responsible for managing contract upgrades. The `admin` of the proxy has the authority to update the implementation contract (i.e., the Governance contract). Any compromise of the admin account could allow a hacker to exploit this authority, potentially altering the implementation contract pointed to by the proxy, and thus executing malicious functionality within the implementation contract.

The identified loop logic in `_processDelegateQueue()`, `_processUndelegateQueue()`, and `_calcDelegatorRewardsAndPendingUndelegates()` may exceed the block gas limit when the parameter `beforeEpochExclude`/`beforeEpoch` is far bigger than the epoch of last processed delegation. It can happen if functions `redelegateDelegatorFee()`/`claimDelegatorFee()`/`claimDelegatorFeeAtEpoch()` have not been called by a delegator for a long time. This is especially critical for `StakingPool` because it does not use `claimDelegatorFeeAtEpoch()` to process delegation little by little. Thus the modifier `advanceStakingRewards()` in `StakingPool` may always fail due to the use of `_processDelegateQueue()`/`_calcDelegatorRewardsAndPendingUndelegates()`. Then the functions `stake()`/`unstake()`/`claim()` in `StakingPool` will always fail and users' funds are locked in the contract and lost.

Deploying new contracts and upgrading existing contracts use different bytecodes. Deploying new contracts run `contract creation bytecode` which runs constructor code and returns the actual runtime bytecode. Upgrading existing contracts involves using new runtime bytecode to replace existing runtime bytecode. The function `_upgradeSystemSmartContract()` does not run constructor code at all which is required by deploying new contracts. Thus any new contract with non-empty constructor will not initialize properly and malfunction afterwards. See https://docs.soliditylang.org/en/latest/contracts.html#immutable

If a validator with non-zero delegation or pending validator rewards is removed, the functions `undelegate()`/`claimValidatorFee()`/`claimValidatorFeeAtEpoch()` will malfunction and users' funds can not be withdrawn.

The **require** can be used to check for conditions and throw an exception if the condition is not met. It is better to provide a string message containing details about the error that will be passed back to the caller.

Performing division by zero would raise an error and revert the transaction. ```solidity=136 uint64 epoch = uint64(blockNumber / _chainConfigContract.getEpochBlockInterval()); ``` The expression `blockNumber / _chainConfigContract.getEpochBlockInterval()` may divide by zero. Its divisor has has estimated interval [0, 4294967295]. --- ```solidity=241 return uint64(block.number / _chainConfigContract.getEpochBlockInterval() + 0); ``` The expression `block.number / _chainConfigContract.getEpochBlockInterval()` may divide by zero. Its divisor has has estimated interval [0, 4294967295]. --- ```solidity=48 return _stakerShares[validator][staker] * 1e18 / _calcRatio(validatorPool); ``` The expression `_stakerShares[validator][staker] * 1e18 / _calcRatio(validatorPool)` may divide by zero. Its divisor has has estimated interval [-1, pinf]. --- ```solidity=103 return uint64(block.number / _chainConfigContract.getEpochBlockInterval()); ``` The expression `block.number / _chainConfigContract.getEpochBlockInterval()` may divide by zero. Its divisor has has estimated interval [0, 4294967295].

When a loop allows an arbitrary number of iterations or accesses state variables in its body, the function may run out of gas and revert the transaction. ```solidity=42 for (uint256 i = 0; i < deployers.length; i++) { ``` Function `DeployerProxy.ctor` contains a loop and its loop condition depends on parameters: `deployers`. --- ```solidity=86 for (uint256 i = 0; i < currentValidatorSet.length; i++) { ``` Function `Governance.activateProposerRegistry` contains a loop and its loop condition depends on external calls: `_stakingContract.getValidators`. --- ```solidity=148 for (uint256 i = 0; i < validators.length; i++) { ``` Function `Governance._votingSupply` contains a loop and its loop condition depends on external calls: `_stakingContract.getValidators`. --- ```solidity=64 for (uint256 i = 0; i < _deployedSystemContracts.length; i++) { ``` Function `RuntimeUpgrade.getSystemContracts` contains a loop and its loop condition depends on state variables: `_deployedSystemContracts`. --- ```solidity=129 for (uint256 i = 0; i < validators.length; i++) { ``` Function `Staking.ctor` contains a loop and its loop condition depends on parameters: `validators`. --- ```solidity=664 for (uint256 i = 0; i < k; i++) { ``` Function `Staking.getValidators` contains a loop and its loop condition depends on external calls: `_chainConfigContract.getActiveValidatorsLength`. --- ```solidity=178 for (uint256 i = 0; i < validators.length; i++) { ``` Function `StakingPool.manuallyClaimPendingUndelegates` contains a loop and its loop condition depends on parameters: `validators`.

One or more state variables are used without being initialized in the constructor. ```solidity=29 address internal _systemTreasury; ``` - `_systemTreasury` is never initialized, but used in `SystemReward._claimSystemFee`.

Type casting refers to changing an variable of one data type into another. The code contains an unsafe cast between integer types, which may result in unexpected truncation or sign flipping of the value. ```solidity=136 uint64 epoch = uint64(blockNumber / _chainConfigContract.getEpochBlockInterval()); ``` Casted expression `blockNumber / _chainConfigContract.getEpochBlockInterval()` has estimated range [0, 115792089237316195423570985008687907853269984665640564039457584007913129639935] but target type `uint64` has range [0, 18446744073709551615]. --- ```solidity=342 require(recentDelegateOp.amount >= uint64(amount / BALANCE_COMPACT_PRECISION), "insufficient balance"); ``` Casted expression `amount / BALANCE_COMPACT_PRECISION` has estimated range [0, 11579208923731619542357098500868790785326998466564056403945758400791] but target type `uint64` has range [0, 18446744073709551615]. --- ```solidity=696 currentSnapshot.totalRewards += uint96(msg.value); ``` Casted expression `msg.value` has estimated range [1, 115792089237316195423570985008687907853269984665640564039457584007913129639935] but target type `uint96` has range [0, 79228162514264337593543950335]. --- ```solidity=859 return uint112(amount / BALANCE_COMPACT_PRECISION); ``` Casted expression `amount / BALANCE_COMPACT_PRECISION` has estimated range [0, 11579208923731619542357098500868790785326998466564056403945758400791] but target type `uint112` has range [0, 5192296858534827628530496329220095].