Introduction
We express our gratitude to the Tiamonds team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Tiamonds is tokenized diamond marketplace.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Tiamonds |
| Audited By | Nataliia Balashova |
| Approved By | Ataberk Yavuzer |
| Website | https://tiamonds.com/→ |
| Changelog | 23/01/2025 - Preliminary Report |
| 27/01/2025 - Final Report | |
| Platform | EVM |
| Language | Solidity |
| Tags | ERC20, Swap |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Tiamonds
- Audited By
- Nataliia Balashova
- Approved By
- Ataberk Yavuzer
- Website
- https://tiamonds.com/→
- Changelog
- 23/01/2025 - Preliminary Report
- 27/01/2025 - Final Report
- Platform
- EVM
- Language
- Solidity
- Tags
- ERC20, Swap
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/tech-lcx/TOTO→ |
| Commit | b76c0958dd4948b5efaa903a2007295f7383b3eb |
Review Scope
- Repository
- https://github.com/tech-lcx/TOTO→
- Commit
- b76c0958dd4948b5efaa903a2007295f7383b3eb
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are fully present.
Technical description is provided.
Code quality
The development environment is configured.
The code is mostly Gas-efficient.
The code conforms with the Solidity Style Guide.
Test coverage
Code coverage of the project is 61.11% (branch coverage).
Deployment and basic user interactions are covered with tests.
Covers the core functionality but does not achieve full coverage, particularly in edge cases.
Error scenarios and failure conditions are not fully covered.
System Overview
Toto is a protocol with the following contracts:
TOTO — an ERC-20 token with minting, burning, and pausing functionality. It has a maximum supply cap of 1 billion tokens and enforces role-based access control for minting and burning. Only addresses with the MINTER_ROLE, BURNER_ROLE, or MINTER_AND_BURNER_ROLE can mint or burn tokens. Privileged roles are granted through the TOTOAdmin contract.
It has the following attributes:
Name: TOTO Token
Symbol: TOTO
Decimals: 9
Total supply: 1b tokens.
TOTOAdmin — a contract that manages administrative functions like pausing the contract and granting/revoking minting and burning permissions. The owner has the ability to grant the MINTER_ROLE, BURNER_ROLE, or MINTER_AND_BURNER_ROLE, to specific accounts. This contract also uses Ownable2Step to ensure secure ownership transfers.
Swapper — a contract that facilitates a one-to-one swap between TIA and TOTO tokens. It allows users to burn TIA tokens and mint equivalent TOTO tokens. The swapper contract requires the MINTER_ROLE to mint TOTO tokens and interact with the TIA and TOTO contracts to perform the swap.
Privileged Roles
Owner: The owner is the most privileged role, able to grant and revoke minting and burning permissions, and pause/unpause the contract.
MINTER_ROLE: Privileged role that allows minting of TOTO tokens.
BURNER_ROLE: Privileged role that allows burning of TOTO tokens.
MINTER_AND_BURNER_ROLE: Privileged role that allows minting and burning of TOTO tokens
Potential Risks
Allowing a single entity to control minting can lead to potential centralization risks, where the minting process is manipulated, leading to token inflation or loss of trust if misused.
Reimplementing the spendAllowance function introduces the risk of incorrect behavior or security flaws, potentially bypassing allowance checks and affecting the integrity of token transfers.
Copying and using OpenZeppelin contracts without understanding their nuances can introduce unintended vulnerabilities or version mismatches, potentially compromising the security of the contract.
The _spendAllowance function could be vulnerable to front-running attacks, where malicious actors exploit the time gap between allowance checks and updates, potentially gaining unauthorized access to token transfers.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8443 | Public Functions that Can be External | fixed | Observation | |
| F-2025-8442 | Floating Pragma | accepted | Observation | |
| F-2025-8441 | Missing SafeERC20 Usage for swap Function | fixed | Observation |
Identify vulnerabilities in your smart contracts.
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/tech-lcx/TOTO→ |
| Commit | b76c0958dd4948b5efaa903a2007295f7383b3eb |
| Whitepaper | https://app.tiamonds.com/static/media/Tiamonds_White_Paper_3.ad90f77ca7c347156b1a.pdf→ |
| Requirements | N/A |
| Technical Requirements | Documented within the code comments (NatSpecs) |
Scope Details
- Repository
- https://github.com/tech-lcx/TOTO→
- Commit
- b76c0958dd4948b5efaa903a2007295f7383b3eb
- Requirements
- N/A
- Technical Requirements
- Documented within the code comments (NatSpecs)
Assets in Scope
Appendix 3. Additional Valuables
Additional Recommendations
The smart contracts in the scope of this audit could benefit from the introduction of automatic emergency actions for critical activities, such as unauthorized operations like ownership changes or proxy upgrades, as well as unexpected fund manipulations, including large withdrawals or minting events. Adding such mechanisms would enable the protocol to react automatically to unusual activity, ensuring the contract remains secure and functions as intended.
To improve functionality, these emergency actions could be designed to trigger under specific conditions, such as:
Detecting changes to ownership or critical permissions.
Monitoring large or unexpected transactions and minting events.
Pausing operations when irregularities are identified.
These enhancements would provide an added layer of security, making the contract more robust and better equipped to handle unexpected situations while maintaining smooth operations.