- Hacken
- Audits
- belong-net
- [SCA] Belong.net | EVM | Oct2024
Introduction
We express our gratitude to the Belong.net team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Belong.net allows users to create their own NFT collection, whose tokens represent invitations to the corresponding community.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Belong.net |
| Audited By | Niccolò Pozzolini |
| Approved By | Przemyslaw Swiatowiec |
| Website | https://belong.net/→ |
| Changelog | 11/11/2024 - Preliminary Report; 15/11/2024 - Remediation Report |
| Platform | Ethereum, Skale, Polygon, Celo, Linea |
| Language | Solidity |
| Tags | NFT, ERC71, Royalties |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Belong.net
- Audited By
- Niccolò Pozzolini
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://belong.net/→
- Changelog
- 11/11/2024 - Preliminary Report; 15/11/2024 - Remediation Report
- Platform
- Ethereum, Skale, Polygon, Celo, Linea
- Language
- Solidity
- Tags
- NFT, ERC71, Royalties
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://gitlab.com/nomadhub/smart-contracts→ |
| Commit | f12535c |
Review Scope
- Commit
- f12535c
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are complete.
Technical description is provided.
Code quality
The development environment is configured.
Test coverage
Code coverage of the project is 98.94% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases are covered.
Interactions by several users are tested thoroughly.
System Overview
The Belong.net project is designed to enable users to create and manage their own NFT collections. These collections serve as invitations to specific communities or hubs. The platform provides a comprehensive framework for deploying NFT collections, managing royalties, and facilitating transactions, all while ensuring compliance with specified rules and conditions.
It is composed by the following contracts:
NFTFactory: This is the core contract responsible for deploying new NFT collections. It allows creators to specify collection parameters such as name, symbol, contractURI, mint price, and more.
ReceiverFactory: This contract is used to create instances of the RoyaltiesReceiver contract. It facilitates the deployment of royalty management contracts for each new collection.
RoyaltiesReceiver: This contract handles the distribution of royalties from secondary sales. It ensures that both the creator and the platform receive their respective shares of the royalties, calculated based on predefined formulas.
NFT: Implements the minting and transfer functionality for NFTs. It includes features for transfer validation and royalty management, ensuring that all transactions comply with the platform's rules.
CreatorToken: This contract enables the use of a transfer validator to ensure that token transfers are valid and authorized.
ReferralSystem: Provides functionality for creating and managing referral codes. It allows users to generate referral codes that can be used during collection creation, offering a percentage of commissions from mint tokens to the referral code creator.
Privileged roles
NFTFactory.Owner: The owner of the contract has the authority to set new factory parameters, including the signer address, default payment currency, transfer validator, and maximum array size. The owner can also set the platform address and commission.
NFT.Owner: The owner of the contract has the authority to perform several administrative actions. This includes setting automatic approval of transfers from the validator, updating the paying token and mint prices
Potential Risks
Commits Containing Additional Code in the Remediation Stage: During the remediation phase of this audit, code that was not directly related to the fixes was introduced. This poses a risk of new vulnerabilities emerging from the additional code, which was not reviewed by Hacken's team. To ensure that no security issues are overlooked in these commits, we recommend conducting a re-audit.
Dynamic Array Iteration Gas Limit Risks: The project iterates over potentially large dynamic arrays, which leads to excessive gas costs, risking denial of service due to out-of-gas errors, directly impacting contract usability and reliability.
Dependency on Unaudited External Libraries: The project utilizes libraries or contracts without security audits, potentially introducing vulnerabilities. This compromises the security of the audited system, making it susceptible to attacks exploiting these external weaknesses.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-6997 | Third Payee Addition Allows Single Payee to Manipulate Shares | fixed | High | |
| F-2024-7056 | Denial of Service Vulnerability in releaseAll Function | fixed | Medium | |
| F-2024-7096 | Redundant Use of unchecked Block for Increment Operations | fixed | Observation | |
| F-2024-7095 | Unvalidated Referral Percentages Can Lead To Overflow | mitigated | Observation | |
| F-2024-7094 | Lack of Input Validation in setPlatformParameters Function | mitigated | Observation | |
| F-2024-7088 | Missing _disableInitializers() in Upgradable Contract Constructor | fixed | Observation |
Appendix 1. Definitions
Severities
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. |
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.
Potential Risks
The "Potential Risks" section identifies issues that are not direct security vulnerabilities but could still affect the project’s performance, reliability, or user trust. These risks arise from design choices, architectural decisions, or operational practices that, while not immediately exploitable, may lead to problems under certain conditions. Additionally, potential risks can impact the quality of the audit itself, as they may involve external factors or components beyond the scope of the audit, leading to incomplete assessments or oversight of key areas. This section aims to provide a broader perspective on factors that could affect the project's long-term security, functionality, and the comprehensiveness of the audit findings.
Appendix 2. Scope
The scope of the project includes the following smart contracts from the provided repository:
Scope Details | |
|---|---|
| Repository | https://gitlab.com/nomadhub/smart-contracts→ |
| Commit | f12535cb8211186081ccd9f590fee50a4a82208d |
| Requirements | https://gitlab.com/nomadhub/smart-contracts/blob/feat/royalties/README.md→ |
| Technical Requirements | https://gitlab.com/nomadhub/smart-contracts/blob/feat/royalties/README.md→ |
Scope Details
- Commit
- f12535cb8211186081ccd9f590fee50a4a82208d
- Technical Requirements
- https://gitlab.com/nomadhub/smart-contracts/blob/feat/royalties/README.md→
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring that the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.