Gigzi smart contract security audit conclusion.

Gigzi_audit_conclusion.md

Gigzi smart contract security audit conclusion: bug fixing is necessary.

Critical issue:

• Fees Avoidance. User can direct call transferFromAndCall or transferAndCall implemented in OpenZeppelin ERC827Token to transfer token without fee collection and possible manipulation of the reward since it the reward won't be updated.

Medium severity issues:

• FeeableToken contract overload transfer and transferFrom methods, if a user directly call these functions to transfer tokens, it can lead to lost tokens issue.

• The account reward was updated after subtracting the burned tokens and that cause lower reward then must be.

• Estimation Account Reward in Percent Error.

Pay attention:

• Raw call to untrusted contract in MessageHelper.sol don't hurt Gigzi smart-contract, because it's not used, but you must know about it if you used it in future.

Revealing audit reports:

• https://gist.github.com/MrCrambo/422384ecf5a215be81bad6c9b5c2b605
• https://gist.github.com/RideSolo/55e07505b231f1cab7454d21ca8f8dc3
• https://gist.github.com/alexo18/f7014a8e941e81c98871b758196bdad7
• https://gist.github.com/gorbunovperm/0e0fa4e5a532a55672ed68649e51ccb4

@MrCrambo

Notes regarding the https://gist.github.com/MrCrambo/422384ecf5a215be81bad6c9b5c2b605 report.

1. Time in the contract use seconds, not in "millis" and it did not affect on account balance. It used for estimate account reward in percent.

Not a security issue.

2. All users who hold GZB tokens on their accounts will receive payments in GZG from the CA; a size of the payment will be proportional to the amount of GZB tokens on the account. Payments will be initiated by the CA at the end of a billing period, off-chain.

So estimate account reward in percent did not calculate directly in getAccountReward() function, but can calculate off-chain: rewardAccum * 100 / supplyTimeTotal

Not a security issue.

3. Modifier restricted was correct and no need to change.

Not a security issue.

4. Math operation in that lines can not be exploited for over- or under- flow, because it doesn't operate with user inputs.

Severity: low

Conclusion

You did not find critical issue. I strongly recommend that you review other audit reports and study the programming of contracts more thoroughly.

@RideSolo

Notes regarding the https://gist.github.com/RideSolo/55e07505b231f1cab7454d21ca8f8dc3 report.

I have only one note about the Gas Consumption. I agree that gas consumption optimization is very important, but it's not a security issue.

Conclusion

Your audit report is fine. You have done an in-depth analysis of the parent contracts from OpenZeppelin.

@alexo18

Notes regarding the https://gist.github.com/alexo18/f7014a8e941e81c98871b758196bdad7 report.

1. rewardPeriod is time period in seconds and no need to any other conversion.

Not a security issue.

2. Raw call to untrusted contract in MessageHelper.sol don't hurt Gigzi smart-contract, because it's not used. And it also has an appropriate comment.

3. EVM doesn't support concurrent call to a function. Not a security issue.

4. Flooding attack will have high cost attacker but without any profit. It can't affect to contract performance, but affect to blockchain size.

It is better to assign it low severity.

Conclusion

You did not find critical issue.

@gorbunovperm

Notes regarding the https://gist.github.com/gorbunovperm/0e0fa4e5a532a55672ed68649e51ccb4 report.

1. Lost reward after burning tokens - better to assign it medium severity.

Conclusion

You did not find critical issue.