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

The contracts of the project are deployed with `proxy`. Apart from the logic in the specific logic contract, the contracts deployed via proxies can add additional permission controls or other logic. Since the proxy contract is not in the audit scope, it will be treated as a black box and assumed functional correctness. However, there will be potential centralization risk in the proxy:

- The admin of the proxy contract has the authority to execute any delegate call.

Any compromise to the `admin` account may allow the hacker to take advantage of this and users' assets may suffer loss.

Centralization risk in proxy

The linked variables are assigned only once, either during their contract-level declaration or during the `constructor`'s execution.

Mutability Specifiers Missing

The contract `CRYPTERIUM_CROWDSALE_STAGING_B1` inherits the contract `Secondary` but does not use its features.

`Secondary` inherited but not used

The metadata of the contract `CRYPTERIUM_STAGING_B1` is same with that of the contract `CRYPTERIUM_STAKEING_STAGING_B1`.

Same Metadata

The value of `payCount` should be time divided by PERIOD instead of the remainder of time divided by PERIOD.

Logical issue of `payCount`

The stake token and reward token are the same in the contract. The function `withdrawAll()` allows the owner to withdraw all tokens from the contract, which could cause the users' principal to be lost. It's better to distinguish between two tokens or strictly record and protect the user's assets.

Logical issue of function `withdrawAll()`

The intervals of the packs are not involved in the calculation of reward. The reward should multiply the real number of days rather than 7.

Wrong Reward Calculation 

The linked `transfer()`/`transferFrom()` invocations do not check the return value of the function call which should yield a `true` result in case of a proper ERC-20 implementation.

Unchecked Value of ERC-20 `transfer()`/`transferFrom()` Call

SafeMath from OpenZeppelin is not used in the following functions which makes them possible for overflow/underflow and will lead to an inaccurate calculation result.

- function stakeTokens()
- function unStakeTokens()
- function _getPackage()
- function _lockReward()

SafeMath Not Used

The two checks in the function `unStakeTokens()` can be merged because the condition `_packIndex < stakerPackageList[msg.sender][_pack].length` covers `stakerPackageList[msg.sender][_pack].length > 0`.

Checks can be merged in function `unStakeTokens()`

Solidity integer division might truncate. As a result, performing multiplication before division can sometimes avoid loss of precision.

Divide Before Multiply

The codes mentioned are used for test only.

Codes for Test Only

In the contract `CRYPTERIUM_STAGING_B1`, the role `PAUSER_ROLE` has authority over the following functions:
- function pause() and unpause(), to pause or unpause the contract.
The role `BURNER_ROLE` has authority over the following function:
- function burnFrom(), to burn tokens from users.
The role `UPGRADER_ROLE` has authority over the following function:
- function `_authorizeUpgrade()`, to change proxy contract.

Any compromise to the privileged accounts may allow a hacker to take advantage of this authority and bring unpredictable damages to the project.

Centralization Related Risks in CRYPTERIUM_STAGING_B1

The function costs the allowance of the spender and requires the `BUNNER_ROLE` permission at the same time. Usually, `burnFrom()` is like the function `transferFrom()` which does not need permission control. 

Discussion on `burnFrom()`

In the contract `CRYPTERIUM_CROWDSALE_STAGING_B1`, the role `onlyOwner` has authority over the following functions:
- function withdrawAll(), to withdraw tokens from the contract.
- function withdrawHistory(), to view the `withdrawCounter`.

AND

In the contract `Ownable`, the role `owner` has authority over the following functions:
- function reounceOwnership() and transferOwnership(), to renounce or transfer the ownership.

AND

In the contract `Secondary`, the role `primary` has authority over the following function:
- function transferPrimary(), to transfer the `primary` role.

AND

In the contract `WhitelistAdminRole`, the role `whitelistAdmin` has authority over the following functions:
- function addWhitelistAdmin(), to add other accounts as `whitelistAdmin`.

AND

In the contract `WhitelistedRole`, the role `whitelistAdmin` has authority over the following functions:
- function addWhitelisted() and removeWhitelisted(), to add or remove `whitelistAdmins`.

Any compromise to the privileged accounts may allow a hacker to take advantage of this authority and bring unpredictable damages to the project.

Centralization Related Risks in `CRYPTERIUM_WHITELISTED_STAGING_B1`

In the contract `CRYPTERIUM_STAKING_STAGING_B1`, the role `owner` has authority over the following functions:
- function setPoolLimitWei(), to set _poolLimitWei.
- function setLockedRewardWallet(), to set _lockedRewardWallet.
- function withdrawAll(), to withdraw tokens from the contract.

AND

In the contract `Ownable`, the role `owner` has authority over the following functions:
- function reounceOwnership() and transferOwnership(), to renounce or transfer the ownership.

AND

In the contract `Secondary`, the role `primary` has authority over the following function:
- function transferPrimary(), to transfer the `primary` role.

Any compromise to the privileged accounts may allow a hacker to take advantage of this authority and bring unpredictable damages to the project.

Centralization Related Risks in CRYPTERIUM_STAKING_STAGING_B1

The address `wallet` and `owner` are the receivers of the native token and erc20. And the ways to record the history are also different. 

Discussions on `CRYPTERIUM_WHITELISTED_STAGING_B1`

In the contract `Ownable`, the role `owner` has authority over the following functions:
- function renounceOwnership(), to renounce the ownership.
- function transferOwnership(), to transfer ownerhsip to others.

AND

In the contract `ProxyAdmin`, the role `owner` has authority over the following functions:
- function changeProxyAdmin(), to change the admin of the proxy contract.
- function upgrade(), to change the proxy implementation.
- function upgradeAndCall(), to change the proxy implementation and perform a call.

AND

In the contract `TransparentUpgradeableProxy`, the role `admin` has authority over the following functions:
- function admin(), implementation() to get the info of admin or implementation.
- function implementation()
- function changeAdmin(), to change the admin.
- function upgradeTo(), to change the implementation.
- function upgradeToAndCall(), to change the implementation and perform a call.

Any compromise to the `owner` or `admin` account may allow a hacker to take advantage of this authority and bring unpredictable damages to the project.

Centralization Related Risks in ERC1967Proxy

A `whitelistadmin` can set other `whitelistadmin`, which is dangerous when untrusted users become `whitelistadmin`. And except for users' own renouncing, there is no way to unset the untrusted admin.

Administrator Problems of `whitelistAdmin`

Crypterium Game

ContextUpgradeable.sol

Proxy.sol

Crypterium%20Game

SafeERC20.sol

ERC165Upgradeable.sol

Crypterium Fantasy

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

19

0

9

1

9