Vidma is pleased to present this audit report outlining our assessment of code, smart contracts, and other important audit insights and suggestions for management, developers, and users.
VRJAM is an immersive, live experience platform built on the Matic blockchain designed to magnify the connectedness of human beings in virtual space. VRJAM is a multiplayer social gaming and live events platform.
The audited scope included the Marketplace contract and VRJAMCollection. Marketplace allows users to create orders to swap the VRJAMCollection NFTs by proposing the price by the buyer which is approved by the seller. Swap of orders is possible only by signing the message by one of the participant seller or buyer. The platform will charge a fee for each closed order. VRJAMCollection is pausable. There is a possibility for the user with the pauser role to stop any transfer for all users on the platform.
During the audit process, the Vidma team found several issues. A detailed summary and the current state are displayed in the table below.
After evaluating the findings in this report and the final state after fixes, the Vidma auditors can state that the contracts are fully operational and secure. Under the given circumstances, we set the following risk level:
Our auditors are evaluating the initial commit given for the scope of the audit and the last commit with the fixes. This approach helps us adequately and sequentially evaluate the quality of the code. Code style, optimization of the contracts, the number of issues, and risk level of the issues are all taken into consideration. The Vidma team has developed a transparent scoring system presented below.
Evaluating the initial commit and the last commit with the fixes, Vidma audit team set the following codebase quality mark.
Score
Based on the overall result of the audit and the state of the final reviewed commit, the Vidma audit team grants the following score:
In addition to manual check and static analysis, the auditing team has conducted a number of integrated autotests to ensure the given codebase has an adequate performance and security level. The test results and coverage can be found in the accompanying section of this audit report.
Please be aware that this audit does not certify the definitive reliability and security level of the contract. This document describes all vulnerabilities, typos, performance issues, and security issues found by the Vidma audit team.
If the code is still under development, we highly recommend running one more audit once the code is finalized.
VRJAM is a metaverse platform that empowers rightsholders to create and share digital content and virtual events with global audiences.
Within the scope of this audit, two independent auditors thoroughly investigated the given codebase and analyzed the overall security and performance of the smart contracts.
The audit was conducted from October 11, 2022 to October 12, 2022. The outcome is disclosed in this document.
The review of the fixes was done on Wednesday, October 19. The outcome is disclosed in this document.
The scope of work for the given audit consists of the following contracts:
The source code was taken from the following sources:
Repository 1:
https://github.com/vrjlive/VRJAM-ERC1155-Token
Initial commit submitted for the audit:
b27f5d509c26b846b7e7553605646deb676fd2ee
Last commit reviewed by the auditing team:
97406d0d47dd48bc05541a93d902b5e6367b2ed2
Repository 2:
https://github.com/vrjlive/VRJAM-Marketplace-LibOrder-Contract
Initial commit submitted for the audit:
481f6d1ba08b261b3789f782ae7aadea7ff6a4ba
Last commit reviewed by the auditing team:
7ef76e95980bad9f356fe8b26e92c247fd63bd33
As a reference to the contracts logic, business concept, and the expected behavior of the codebase, the VRJAM team has provided the following documentation:
https://vrjam.com/wp-content/uploads/2022/10/VRJAM-Whitepaper-v3.5.pdf.zip
Vidma audit team uses the most sophisticated and contemporary methods and well-developed techniques to ensure contracts are free of vulnerabilities and security risks. The overall workflow consists of the following phases:
After the Audit kick-off, our security team conducts research on the contract’s logic and expected behavior of the audited contract.
Vidma auditors do a deep dive into your tech documentation with the aim of discovering all the behavior patterns of your codebase and analyzing the potential audit and testing scenarios.
At this point, the Vidma auditors are ready to kick off the process. We set the auditing strategies and methods and are prepared to conduct the first audit part.
During the manual phase of the audit, the Vidma team manually looks through the code in order to find any security issues, typos, or discrepancies with the logic of the contract. The initial commit as stated in the agreement is taken into consideration.
Static analysis tools are used to find any other vulnerabilities in smart contracts that were missed after a manual check.
An interim report with the list of issues.
Within the testing part, Vidma auditors run integration tests using the Truffle or Hardhat testing framework. The test coverage and the test results are inserted in the accompanying section of this audit report.
Second interim report with the list of new issues found during the testing part of the audit process.
For simplicity in reviewing the findings in this report, Vidma auditors classify the findings in accordance with the severity level of the issues. (from most critical to least critical).
All issues are marked as “Resolved” or “Unresolved”, depending on if they have been fixed by project team or not. The issues with “Not Relevant” status are left on the list of findings but are not eligible for the score points deduction.
The latest commit with the fixes reviewed by the auditors is indicated in the “Scope of Work” section of the report.
The Vidma team always provides a detailed description of the issues and recommendations on how to fix them.
Classification of found issues is graded according to 6 levels of severity described below:
Low | ML – 01 | Resolved
In the Marketplace contract should be event emit for state variables overriding _beneficiary and _fee in the appropriate functions setBeneficiary() and setFee().
Consider the emitting events in these specific cases to be able to track critical data change.
Low | ML – 02 | Resolved
In the LibOrder library constant ORDER_TYPEHASH doesn't have variable visibility and it is public by default. Labeling the visibility explicitly makes it easier to catch incorrect assumptions about who can access the variable.
Consider defining visibility for this constant.
Low | TL – 01 | Resolved
There are unused imports in the codebase:
Consider removing useless imports to decrease the contract’s bytecode.
Low | TL – 02 | Resolved
Params event indexing is missed for MatchOrders() event of the Merketplace contract. The indexed parameters for logged events give the possibility to search for these events using the indexed parameters as filters (solidity official docs)
Consider adding event param indexing where it is missed.
Low | TL – 03 | Resolved
There is an assembly block that gets chain id in Marketplace contract but in the Solidity compiler version 0.8.* or higher block.chainid is available as a global variable.
Consider using block.chainid.
Low | TL – 04 | Resolved
The current version of solc in the audited contracts is ^0.8.4 and it is better to lock the pragma to a specific version.
Contracts should be deployed with the same compiler version and flags that they have been tested thoroughly. Locking the pragma helps to ensure that contracts do not accidentally get deployed using, for example, an outdated compiler version that might introduce bugs that affect the contract system negatively.
Consider locking pragma to a specific version.
Informational | MI – 01 | Unresolved
In the contracts Marketplace, VRJAMCollection and ERC1155 there are public functions that can be marked as external as they are not called anywhere inside the contract.
Consider changing visibility from public to external.
Consider changing visibility to external in next functions:
Informational | MI – 02 | Unresolved
The functions in contracts Marketplace and VRJAMCollection are not grouped according to their visibility and order.
Functions should be grouped according to their visibility and ordered in thefollowing way:
Consider changing functions order according to solidity documentation and style guide.
Informational | MI – 03 | Resolved
In the ERC1155 contract there is an unnecessary comment in 252 line.
Consider removing the unnecessary comments.
Informational | TI – 01 | Resolved
In the marketplace contract, there is pausable functionality. Based on the natspec it should not allow make orders when a contract is paused. But in fact matchOrders() function has no limitation and check for paused contract or not.
Consider removing pausable functionality in case it is useless or add whenNotPaused() modifier for matchOrders() function.
whenNotPaused() modifier for matchOrders() function was added.
To verify the security of contracts and their performance, a number of integration tests were carried out using the Truffle testing framework.
In this section, we provide both tests written by VRJAM and tests written by Vidma auditors.
VRJAM Coverage – 96.77%
Vidma Coverage – 100%
Industry Standard – 95%
It is important to note that Vidma auditors do not modify, edit or add tests to the existing tests provided in the VRJAM repository. We write totally separate tests with code coverage of a minimum of 95% to meet industry standards.
We are delighted to have a chance to work with the VRJAM team and contribute to your company's success by reviewing and certifying the security of your smart contracts.
The statements made in this document should be interpreted neither as investment or legal advice, nor should its authors be held accountable for decisions made based on this document.