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 findings and their fixes we can certify that the contract is fully production-ready.
During the auditing process, Vidma team has found informational issues only.
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:
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. Code style, optimization of the contracts, amount, and risk level of the issues are taken into consideration. The Vidma team has developed the transparent scoring system presented below.
Issue severity
Based on the given findings, risk level, performance, and code style, Vidma team can grant the following overall score:
99.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
INOFolio is a user-friendly ecosystem of blockchain and AI applications built to power the streaming economy. Their vision is a universal system for turning attention into real-world goods and services.
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 on Oct 13th, 2021 and the final results are present in this document
Vidma auditing team has made a review of the following contracts:
- ICFolioltemHantler;
- IWOWSCryptofolio;
- IWOWSERC1155;
- Tokenlds;
- WOWSErc1155;
- WOWSMinterPauser.
The source code was taken from the following source:
https://github.com/wolvesofwallstreet/wolves.finance
Initial commit submitted for the audit:
81f841667cbae891138359d9a91684f17cf17867
Last commit:
48d6c3ce13acbcb099d9c69edeee10a3b57c1976
To conduct a more detailed audit, INOFolio has provided the following documentation:
https://drive.google.com/drive/folders/17f9Hr3Nn7kZW5cl9F_BrUgLgbSCKXyV1?usp=sharing
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, Vidma 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 INOFolio or not. The latest commit, indicated in this audit report should include all the fixes made.
To ease the explanation, the Vidma 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
Unnecessary contract inheritance
Informational | Resolved
The WOWSMinterPauser inherits Context and AccessControl contracts but AccessControl already inherits Context.
Also regarding this conversation, the use of Context “doesn’t by itself provide any more security”, it should be used in solutions that support meta-transactions or upgradeable contracts. Since there is no such mechanic, Context will only use gas instead of providing more security.
Recommendation:
Remove Context inheritance from WOWSMinterPauser.
Re-Audit:
Removed unnecessary inheritance.
Using string instead of keccak256 for declaring roles
Informational | Resolved
The WOWSMinterPauser uses AccessControl to give access to minting by specific role. To declare a role, use the bytes32 variable which is initialized by string. Since the string is a dynamic-size variable and bytes32 is fixed-size it can lead to unpredictable situations.
Recommendation:
Use keccak256 instead of string to declare roles for AccessControl.
Re-Audit:
Fixed.
Unused function in WOWSERC1155
Informational | Resolved
The WOWSERC1155 contract has an initialization function to set the owner and other variables. It has a check for the count of DEFAULT_ADMIN_ROLE to prevent it from being used more than one time. But DEFAULT_ADMIN_ROLE already has at least one address from the constructor. It means that it can’t be called. Also, this function can be called from any address, which means that anyone can set the owner of the first point will be fixed.
For proper use of initialization functionality, I recommend using this approach.
Recommendation:
One of three:
- Use OpenZeppelin initializable contract;
- Use initialize inside constructor call instead of _setupRole;
- Remove check for DEFAULT_ADMIN_ROLE count and add onlyOwner modifier.
Re-Audit:
Fixed.
Test Results
To verify the contract security and performance a bunch of integration tests were made using the Truffle testing framework.
Tests were based on the functionality of the code, business logic, and requirements and for the purpose of finding the vulnerabilities in the contacts.
In this section, we provide tests written by Vidma auditors.
Vidma Coverage – 97.14%
Industry Standard – 95%
It’s important to note that Vidma auditors do not modify, edit or add tests to the existing tests provided in the INOFolio repo. We write totally separate tests with code coverage of a minimum of 95%, to meet the industry standards.
Tests are written by Vidma
Test Coverage
Test Results
We are delighted to have a chance to work together with INOFolio team and contribute to their success by reviewing and certifying the security of the smart contracts.
The statements made in this document should not be interpreted as investment or legal advice, nor should its authors be held accountable for decisions made based on them.
.svg)
