We released a brand new security service
Check it out
Summary
Vidma team has conducted a smart contract audit for the given codebase. The contracts are in good condition. Based on the fixes provided by the Ammbr team and on the quality and security of the codebase provided, Vidma team can give a score of 95 to the audited smart contracts.
During the auditing process, the Vidma team has found a couple of informational issues, 7 issues with a low level of severity, 1 issue with a medium level of severity, and 3 issues with a critical level of severity.
Evaluating the findings, we can assure that the contract is safe to use and all the issues found are performed only by certain conditions and cases. Under the given circumstances we can set the following risk level:
.svg)
High Confidence
Vidma auditors are evaluating the initial commit given for the scope of the audit and the last commit with the fixes. Hence, it helps to adequately evaluate the development quality.
Applicature auditing team has conducted a bunch of integrated autotests to ensure that the given codebase has decent performance and security levels. The test results and the coverage can be found in the accompanying section of this audit report.
Issue severity
Based on the given findings, risk level, performance, and code style, Vidma team can grant the following overall score:
95.00
Vidma auditing team has conducted a bunch of integrated autotests to ensure that the given codebase has decent performance and security levels. The test results and the coverage can be found in the accompanying section of this audit report.
Please mind that this audit does not certify the definite reliability and security level of the contract. This document describes all vulnerabilities, typos, performance issues, and security issues found by Vidma auditing team. If the code is under development, we recommend run one more audit once the code is finalized.
.svg)
Scope of work
Ammbr applies systems thinking to dynamically map out the influencing factors for each project. They establish relationships with partners who create added value and bring together the public and private sectors.
Within the scope of this audit, two independent auditors deeply investigated the given codebase and analyzed the overall security and performance of smart contracts.
The debrief took place from Jan 10th to 26th, 2022 and the final results are present in this document.
Applicature auditing team has made a review of the following contracts:
- Migrations.sol
- QC.sol
The source code was taken from the following source - https://github.com/AmmbrFi/qc-contract/commit/4a3a40c6cd8a8756d4d214f30d85c1c6edb1a3cd
Initial commit submitted for the audit - https://github.com/AmmbrFi/qc-contract/commit/4a3a40c6cd8a8756d4d214f30d85c1c6edb1a3cd
Last commit - https://github.com/AmmbrFi/qc-contract/commit/03a39cfb80030ef5c9952d4ef54f228aaf86ecab
In order to conduct a more detailed audit, Ammbr has provided the following documentation: https://github.com/AmmbrFi/qc-contract/blob/master/docs.md
Workflow of the auditing process
During the manual phase of the audit, Vidma team manually looks through the code in order to find any security issues, typos, or discrepancies with the logic of the contract.
Within the testing part, Vidma auditors run integration tests using the Truffle testing framework. The test coverage and the tests themselves are inserted into this audit report.
Vidma team uses the most sophisticated and contemporary methods and techniques to ensure the contract does not have any vulnerabilities or security risks:
Re-entrancy;
Access Management Hierarchy;
Arithmetic Over/Under Flows;
Unexpected Ether;
Delegatecall;
Default Public Visibility;
Hidden Malicious Code;
Entropy Illusion (Lack of Randomness);
External Contract Referencing;
Short Address/Parameter Attack;
Unchecked CALL Return Values;
Race Conditions / Front Running;
General Denial Of Service (DOS);
Uninitialized Storage Pointers;
Floating Points and Precision;
Tx.Origin Authentication;
Re-entrancy;
Signatures Replay;
Pool Asset Security (backdoors in the underlying ERC-20).
Structure and organization of the findings
For the convenience of reviewing the findings in this report, Applicature auditors classified them in accordance with the severity of the issues. (from most critical to least critical). The acceptance criteria are described below.
All issues are marked as “Resolved” or “Unresolved”, depending on whether they have been fixed by Ammbr or not. The latest commit, indicated in this audit report should include all the fixes made.
To ease the explanation, the Applicature team has provided a detailed description of the issues and recommendations on how to fix them.
Hence, according to the statements above, we classified all the findings in the following way:
Finding
Description
Critical
The issue bear a definite risk to the contract, so it may affect the ability to compile or operate.
High
Major security or operational risk found, that may harm the end-user or the overall performance of the contract.
Medium
The issue affects the contract to operate in a way that doesn’t significantly hinder its performance.
Low
Major security or operational risk found, that may harm the end-user or the overall performance of the contract.
Informational
The issue bear a definite risk to the contract, so it may affect the ability to compile or operate.
Manual Report
Resolved, Critical: Incorrect logic in mint() and burn() functions
Critical | Resolved
In mint() and burn() functions _totalSupply is changing but the value of _gonsPerFragment is not changing. It affects incorrect _gonBalances[user] calculation.
It triggers the following critical issues:
- When the user already has a significant amount of tokens on the balance, it is impossible to mint a certain amount to him. It happens because the new value of the user's balance exceeds the allocated limit for uint256 type variables.
- If mint or burn is called properly all balance calculations in all functions related to transfer are incorrect or even fail when the amount is too big because _gonsPerFragment is not valid according to the _totalSuply
Steps to reproduce:
User balance: 1000000000000000000000000 tokens.
Scaled balance: 115792089237316195423570985008687907853269984665640564000000000000000000000000
Minter try to mint 1 token for the user
Expected result:
- User balance 1000001000000000000000000 tokens
- Scaled balance:
115792089237316195423570985008687907853269984665640563725448000000000000000000
The real result:- transaction failed because gonValue + gonBalances[to] in result this value is too large and can’t be stored in the variable due to lack of dimensionality, which leads to transaction failure.
Recommendation:
Change the value of _gonsPerFragment variable to appropriate one every time you change the _totalSuply in burn() and mint() functions. As a suggestion possible solution to implement mint() function: