Introduction
We express our gratitude to the Zeebu team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Zeebu builds a unified payment ecosystem that brings innovation to telecom invoice settlement process using blockchain technology making it faster, more transparent, and more efficient than traditional financial services.
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Zeebu
- Audited By
- Stepan Chekhovskoi
- Approved By
- Grzegorz Trawinski
- Website
- https://zeebu.com→
- Changelog
- 18/07/2024 - Preliminary Report, 18/07/2024 - Final Report
- Platform
- Base L2 (EVM)
- Language
- Solidity
- Tags
- ERC-20 Token
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope
- Commit
- d9546fcf70da24f362297d44391d53e6a0180856
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional Requirements and Technical Description are comprehensive.
Code quality
The code is clearly written.
The development environment is set up.
Test coverage
Code coverage of the project is 100% (branch coverage).
The contract is covered with tests.
System Overview
Zeebu Token is a ERC-20 Token implemented using the upgradeable pattern.
The initial token supply is 250M with 18 decimals. The corresponding amount of token is going to be burned on the Ethereum to keep the total supply.
Privileged roles
The smart contract owner is able to upgrade the contract implementation.
Risks
Centralized Minting to a Single Address: The project concentrates minting tokens in a single address, raising the risk of fund mismanagement or theft, especially if key storage security is compromised.
Flexibility and Risk in Contract Upgrades: The project's contracts are upgradable, allowing the administrator to update the contract logic at any time. While this provides flexibility in addressing issues and evolving the project, it also introduces risks if upgrade processes are not properly managed or secured, potentially allowing for unauthorized changes that could compromise the project's integrity and security.
Absence of Upgrade Window Constraints: The contract suite allows for immediate upgrades without a mandatory review or waiting period, increasing the risk of rapid deployment of malicious or flawed code, potentially compromising the system's integrity and user assets.
Findings
No vulnerabilities were foundAppendix 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
- d9546fcf70da24f362297d44391d53e6a0180856
- Technical Requirements
- README.md
Contracts in Scope
contracts/interfaces/IZeebuToken.solcontracts/ZeebuToken.sol