Audit name:
[SCA] Hubz | Hubz-Aidrop | Dec2024
Date:
Dec 18, 2024
Table of Content
Introduction
We express our gratitude to the Hubz team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Hubz is a Jetton Airdrop solution.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Hubz |
| Audited By | Olesia Bilenka |
| Approved By | Ataberk Yavuzer |
| Website | http://hubz.io/→ |
| Changelog | 11/12/2024 - Preliminary Report |
| 18/12/2024 - Final Report | |
| Platform | TON |
| Language | FunC |
| Tags | Fungible Token; Airdrop |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Hubz
- Audited By
- Olesia Bilenka
- Approved By
- Ataberk Yavuzer
- Website
- http://hubz.io/→
- Changelog
- 11/12/2024 - Preliminary Report
- 18/12/2024 - Final Report
- Platform
- TON
- Language
- FunC
- Tags
- Fungible Token; Airdrop
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/cumberlandlabs/hubz_airdrop→ |
| Commit | fd54f18 |
Review Scope
- Commit
- fd54f18
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report.
Documentation quality
Functional requirements are not provided.
Technical description is not provided.
Code quality
The code mostly follows best practices.
The development environment is configured.
Test coverage
Code coverage of the project can not be calculated due to the lack of a test coverage measurement tool for func.
Deployment and basic user interactions are covered with tests
System Overview
Hubz is a Jetton airdrop system with the following contracts:
airdrop - is a contract designed to process Jetton token airdrop claims. It enables the validation of claims and token transfers.
airdrop-helper - is a smart contract responsible for managing claims in the context of an airdrop system. It ensures that claims are validated, prevents duplicate claims, and securely interacts with the airdrop contract to process and confirm claims.
constants - is a contract that defines constants for operation codes, error codes, and balance requirements. Operation codes identify actions like wallet deployment, claim processing, and token transfers. Error codes standardize failures such as duplicate claims, insufficient balance, and invalid proofs. Balance and fee constants ensure the contract maintains the minimum required funds for smooth execution.
jetton-minter — is a smart contract that manages jetton token issuance, minting, and burning, as well as wallet address provision. It stores key data such as the total supply of jettons, admin address, and jetton wallet code. The contract allows for minting of new jettons, which can only be performed by the admin, and tracks token ownership through jetton wallets. It also handles burn notifications, reducing the total supply when tokens are burned. Additionally, the contract supports changing the admin and updating content, along with providing wallet addresses upon request.
jetton-wallet — is a contract that manages the transfer, reception, and burning of jettons for individual wallet addresses. It tracks the balance of jettons, the owner’s address, the associated master contract address, and the wallet code. The contract handles both internal and external transfers, ensuring that the sender has a sufficient balance and that all transfers are processed securely. It also supports burning jettons, reducing the balance accordingly, and can receive tokens from the master contract. Additionally, the contract is capable of sending notifications about token burns and transfers while preventing failed actions in the computation phase to avoid bouncing messages.
jetton-utils — is a contract that provides functions that compile data about the balance, owner address, master address, and wallet code into a cell. Based on this data, the wallet state is generated. The wallet address is then created by hashing the state and constructing a slice representing the wallet's address.
op-codes - is a contract that provides constants that represent operation codes for various actions in the smart contract. The codes do actions such as transferring tokens, sending notifications for transfers or burns, internal transfers, handling excess tokens, and minting new tokens by the minter. Each operation is associated with a unique hexadecimal value for easy identification during contract execution.
params - is a contract that provides a workchain function that returns the current workchain, which is set to 0. The force_chain function checks if the workchain ID of a given address matches the current workchain and throws an error if it doesn't, ensuring that operations are only performed within the specified workchain.
stdlib - is a library that provides standard FunC functions.
Privileged roles
The admin of the jetton-minter contract has the exclusive ability to mint tokens, change the admin address, and update contract content.
Potential Risks
Centralized Control of Minting Process: The token contract’s design allows for centralized control over the minting process, posing a risk of unauthorized token issuance, potentially diluting the token value, and undermining trust in the project's economic governance.
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, acting contract integrity and user trust, especially during critical operations like minting phases.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2024-7589 | Missing Bounced Messages Handling | accepted | Low | |
| F-2024-7588 | Potential Transaction Failures Due to Hardcoded Fees | accepted | Low | |
| F-2024-7587 | Magic Numbers Usage Reduces Code Readability | accepted | 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://github.com/cumberlandlabs/hubz_airdrop→ |
| Commit | fd54f18063824c79946797bae8891a2807fa994d |
| Whitepaper | N/A |
Scope Details
- Commit
- fd54f18063824c79946797bae8891a2807fa994d
- Whitepaper
- N/A