Audit name:
[SCA] RoOLZ | GodlJetton | Sep2024
Date:
Oct 11, 2024
Table of Content
Introduction
We express our gratitude to the RoOLZ team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
GodlJetton is a fungible token contract.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for RoOLZ |
| Audited By | Olesia Bilenka |
| Approved By | Ataberk Yavuzer |
| Website | https://roolz.ai→ |
| Changelog | 11/10/2024 - Preliminary Report |
| 11/10/2024 - Final Report | |
| Platform | TON |
| Language | FunC |
| Tags | Fungible Token |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for RoOLZ
- Audited By
- Olesia Bilenka
- Approved By
- Ataberk Yavuzer
- Website
- https://roolz.ai→
- Changelog
- 11/10/2024 - Preliminary Report
- 11/10/2024 - Final Report
- Platform
- TON
- Language
- FunC
- Tags
- Fungible Token
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/ROoLZOrg/GodlJetton→ |
| Commit | 0a97140 |
Review Scope
- Repository
- https://github.com/ROoLZOrg/GodlJetton→
- Commit
- 0a97140
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 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.
Tests were not provided.
System Overview
GodlJetton is a jeton token project with the following contracts:
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 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.
constants — is a contract that defines key operations like increment, deposit, withdraw, and transfer of ownership. Errors include unknown operations, access denial, and insufficient balance. Additionally, there are parameters for minimum storage fees and gas consumption, both set at 0.01 TON.
discovery-params —is a contract that defines two operations for wallet address management: providing and taking a wallet address, each associated with a unique constant. The is_resolvable? function checks whether an address belongs to the current workchain by comparing the workchain ID from the address with the contract's workchain.
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 which represent operation codes for various actions in the smart contract. The codes define 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 workchain function which 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.
utils — is a contract that provides sendgrams function which creates a message to send a specified amount of tokens to a given address. It formats the message with a bounce flag, stores the recipient address and the amount, and indicates that no additional data is attached. The message is then sent using the sendraw_message function, with mode 3, ensuring that errors are ignored and the sender covers the fees.
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, affecting contract integrity and user trust, especially during critical operations like minting phases.
Findings
No vulnerabilities were foundAppendix 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/ROoLZOrg/GodlJetton→ |
| Commit | 0a97140eadd1ea4c21848aba33b963c4856e12a7 |
| Whitepaper | Not provided |
Scope Details
- Repository
- https://github.com/ROoLZOrg/GodlJetton→
- Commit
- 0a97140eadd1ea4c21848aba33b963c4856e12a7
- Whitepaper
- Not provided