Read the findings of the 2022 Web3 Security Report

`SafeMath` is no longer needed starting with Solidity >=0.8.0. The compiler now has built in overflow/underflow checking.


SafeMath Not Required For Solidity Version 0.8.0

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.

Missing Error Messages

In the contract `StakingCampaign` the role `_owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/a7279be264664dd18ee515328e3a5f2c/diagrams/centralization-StakingCampaign-_owner.svg)

In the contract `BatchTransfer` the role `_owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/a7279be264664dd18ee515328e3a5f2c/diagrams/centralization-BatchTransfer-_owner.svg)

In the contract `Jimizz` the role `_owner` has authority over the functions shown in the diagram below.

![](https://accelerator-tasks-prod.s3.amazonaws.com/a7279be264664dd18ee515328e3a5f2c/diagrams/centralization-Jimizz-_owner.svg)

Any compromise to the privileged account may allow the hacker to take advantage of this authority and switch owner, and modify critical configurations of the contracts or call the `drain()` or `drainERC20()` function to send all tokens to owner address. 


Centralization Risks

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

There should always be events emitted in the sensitive functions that are controlled by centralization roles.

Missing Emit Events

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

In the contract `EmergencyDrainable`, any user can call `drain()` and `drainERC20()` functions to drain tokens to owner. The contracts `StakingCampaign`, `GradedVesting`, and `Jimizz` all inherit the `EmergencyDrainable` contract, which means that the tokens that users stake to the staking contract, and the token balance that is pending collection by the beneficiary in the vesting contract could all be drained to the owner by anyone. 

In the contract `BatchTransfer`, the `drain()` function also does not have any access restriction and sends all token balance to the owner. 

Anyone Can Drain Contract Token Balance to Owner

All of the Jimizz 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. Any compromise to the deployer account may allow the attacker to steal and sell tokens on the market, resulting in severe damage to the project. 

Initial Token Distribution

In the following `for` loop, when the staked token at a certain index `i` is released, the last stake in the `stakeholders` array is swapped into the index `i` and the last index is popped off the array. Then the `for` loop continues execution and index `i` is incremented, meaning that the recently swapped stake is not evaluated whether it can be released. Initially this might not be problem, as the stakes are pushed to the end of the array when they are added, with increasing `endsOn` timestamp. When the swaps happen in the array, this condition might be no longer true, as the last stake with the highest `endsOn` timestamp is moved to an earlier index in the array, potentially causing some withdrawable stakes to be skipped when the `withdraw()` function is called. 

```solidity=157
  for (uint i = 0; i < stakeholders[index].stakes.length; i++) {
      if (
        stakeholders[index].stakes[i].endsOn <= block.timestamp &&
        stakeholders[index].stakes[i].amount > 0 // Just a double check
      ) {
        // Track released amount
        totalReleased = totalReleased.add(
          stakeholders[index].stakes[i].amount
        );

        // Remove stake
        uint size = stakeholders[index].stakes.length;
        stakeholders[index].stakes[i] = stakeholders[index].stakes[size - 1];
        stakeholders[index].stakes.pop();
      }
    }
```

The Withdraw() Function Might Miss Some Stakes Available for Withdrawal

Mathematical operations in the aforementioned function perform divisions before multiplications. Performing multiplication before division can sometimes avoid loss of precision. Also, `div(100)` and `mul(100)` cancel each other out and there is no need to include them. 

Division Before Multiplication

Jimizz

BatchTransfer.sol

Jimizz.sol

StakingCampaign.sol

Jimizz

Highlights & Alerts

This is just a placeholder

highlight placeholder lorem Ipsum...

highlight lorem

This is a alert demo

Alert demo

Code Audit History

10

0

0

2

8