Smart Contract Audit

INOFolio
October 13, 2021

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.

Severity of the issue
Total found
Resolved
Unresolved
Critical
3 issues
3 issues
0 issues
High
3 issues
3 issues
0 issues
Medium
3 issues
3 issues
0 issues
Low
3 issues
3 issues
0 issues
Informational
3 issues
3 issues
0 issues
Low
3 issues
3 issues
0 issues

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.

Based on the given findings, risk level, performance, and code style, Vidma team can grant the following overall score:

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.

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.

Severity of the issue Issue severity Total found Resolved Unresolved
Critical 0 issues 0 issues 0 issues
High 0 issues 0 issues 0 issues
Medium 0 issues 0 issues 0 issues
Low 0 issues 0 issues 0 issues
Informational 3 issues 3 issues 0 issues
Total 3 issues 3 issues 0 issue


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.

Severity of the issue
Issue severity
Total found
Resolved
Critical
1
10
High
0.8
7
Medium
0.5
5
Low
0.2
0.5
Informational
0
0.1

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.

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

File
cfolio\interfaces\
ICFolioltemHantler.sol
token\
WOWSErc1155.sol
WOWSMinterPauser.sol
token\interfaces\
IWOWSCryptofolio.sol
IWOWSERC1155.sol
utils\
Tokenlds.sol
All Files
File % Stmts % Branch % Funcs % Lines
cfolio\interfaces\ 100.00 100.00 100.00 100.00
ICFolioltemHantler.sol 100.00 100.00 100.00 100.00
token\ 97.01 92.50 100.00 97.78
WOWSErc1155.sol 96.43 89.66 100.00 97.35
WOWSMinterPauser.sol 100.00 100.00 100.00 100.00
token\interfaces\ 100.00 100.00 100.00 100.00
IWOWSCryptofolio.sol 100.00 100.00 100.00 100.00
IWOWSERC1155.sol 100.00 100.00 100.00 100.00
utils\ 100.00 100.00 100.00 100.00
Tokenlds.sol 100.00 100.00 100.00 100.00
All Files 97.14 92.50 100.00 97.87


Test Results

Contract: WOWSMinterPauser

  • WOWSMinterPauser Phase Test Cases
    • should pause of contract correctly(1321ms)
    • shouldn't pause of contract if msg.sender isn't admin(898ms)
    • should burn correctly(774ms)
    • shouldn't burn if caller isn't owner or isn't approved(681ms)
    • should burn batch correctly(967ms)
    • shouldn't burn batch if caller isn't owner or isn't approved(1108ms)
    • should mint correctly(457ms)
    • shouldn't mint if msg.sender isn't minter(506ms)
    • shouldn't mint if address is zero(383ms)
    • shouldn't mint if transfer operation is paused(819ms)
    • should mint batch correctly(500ms)
    • shouldn't mint batch if msg.sender isn't minter(367ms)
    • shouldn't mint batch if address is zero(407ms)
    • shouldn't mint batch if array's lengths don't match(408ms)
    • shouldn't mint batch if transfer operation is paused(780ms)
    • should get result correctly if interface's support exist(377ms)

Contract: WOWSMinterPauser

  • WOWSErc1155 Phase Test Cases
    • should get uint256(-1) if id isn’t existed(417ms)
    • shouldn't initialize contract more than once(1733ms)
    • shouldn't set base metadata uri if msg.sender isn't admin(1055ms)
    • shouldn't set custom metadata uri if msg.sender isn't admin(1099ms)
    • shouldn't set cfolio metadata uri if msg.sender isn't admin(1447ms)
    • shouldn't set contract's metadata uri if msg.sender isn't admin(1411ms)
    • shouldn't set custom card level if msg.sender isn't minter(1041ms)
    • shouldn't set custom card level if curds isn't custom(484ms)
    • should set cfolio item type correctly(509ms)
    • shouldn't set cfolio item type if msg.sender isn't minter(366ms)
    • shouldn't set cfolio item type if tokenId is invalid(447ms)
    • should set approval for all correctly(444ms)
    • shouldn't set approval for all if caller isn't operator(468ms)
    • should get uri correctly(624ms)
    • should get token data correctly(1024ms)
    • should get cfolio item type correctly(588ms)
    • shouldn't get cfolio item type if id is incorrectly(175ms)
    • should do before token transfer correctly(1999ms)
    • should do before batch token transfer correctly(4710ms)
    • shouldn't do before batch token transfer if array's length is mismatch(2296ms)
    • shouldn't mint batch if amounts isn't 1(440ms)
    • shouldn't mint batch if already minted(2272ms)
    • should mint with cfolio token id correctly(1213ms)
    • should do before token transfer correctly if to is address of zero(2213ms)
    • shouldn't do before token transfer if data is invalid(484ms)
    • shouldn't do before token transfer if address of data is invalid(637ms)
    • shouldn't do before batch token transfer if count mismatch(3936ms)
    • should get mask hash correctly(179ms)
44 passing (5s)

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.