Introduction
We express our gratitude to the FATTY team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Document
- Name
- Smart Contract Code Review and Security Analysis Report for FATTY
- Audited By
- Viktor Raboshchuk, Viktor Raboshchuk
- Approved By
- Przemyslaw Swiatowiec
- Website
- https://fatboygame.io/→
- Changelog
- 21/06/2024 - Preliminary Report -02/07/24 - Final Report
- Platform
- Arbitrum One, Ethereum, BNB Chain
- Language
- Solidity
- Tags
- Presale
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope
- Commit
- 7a0f4875cf7366846c1f145d48054b9d5c511798
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are provided.
NatSpec is present.
Technical description is not provided.
Development environment is described.
Code quality
The code has sufficient quality.
Test coverage
Code coverage of the project is 83.59% (branch coverage).
Deployment and basic user interactions are covered with tests.
System Overview
FatBoy is a presale protocol with the following contracts:
PresaleClaiming - is a smart contract designed for managing the presale and claiming process of tokens. It integrates functionalities for buying tokens during a presale period, applying referral and volume bonuses, and facilitating the claiming of purchased tokens after the presale ends. This contract is upgradeable and uses a proxy pattern for deployment.
ReferralUSDTRewards.sol - is a smart contract that allows users to claim USDT rewards based on a Merkle proof, which verifies their eligibility and the amount claimed, with additional functionalities for setting the Merkle root by authorized server addresses and emergency withdrawals by the contract owner.
IClaiming.sol - interface for the PresaleClaiming contract.
IPresale.sol - interface for the PresaleClaiming contract.
Privileged roles
The owner of the PresaleClaiming contract can set referral bonus tiers, enable/disable referral bonuses, toggle volume buy bonuses, configure volume buy bonus tiers, change presale states, activate/deactivate claiming, set the treasury wallet and stable coin addresses (USDC and USDT), establish a minimum purchase amount, set the claimable token and withdraw tokens from the contract.
Accounts with SERVER_ROLE in the PresaleClaiming contract can set the presale phase.
The owner of the ReferralUSDTRewards contract can withdraw tokens from the contract.
Accounts with SERVER_ROLE in ReferralUSDTRewards contract can set the Merkle root.
Risks
The project utilizes Solidity version 0.8.20 or higher, which includes the introduction of the PUSH0 (0x5f) opcode. This opcode is currently supported on the Ethereum mainnet but may not be universally supported across other blockchain networks. Consequently, deploying the contract on chains other than the Ethereum mainnet, such as certain Layer 2 (L2) chains or alternative networks, might lead to compatibility issues or execution errors due to the lack of support for the PUSH0 opcode. In scenarios where deployment on various chains is anticipated, selecting an appropriate Ethereum Virtual Machine (EVM) version that is widely supported across these networks is crucial to avoid potential operational disruptions or deployment failures.
A potential risk exists with the contract being centralized around the setter for the currentPresalePhaseIndex. If the server role does not set this value accurately and in a timely manner, it could affect token distribution.
A potential risk exists with the emergencyWithdrawToken function, which can only withdraw claimableToken. In an emergency, no other tokens can be withdrawn using this function, except for native tokens, which can be withdrawn using the emergencyWithdrawNativeCoin function. This limitation can hinder access to other tokens during critical situations, affecting liquidity and operational flexibility.
PresaleClaiming.sol imports the AggregatorV3Interface from the Chainlink library, which is used to interact with external data feeds. This introduces a risk as the contract is dependent on these external data feeds for its operation. If these data feeds are compromised, manipulated, or become unavailable, it could impact the functionality and security of the contract.
buyTokensWert in the contract PresaleClaiming.sol relies on wert, a third-party payment processor. This introduces a risk as the contract's functionality is dependent on the reliability and security of this external service. If wert is compromised, experiences downtime, or if its API changes unexpectedly, it could disrupt the contract's operations.
The setPaymentToken function in the PresaleClaiming.sol contract checks the decimal places of a payment token when it is added as a payment method. If a non-standard token changes its decimal places after being added, the contract does not have a mechanism to re-validate or remove this token. This could lead to potential issues with transactions, as the contract assumes a fixed decimal place for each token.
The current implementation of MerkleProof.sol in the OpenZeppelin library exhibits a vulnerability when handling leaf data that is exactly 64 bytes in size. This issue, detailed in Issue #278 → from the sherlock-audit repository, enables an attacker to bypass the merkle-tree proof, leading to a security risks if the leaves are not built carefully. Additionally, this vulnerability is acknowledged with a warning in the MerkleProof.sol → contract(#3091 →).
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
F-2024-3964 | Incorrect Definition of Stablecoins Decimal | Mitigated | Critical | |
F-2024-4003 | Potential Loss of Purchased Tokens Due to Insufficient Payment Validation in _getTokensForCost Function | Mitigated | High | |
F-2024-4001 | Missing Threshold Leading to Possible Draining of Funds | Mitigated | High | |
F-2024-3997 | Hardcoded Price of Stablecoin | Fixed | High | |
F-2024-3962 | Contract Funds Can be Drained due to Wrong Cost Calculations | Mitigated | High | |
F-2024-3961 | Incorrect Decimal Assumption for ERC20 Tokens Causes Calculation Errors | Fixed | High | |
F-2024-4006 | Missing On-Chain Bonus Tokens for Referrer in _processReferralBonus | Mitigated | Medium | |
F-2024-3963 | Denial of Service Attack Due to Decimals Calculations | Fixed | Medium | |
F-2024-3960 | Missing Old Values Update During Stablecoin Address Set | Fixed | Low | |
F-2024-4014 | Missing UUPS Init Function Invocation | Fixed | Observation |
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
- 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
- Commit
- 7a0f4875cf7366846c1f145d48054b9d5c511798
- Whitepaper
- https://whitepaper.fatboygame.io/→
- Technical Requirements
- https://gitlab.cleevio.cz/cleeviox/backend/fatboy-presale-sc/-/blob/main/README.md→
Contracts in Scope
src/PresaleClaiming.solsrc/ReferralUSDTRewards.solsrc/interfaces/IClaiming.solsrc/interfaces/IPresale.sol