Audit name:
[SCA] Smobler Studios / NFT-Claim / Jan2024
Date:
Feb 15, 2024
Table of Content
Introduction
We express our gratitude to the Smobler Studios team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
This project consists on a set of contracts that allow the creation and management of ERC721 and ERC1155 collections: creation, minting, claiming, trading.
| title | content |
|---|---|
| Platform | SMOBLER STUDIOS |
| Language | SOLIDITY |
| Tags | NFT, MARKETPLACE |
| Timeline | 23/01/2024 - 15/02/2024 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/dev-andreavendrame/SoftTokenMarketplace→ |
| Commit | 656f598 |
Review Scope
- Commit
- 656f598
Audit Summary
10/10
95%
10/10
10/10
The system users should acknowledge all the risks summed up in the risks section of the report
Document Information
This report may contain confidential information about IT systems and the intellectual property of the Customer, as well as information about potential vulnerabilities and methods of their exploitation.
The report can be disclosed publicly after prior consent by another Party. Any subsequent publication of this report shall be without mandatory consent.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Smobler Studios |
| Audited By | David Camps Novi |
| Approved By | Przemyslaw Swiatowiec |
| Website | Not provided. |
| Changelog | 31/01/2024 - Preliminary Report; 15/02/2024 - Final Report |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Smobler Studios
- Audited By
- David Camps Novi
- Approved By
- Przemyslaw Swiatowiec
- Website
- Not provided.
- Changelog
- 31/01/2024 - Preliminary Report; 15/02/2024 - Final Report
System Overview
Smobler Studios has developed an NFT management project with the following capabilities:
Create an ERC721 collection with some custom features like custom URI, third party minting and custom token IDs range.
Create a minter contract that allows the deployer sell ERC721 NFTs by creating allow lists, limited sale phases, pay with native currencies and ERC20 tokens and set a third-party to earn from each token sale.
Create a soft-token contract, a smart contract that simulates some of the ERC20 token features in a simplified way.
A simple marketplace for ERC721 and ERC1155 tokens that can be sold by selecting an ERC20 payment token.
An ERC1155 claimer contract that allows to claim ERC1155 tokens in pseudo-random way and in a simple way.
Privileged roles
All contracts have a Pauser role to lock certain functionalities when necessary. Additionally, each contract has specific roles.
CollectionMinter:
MANAGER_ROLE: Manages the creation, disabling, and whitelists for sale phases.
TEAM_MINTER_ROLE: Enables the team to mint NFTs outside sale phases, respecting collection max supply.
Erc721Collection:
MINTER_ROLE: Has the ability to call the safeMint function to mint new tokens for the collection.
URI_EDITOR_ROLE: Can change the URI of an existing token within the collection.
Erc1155Claimer:
MANAGER_ROLE: Can add/remove the permission for a specific wallet address to participate in a claim event anytime.
NFTS_OPERATOR_ROLE: Can send Erc1155 tokens to the smart contract in order to allow users to claim them through active claim events.
SnowTracker
MANAGER_ROLE: Can add and remove tokens to the balance of users.
SPENDER_ROLE: Can spend the tokens of users, removing them from their balances.
SnowMarketplace:
MANAGER_ROLE: Can activate and deactivate the marketplace, and update the snow contract address.
ORDERS_MANAGER_ROLE: Can create and cancel orders, and send ERC1155 tokens to the contract.
Executive Summary
Documentation quality
The total Documentation Quality score is 10 out of 10.
Functional requirements are sufficient.
Technical description is provided.
Code quality
The total Code Quality score is 10 out of 10.
The development environment is configured.
Presence of unused variables.
Inefficient gas modeling
Missing best practices implementations
Test coverage
Code coverage of the project is 95% (branch coverage).
Deployment and basic user interactions are not covered with tests.
Negative cases coverage is missed.
Interactions by several users are not tested thoroughly.
Security score
Upon auditing, the code was found to contain 0 critical, 0 high, 3 medium, and 1 low severity issues. All issues were fixed during the remediation part of this audit, leading to a security score of 10 out of 10.
All identified issues are detailed in the “Findings” section of this report.
Summary
The comprehensive audit of the customer's smart contract yields an overall score of 9.8. This score reflects the combined evaluation of documentation, code quality, test coverage, and security aspects of the project.
Risks
ERC20, ERC1155 and ERC721 token standards are used in the project by the project owners and/or third parties that will use the system. Although no whitelisting exists, the tokens are considered to be safe. Nevertheless, there is no guarantee that no malicious tokens will be used.
The system provides pseudo-random values in the contract ERC1155Claimer. As such, it should be noted that those values can be predicted since are obtained from preset values such as the msg.sender or gasLeft.
The project heavily relies on a roles system with high privileges, which can manipulate key aspects of the contracts since their intervention is required for the project to work as intended. Some of these roles rely on third parties, which are considered safe by the development team. Hence, users should be aware they are interacting with a highly centralized system and understand its consequences.
The pauser role has the capability to pause or unpause the contract at will, locking the functionalities of the contract without previous notice.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-0710 | Uncontrolled loop of storage interactions may lead to Denial Of Service | fixed | Medium | |
| F-2024-0696 | Incorrect return array may result in temporal denial of service | fixed | Medium | |
| F-2024-0693 | Incorrect array calculation may lead to temporal denial of service | fixed | Medium | |
| F-2024-0675 | Missing checks on transferring non-standard ERC20 tokens | fixed | Low | |
| F-2024-0732 | Incomplete NFT minting cap implementation | fixed | Observation | |
| F-2024-0731 | Incomplete implementation of ERC2981 royalties | accepted | Observation | |
| F-2024-0714 | Improper erc721Receiver standard implementation | fixed | Observation | |
| F-2024-0712 | Incorrect standard implementation leads to unusable functionality | fixed | Observation | |
| F-2024-0709 | Inefficient loop execution results in increased execution cost | fixed | Observation | |
| F-2024-0707 | Incorrect empty bytes data | fixed | Observation |
Identify vulnerabilities in your smart contracts.
Appendix 1. Severity Definitions
When auditing smart contracts, Hacken is using a risk-based approach that considers Likelihood, Impact, Exploitability and Complexity metrics to evaluate findings and score severities.
Reference on how risk scoring is done is available through the repository in our Github organization:
Severity | Description |
|---|---|
Critical | Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation. |
High | High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation. |
Medium | Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category. |
Low | Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score. |
Severity
- Critical
Description
- Critical vulnerabilities are usually straightforward to exploit and can lead to the loss of user funds or contract state manipulation.
Severity
- High
Description
- High vulnerabilities are usually harder to exploit, requiring specific conditions, or have a more limited scope, but can still lead to the loss of user funds or contract state manipulation.
Severity
- Medium
Description
- Medium vulnerabilities are usually limited to state manipulations and, in most cases, cannot lead to asset loss. Contradictions and requirements violations. Major deviations from best practices are also in this category.
Severity
- Low
Description
- Major deviations from best practices or major Gas inefficiency. These issues will not have a significant impact on code execution, do not affect security score but can affect code quality score.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://github.com/dev-andreavendrame/SoftTokenMarketplace→ |
| Commit | 656f598 |
| Whitepaper | Not provided |
| Requirements | ./README.md |
| Technical Requirements | ./README.md |
Scope Details
- Commit
- 656f598
- Whitepaper
- Not provided
- Requirements
- ./README.md
- Technical Requirements
- ./README.md