Chiliz security record

The protocol adds a feature where tokens can have different cooldown periods. This may mean that in some cases, users can bypass this period by swapping tokens.It is possible that the new token will have a lower cooldown than the old token, thus allowing previously unstaked tokens to have a shorter cooldown period.These are the steps to replicate this issue:Stake old tokens (asuming 1000 seconds of locking period).Wait less time than unstakePeriodPerToken of the old token and unstake them.Swap tokens.The lock time for your position has decreased depending on the unstakePeriodPerToken of the new token. For example, if this value is 1 second, then the remaining time is bypassed.

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 report gives no description here.

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`.