Sign Up for a Code Audit Today and Get 3 Months of Skynet for Free

All of the tokens are sent to the contract deployer when deploying the contract. This could be a centralization risk as the deployer can distribute tokens without obtaining the consensus of the community.

Initial Token Distribution

In the contract `SmartChefInitializable`, the role `_owner` has authority over the following functions:
- `renounceOwnership()`
- `transferOwnership()`
- `emergencyRewardWithdraw(uint256 _amount)`
- `recoverWrongTokens(address _tokenAddress, uint256 _tokenAmount)`
- `stopReward()`
- `updatePoolLimitPerUser(bool _hasUserLimit, uint256 _poolLimitPerUser)`
- `updateRewardPerBlock(uint256 _rewardPerBlock)`
- `updateStartAndEndBlocks(uint256 _startBlock, uint256 _bonusEndBlock)`

Any compromise to the `_owner` account may allow a hacker to take advantage of this authority.

In the contract `NFTAirdrop`, the role `_owner` has authority over the following functions:
- `flipClaimState()`

Any compromise to the `_owner` account may allow a hacker to take advantage of this authority.

In the contract `GameSlot`, the role `_owner` has authority over the following functions:
- `cashoutPoints`
- `setAdmin`
- `unlock()`
- `addToBlacklist(address[] calldata entries)`
- `removeFromBlacklist(address[] calldata entries)`
- `emergencyWithdraw()`
- `recoverWrongTokens(address _tokenAddress, uint256 _tokenAmount)`
- `setReservedAmount(uint256 _reservedAmount)`
- `setPerformanceFee(uint256 _performanceFee)`
- `setTreasury(address _treasury)`
- `flipSuspendState()`
- `setUnlockLimitAmount()`

Any compromise to the `_owner` account may allow a hacker to take advantage of this authority.

In the contract `TokenAirdrop`, the role `_owner` has authority over the following functions:
- `flipClaimState()`
- `addToWhiteList()`
- `addToPremium()`
- `removeFromWhiteList()`
- `setTokensPerClaim()` in the commit `ca76d8048b424b7c09f2ab3b7c9a9e0d7da90cc2`
- `setTokensPerClaimPremium` in the commit `ca76d8048b424b7c09f2ab3b7c9a9e0d7da90cc2`

Any compromise to the `_owner` account may allow a hacker to take advantage of this authority.

In the contract `PremiumPool`, the role `_owner` has authority over the following functions:
- `emergencyRewardWithdraw(uint256 _amount)`
- `recoverWrongTokens(address _tokenAddress, uint256 _tokenAmount)`
- `stopReward()`
- `updatePoolLimitPerUser(bool _hasUserLimit, uint256 _poolLimitPerUser)`
- `updateRewardPerBlock(uint256 _rewardPerBlock)`
- `updateStartAndEndBlocks(uint256 _startBlock, uint256 _bonusEndBlock)`
- `setWithdrawFee(uint256 _withdrawFee)`
- `setWithdrawFeePeriod(uint256 _withdrawFeePeriod)`

Any compromise to the `_owner` account may allow a hacker to take advantage of this authority.

Centralization Related Risks

When transferring standard ERC20 deflationary tokens, the input amount may not be equal to the received amount due to the charged transaction fee. For example, if a user stakes 100 deflationary tokens (with a 10% transaction fee) in a SmartChefInitializable, only 90 tokens actually arrived in the contract. However, the user can still withdraw 100 tokens from the contract, which causes the contract to lose 10 tokens in such a transaction. 

The SmartChefInitializable takes the pool token balance(the `stakedTokenSupply`) into account when calculating the users' reward. An attacker can repeat the process of deposit and withdraw to lower the token balance(`stakedTokenSupply`) in a deflationary token pool and cause the contract to increase the reward amount. 

The PremiumPool takes the pool token balance(the `stakedTokenSupply`) into account when calculating the users' reward. An attacker can repeat the process of deposit and withdraw to lower the token balance(`stakedTokenSupply`) in a deflationary token pool and cause the contract to increase the reward amount. 

Reference:
https://thoreum-finance.medium.com/what-exploit-happened-today-for-gocerberus-and-garuda-also-for-lokum-ybear-piggy-caramelswap-3943ee23a39f

Incompatibility With Deflationary Tokens

The linked variables assigned in the constructor can be declared as `immutable`. Immutable state variables can be assigned during contract creation but will remain constant throughout the lifetime of a deployed contract. A big advantage of immutable variables is that reading them is significantly cheaper than reading from regular state variables since they will not be stored in storage.

Variables That Could Be Declared as Immutable

There is a fee-charging logic when withdrawing. However, the fee is not deducted from the user.

Example:
- Alice withdraws an amount of 10000 in less than 72 hours,
- Then the fee could be 10000 * 10 / 10000 = 10, 10 amount of token sent to the address `treasury`, at the same time, the value of `_amount` becomes 9990
- Finally, the amount deducted from Alice is 9990 instead of `10000`

As a result, the fee is not charged to Alice but to the pool.

The wrong amount is deducted from the user when withdrawing

Functions that affect the status of sensitive variables should be able to emit events as notifications to customers:

- `setWithdrawFee()`
- `setWithdrawFeePeriod()`

Missing Emit Events

The given input `_treasury` is missing the sanity checks for ensuring non-zero value.

Lack of Input Validation

```solidity
    function addToPremium(address[] calldata _e) external onlyOwner {
            ...
            _addToWhitelsit(entry);
            premiumAddress[entry] = true;
            ...  
    }
```
In the function `addToPremium`, a premium address will be added to the whitelist, and the value `premiumAddress[premiumAddress]` also be marked as true.

However, in the function `removeFromWhiteList`, lack of checking the case whether an address is a premium address. The value `premiumAddress[premiumAddress]` should be marked as false when removing it from the whitelist, otherwise, the value of `whitelistAddress[premiumAddress]` is not correct.


Lack of update `premiumAddress` when calling the `removeFromWhiteList` function

When we add an address into the whitelist, the `_counter` will be increased:
```solidity=61
function _addToWhitelsit(address _address) internal {
      require(_address != address(0), "Zero address is not allowed");
      if (!whitelistAddress[_address]) {
          whitelistAddress[_address] = true;
          _counter.increment();
          emit Add(_address);
      }
}
```

However, when we remove an address from the whitelist, the `_counter` is not decreased:
```solidity=86
function removeFromWhiteList(address[] calldata _e) external onlyOwner {
        for(uint256 i = 0; i < _e.length; i++) {
            address entry = _e[i];
            whitelistAddress[entry] = false;
            emit Remove(entry);
        }
}
```

At last, the `_counter` will not reflect the correct number of the whitelist.

Inconsistent Counter

Deblox -Ⅱ

GameSlot.sol

DGS-Staking.sol

TokenAirdrop.sol

DGSToken.sol

NFTAirdrop.sol

Deblox

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

9

0

3

0

6