This document is a security audit report performed by RideSolo, where GIGZI Project has been reviewed.
GIGZI project promess to issue regulated tokens (GZS silver, GZG gold, GZP platinum) backed by precious metals and also one non-regulated token GZB black. Round of rewards will be distributed to the holders of GZB tokens on their accounts in the form of regulated tokens following the project funding. GZB distribution is performed by ICO.
- GigBlack.sol github commit hash ffe57bdaf1b0d1fb29d182cd03c1890b3be50ac8.
- GigSilver.sol github commit hash ffe57bdaf1b0d1fb29d182cd03c1890b3be50ac8.
- GigGold.sol github commit hash ffe57bdaf1b0d1fb29d182cd03c1890b3be50ac8.
- GigPlatinum.sol github commit hash ffe57bdaf1b0d1fb29d182cd03c1890b3be50ac8.
- GigCrowdsale.sol github commit hash ffe57bdaf1b0d1fb29d182cd03c1890b3be50ac8.
- FeeableToken.sol github commit hash ffe57bdaf1b0d1fb29d182cd03c1890b3be50ac8.
- Migrations.sol github commit hash ffe57bdaf1b0d1fb29d182cd03c1890b3be50ac8.
- The OpenZeppelin contracts inherited by the project are excluded from the audit report, however the usage of this contracts were analyzed and errors due to their misuse were highlighted.
- MessageHelper.sol contained in the project repository is part of OpenZeppelin-solidity framework therefore omitted from the audit report.
8 issues were reported including:
-
1 high severity issues.
-
4 medium severity issues.
-
2 low severity issues.
-
1 minor remark.
FeeableToken contract inherit from ERC827Token, therefore any user can call transferFromAndCall or transferAndCall implemented in openzepplin ERC827Token to transfer token without fee collection, both functions call super.tranferFrom and super.transfer, hence calling the next base contract functions defined in StandardToken contract instead of the functions defined in FeeableToken therefore avoiding to pay the fees or possible manipulation of the reward since it the reward won't be updated.
This issue is applicable for GigBlack, GigSilver, GigGold, GigPlatinum Tokens contracts.
Reimplement transferFromAndCall and transferAndCall to override the inherited base contracts functions.
FeeableToken contract reimplement transfer and transferFrom methods, if a user direclty call these functions to transfer tokens, it can lead to lost tokens issue. Please note that even without reimplementation of the inherited functions, the ERC827 standard raise the same issue.
A user can send token to a contract address, where that contract doesn't implement any function to handle tokens.
This issue is applicable for GigBlack, GigSilver, GigGold, GigPlatinum Tokens contracts.
The oppenzepplin ERC827 implement function to avoid lost tokens issue but keep the previously inherited function of the ERC20 standard, developers should read in depth the ERC827 standard to be aware of its weaknesses.
The function setTxFeeCollector member of FeeableToken re-assign fee collector address but do not reset the reserved account old address to avoid fee collection, however addReservedAccount can be used but at the price of extending accountsReserved dynamic array.
The account reward is updated following the time that a user hold its tokens balance untill the next transfer or commit from the GIGZI team.
In the reimplmented function burn member of GigBlack contract, updateAccountReward is called after substracting the burned tokens which doesn't follow the same pattern previously used in processTransfer.
Call updateAccountReward before substracting the burned tokens.
this table is filled supposing that the previous described error (Account Reward Update Error when Burning Tokens) recommendation are took into account. this error is applicable even if the previously recommendation are not applied.
please note that this is an illustrative table, the number presented are proportional to the computation done in GigBlack contract, to show the problem 100 tokens will be burned at block 5.
| block | 0 | 1 | 2 | 3 | 4 | 5 | Account Reward |
|---|---|---|---|---|---|---|---|
| balance user 1 | 1000 | 1000 | 1000 | 1000 | 1000 | 1000 | 1000 * 5 |
| balance user 2 | 1000 | 1000 | 1000 | 1000 | 800 | 800 | 1000 * 3 + 800 * 2 |
| balance user 3 | 0 | 0 | 0 | 0 | 200 | 100 | 200 * 1 + 100 * 1 |
| Total sup | 2000 | 2000 | 2000 | 2000 | 2000 | 1900 |
When calling getAccountReward member of GigBlack after that tokens where burned and after the last comit the reward estimation will be wrong, let's use the previous table as example:
(Total users accounts rewards) / (supplyTimeTotal) = 1
(1000 * 5 + 1000 * 3 + 800 * 2 + 200 * 1 + 100 * 1) / (1900 * 5) = 1.042
Instead of 1 we get 1.042.
supplyTimeTotal should be set as state variable and updated almost the same way as a user account reward but only when tokens are burned, so we will get:
(Total users accounts rewards) / (supplyTimeTotal) = 1
(1000 * 5 + 1000 * 3 + 800 * 2 + 200 * 1 + 100 * 1) / (2000 * 4 + 1900 * 1) = 1
The reward of txFeeCollector address is updated at each call of processTransfer member of GigBlack contract, adding more gas consumption to user transaction when this address probably belongs to Gigzi team, no reason is advanced for this extra computation.
This issue is marked as medium due to the recurent way that it appears. Gas consumption optimization is an important step in contract development, many optimization can be performed on GigBlack and FeeableToken contracts to save users gas at excution time. We strongly advise the developers to review their code to optimize gas usage following gas comsumption rules.
The purpose of the Migration contract is unclear, no direct errors were found.
one critical issues has been found that need to be fixed to avoid possible loss for the project, other medium issues were also highlighted This contract has some logical errors that need to be fixed before launch of the ICO. The current version of the project cannot be used in live net.