Audit name:
[SCA] VEREM | VEREM-Contracts | Mar2025
Date:
Mar 17, 2025
Table of Content
Introduction
We express our gratitude to the VEREM team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Verem is a fungible token contract.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for VEREM |
| Audited By | Olesia Bilenka |
| Approved By | Ivan Bondar |
| Website | https://verem.org→ |
| Changelog | 12/03/2025 - Preliminary Report |
| 17/03/2025 - 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 VEREM
- Audited By
- Olesia Bilenka
- Approved By
- Ivan Bondar
- Website
- https://verem.org→
- Changelog
- 12/03/2025 - Preliminary Report
- 17/03/2025 - Final Report
- Platform
- TON
- Language
- FunC
- Tags
- Fungible Token
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Codebase | https://verifier.ton.org/EQATmFZKR2_7Cx4ZYs_mRj2EBd37kJNYv8u3PpVPZFvhbqIi→ |
Review Scope
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
Several unused code parts were found.
The development environment is not configured.
Test coverage
Tests were not provided.
System Overview
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.
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.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-9112 | Potential Unexpected Jetton Content Changes After Deployment | mitigated | Observation | |
| F-2025-9111 | Missing Chain Validation for Admin Address Setting | mitigated | Observation | |
| F-2025-9110 | Inconsistent Operation Format in recv_internal of jetton-minter Contract | mitigated | Observation | |
| F-2025-9109 | Risk of Admin Control Loss in jetton-minter Contract | mitigated | Observation | |
| F-2025-9108 | Unused utils.fc and send_grams Function | mitigated | Observation | |
| F-2025-9107 | Unused Operation Codes in op-codes.fc | mitigated | Observation | |
| F-2025-9106 | Unused Constants in constants.fc | mitigated | Observation | |
| F-2025-9105 | Incorrect fwd_fee Calculation in jetton-minter Contract | mitigated | 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 | |
|---|---|
| Codebase | https://verifier.ton.org/EQATmFZKR2_7Cx4ZYs_mRj2EBd37kJNYv8u3PpVPZFvhbqIi→ |
| Whitepaper | Not provided |
| Requirements | Not provided |
| Technical Requirements | Not provided |
Scope Details
- Whitepaper
- Not provided
- Requirements
- Not provided
- Technical Requirements
- Not provided