- Hacken
- Audits
- fore-innovation-ltd-fore-protocol
- [SCA] FORE Protocol | ERC721 + Marketplace | Oct2023
Audit name:
[SCA] FORE Protocol | ERC721 + Marketplace | Oct2023
Date:
Oct 25, 2023
Table of Content
Introduction
We express our gratitude to the FORE Innovation LTD (FORE Protocol) team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
FORE Protocol is a peer-to-peer predictions protocol that enables users to create, participate in, and validate prediction markets in a dynamic and play-to-earn format.
| title | content |
|---|---|
| Platform | Ethereum, Arbitrum |
| Language | Solidity |
| Tags | Non-fungible Token, Marketplace, Factory, Gamify |
| Timeline | 14/08/2023 - 24/10/2023 |
| Methodology | https://hackenio.cc/sc_methodology→ |
Review Scope | |
|---|---|
| Repository | https://github.com/FOREProtocol/contracts→ |
| Commit | 910f87a02874128e12b94637b6b5514c790c7bf2 |
Review Scope
- Commit
- 910f87a02874128e12b94637b6b5514c790c7bf2
Audit Summary
10/10
100%
9/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 FORE Innovation LTD (FORE Protocol) |
| Audited By | Hacken |
| Website | https://www.foreprotocol.io/→ |
| Changelog | 14/08/2023 – Initial Review |
| 29/09/2023 – Second Review | |
| 24/10/2023 – Third Review |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for FORE Innovation LTD (FORE Protocol)
- Audited By
- Hacken
- Changelog
- 14/08/2023 – Initial Review
- 29/09/2023 – Second Review
- 24/10/2023 – Third Review
System Overview
FORE Protocol is a peer-to-peer predictions protocol that enables users to create, participate in, and validate prediction markets in a dynamic and play-to-earn format. FORE Protocol provides the architecture to allow users to create a prediction market for almost any outcome, and rewards them for doing so through the redistribution of protocol fees.
The files in the scope:
ERC721NFTMarketV1.sol — base contract for ForeNftMarketplace.sol.
ICollectionWhitelistChecker.sol - checks if a token can be listed on the ForeNftMarketplace.sol.
ForeNftMarketplace.sol - the FORE Protocol NFT Marketplace.
ForeProtocol.sol - main protocol contract responsible for the storing and validation of the markets data, minting Verifier NFT and increasing or decreasing the power of the Verifier NFT.
IForeProtocol.sol - interface for the ForeProtocol.sol.
IMarketConfig.sol - interface for the MarketConfig.sol.
IProtocolConfig.sol - interface for the ProtocolConfig.sol.
MarketConfig.sol - records the values applied for each marketplace separately.
ProtocolConfig.sol - stores configuration of the ForeProtocol.sol, applies changes for all markers.
BasicFactory.sol - factory contract responsible for creation new BasicMarket.sol.
BasicMarket.sol - base protocol prediction market contract.
library/MarketLib.sol - library for the BasicMarket.sol.
ForeVerifiers.sol - Analyst NFT holding, which will allow to verify market results.
IForeVerifiers.sol - interface for the ForeVerifiers.sol.
Privileged roles
ForeNftMarketplace.sol
Owner - can recover ERC20/NFTs tokens sent to the contract by mistake, can set/update admin and treasury address.
Admin - can add a new , close existing amd modify collections, can update minimum and maximum prices for a token.
ProtocolConfig.sol
Owner - can set factory statuses, edit tiers, update market configurations, can change foundation and high guard accounts, marketplace contract address, verifier mint price and market creation price
BasicMarket.sol
Factory - can initialize new market.
Verifiers - can perform verification.
High guard - can resolve a dispute.
Market Creator - can withdraw market creator reward.
ForeProtocol.sol
Owner - can change base URI.
Whitelisted factory - can create new markets.
ForeVerifiers.sol
Owner - can change base URI, protocol contract, enables or disables transferability feature.
Protocol - can mint token with defined power.
Fore operator - can increase validation for chosen Id, increase token power, can transfer verifier NFT’s from any address.
Fore market - can decrease token power.
Verifier token Id owner - can decrease power.
Executive Summary
Documentation quality
The total Documentation quality score is 10 out of 10.
Project overview is detailed.
All roles in the system are described.
Use cases are described and detailed.
For each contract all futures are described.
All interactions are described.
Technical description is robust.
Run instructions are provided.
Technical specification is provided.
NatSpec is sufficient..
Code quality
The total Code quality score is 9 out of 10.
The development environment is configured.
Solidity Style Guide violations.
Test coverage
Code coverage of the project is 100% (branch coverage).
Deployment and basic user interactions are covered with tests.
Negative cases coverage is present.
Interactions with several users are tested thoroughly.
Security score
Upon auditing, the code was found to contain 6 critical, 5 high, 6 medium, and 5 low severity issues. Out of these, 15 issues have been addressed and resolved, 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
Dispute outcomes rely solely on the decisions of the HighGuard. This centralization can lead to potential biases or inaccuracies in dispute resolutions, putting the fairness of the system at risk.
Market creators are tasked with setting accurate timelines for predictions. If a prediction remains active even after real-world results are known, malicious actors could exploit this oversight, voting with certainty and gaining undue benefits at the expense of regular users. It is crucial to ensure timeline accuracy to maintain the fairness of the prediction market.
In the event of a dispute, users' tokens and verifiers' NFTs are held in the contract. Access and retrieval of these assets are paused until the dispute is resolved by the HighGuard. This may result in unforeseen delays in accessing assets.
The platform's prediction market may become "one-sided" when all participants vote for the same outcome. In such cases, the market automatically closes as 'INVALID'. This approach has potential drawbacks: \-Highly predictable events may lead all users to choose the same result. This can unexpectedly invalidate the market, potentially causing dissatisfaction among participants. \-When a market becomes one-sided, there's no opposing side to distribute rewards from. As a result, participants may not receive the rewards they anticipated.
Incorrect market results might be accepted if no dispute is raised within the given 12-hour window. This can lead to users losing rewards to the wrong side and genuine validators being wrongly penalized with potential NFT burns. Users are advised to actively review validation outcomes and initiate disputes when discrepancies are observed.
In case a market is marked as INVALID, the market creator is not only denied any rewards but also forfeits the fee initially paid to create the market. This means market creators have financial disincentives in scenarios where the market outcome is deemed INVALID, potentially leading to financial losses for them.
The prediction market has no caps on the maximum amount a single verifier can contribute towards market verification. As a result, individual verifiers, if sufficiently funded, can influence a large portion or even the entirety of the market's verification.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2023-107 | Denial of Service Vulnerability; Invalid Calculations | fixed | Critical | |
| F-2023-1073 | Data Consistency | fixed | Critical | |
| F-2023-107 | Denial of Service Vulnerability | fixed | Critical | |
| F-2023-1071 | Unauthorized Access To Critical Functions | mitigated | Critical | |
| F-2023-1070 | Denial of Service Vulnerability | fixed | Critical | |
| F-2023-1069 | Mishandled Edge Case; Data Consistency | mitigated | Critical | |
| F-2023-1079 | Requirement Violation; Data Consistency | fixed | High | |
| F-2023-1078 | Requirements Violation | fixed | High | |
| F-2023-1077 | Coarse-Grained Access Control | mitigated | High | |
| F-2023-1076 | Requirements Violation; Data Consistency | fixed | High |
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/FOREProtocol/contracts→ |
| Commit | 910f87a02874128e12b94637b6b5514c790c7bf2 |
| Whitepaper | Provided→ |
| Requirements | Provided→ |
| Technical Requirements | Provided→ |