- Hacken
- Audits
- evolve-network
- [SCA] Evolve Network | EVOLVE | Jan2025
Audit name:
[SCA] Evolve Network | EVOLVE | Jan2025
Date:
Jan 27, 2025
Table of Content
Introduction
We express our gratitude to the Evolve Network team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Evolve Network is a decentralized compute platform designed to democratize AI agents creation, specifically using LLMs hosted on a global GPU grid. Enabling users worldwide to interact with and develop advanced LLM agents through peer-to-peer distributed inferencing (and finetuning) with memory (data hub) and 3rd party tools.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Evolve Network |
| Audited By | Kornel Światłowski |
| Approved By | Grzegorz Trawinski |
| Website | https://www.evolvenetwork.ai/→ |
| Changelog | 09/01/2025 - Preliminary Report |
| 27/01/2025 - Final Report | |
| 21/02/2025 - Update Final Report | |
| Platform | Ethereum |
| Language | Solidity |
| Tags | ERC-20, Fee-On-Transfer |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Evolve Network
- Audited By
- Kornel Światłowski
- Approved By
- Grzegorz Trawinski
- Changelog
- 09/01/2025 - Preliminary Report
- 27/01/2025 - Final Report
- 21/02/2025 - Update Final Report
- Platform
- Ethereum
- Language
- Solidity
- Tags
- ERC-20, Fee-On-Transfer
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/Evolve-Community/SmartContracts→ |
| Commit | 74717dd3b3375314dd7b433288ab74a793be6956 |
| Final Commit | efd464f9dfb03b286a887729b7a4ab45fbde8dee |
| Updated Final Commit | 0ece7123f3e2ac0d4dfd365c386e37e3b1257043 |
| Deployed at | https://etherscan.io/token/0x0f719591e2bcb6fcc3e68b16d2a88c89c6ae0d42#code→ |
Review Scope
- Commit
- 74717dd3b3375314dd7b433288ab74a793be6956
- Final Commit
- efd464f9dfb03b286a887729b7a4ab45fbde8dee
- Updated Final Commit
- 0ece7123f3e2ac0d4dfd365c386e37e3b1257043
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are present, but only at a high-level.
Technical description is not provided.
Code quality
Development environment is not configured.
Test coverage
Code coverage of the project is 0% (branch coverage).
No tests
System Overview
The EVOLVE contract is an ERC20 token implementation with an initial supply of 42 billion tokens. Whole supply is minted to a deployer. Additional minting is not allowed. It features a fee on transfer mechanism, primarily applied during sales to automated market maker pairs. Collected fee can be swapped for ETH with UniswapV2Router02 and sent to a designated tax wallet.
It has the following attributes:
Name: Evolve Network
Symbol: EVOLVE
Decimals: 18
Total supply: 42 * 1e9 * 1e18;
Privileged roles
The Evolve contract uses an Ownable2Step library from OpenZeppelin to restrict access to important functions.
The contract owner can:
Lower the sell fee.
Retrieve any ETH held in the contract.
Retrieve any ERC20 tokens accidentally sent to the contract.
Set an address as an automated market maker pair.
Excludes or includes an account from fee deductions.
Sets the token threshold at which the contract will swap tokens for ETH.
Updates the tax wallet.
Swaps a specified amount of the contract’s token balance for ETH.
Updates the slippage tolerance used in swaps
Potential 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.
Interactions with External DeFi Protocols: Dependence on external DeFi protocols inherits their risks and vulnerabilities. This might lead to direct financial losses if these protocols are exploited, indirectly affecting the audited project.
Default Fee: The initially audited contract had a sell fee of 30%, but after the audit, the deployed code was updated to 45% at launch. However, after contract deployment, the fee was lowered to 3% and can not be increased due to setter restrictions.
Potential Fee Omission: Swaps on UniswapV2 can be executed via UniswapV2Router02 or directly through UniswapV2Pair contracts. To ensure proper fee enforcement, the contract owner must designate both UniswapV2Router02 and all relevant UniswapV2Pair contracts involving the EVOLVE token as AMM addresses. Failure to mark all possible swap paths may result in missed fee collection.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8102 | Default Tax Wallet Address in EVOLVE Token May Lead to Burned Fees | fixed | Medium | |
| F-2025-8101 | Inefficient Swap Mechanism in EVOLVE Increases Transfers Gas Costs for Users | fixed | Medium | |
| F-2025-8095 | Exposure To Sandwich Attacks in swapBack() Due to Zero AmountOutMin | fixed | Medium | |
| F-2025-8103 | Missing Zero Address Check in setTaxWallet Function Could Lead to Fee Loss | fixed | Low | |
| F-2025-8098 | Missing Events For Key Data | fixed | Observation | |
| F-2025-8094 | Unsafe Use of transfer() with IERC20 | fixed | Observation | |
| F-2025-8093 | Missing Two-step Ownership Transfer Process | fixed | Observation | |
| F-2025-8092 | Use of transfer() to Send Native Assets May Revert | fixed | Observation | |
| F-2025-8089 | Floating Pragma | fixed | 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/Evolve-Community/SmartContracts→ |
| Commit | 74717dd3b3375314dd7b433288ab74a793be6956 |
| Final Commit | efd464f9dfb03b286a887729b7a4ab45fbde8dee |
| Updated Final Commit | 0ece7123f3e2ac0d4dfd365c386e37e3b1257043 |
| Deployed at | https://etherscan.io/token/0x0f719591e2bcb6fcc3e68b16d2a88c89c6ae0d42#code→ |
| Whitepaper | https://docs.evolvenetwork.ai/→ |
| Requirements | https://docs.evolvenetwork.ai/tokenomics/token-utility→ |
| Technical Requirements | - |
Scope Details
- Commit
- 74717dd3b3375314dd7b433288ab74a793be6956
- Final Commit
- efd464f9dfb03b286a887729b7a4ab45fbde8dee
- Updated Final Commit
- 0ece7123f3e2ac0d4dfd365c386e37e3b1257043
- Whitepaper
- https://docs.evolvenetwork.ai/→
- Technical Requirements
- -
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Evolve Network / EVOLVE, Hacken followed its methodology by performing fuzz-testing on the project's main functions. Foundry →, a tool used for fuzz-testing, was employed to check how the protocol behaves under various inputs. Due to the complex and dynamic interactions within the protocol, unexpected edge cases might arise. Therefore, it was important to use fuzz-testing to ensure that several system invariants hold true in all situations.
Fuzz-testing allows the input of many random data points into the system, helping to identify issues that regular testing might miss. A specific Echidna fuzzing suite was prepared for this task, and throughout the assessment, 6 invariants were tested over 1,000,000 runs each. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| Transfer() random amount to not AMM address | Passed | 1M |
| Transfer() random amount to AMM address with default fee | Passed | 1M |
| Transfer() to AMM address with default fee | Passed | 1M |
| TransferFrom() random amount to not AMM address | Passed | 1M |
| TransferFrom() random amount to AMM address with default fee | Passed | 1M |
| TransferFrom() to AMM address with default fee | Passed | 1M |
Invariant
- Transfer() random amount to not AMM address
Test Result
- Passed
Run Count
- 1M
Invariant
- Transfer() random amount to AMM address with default fee
Test Result
- Passed
Run Count
- 1M
Invariant
- Transfer() to AMM address with default fee
Test Result
- Passed
Run Count
- 1M
Invariant
- TransferFrom() random amount to not AMM address
Test Result
- Passed
Run Count
- 1M
Invariant
- TransferFrom() random amount to AMM address with default fee
Test Result
- Passed
Run Count
- 1M
Invariant
- TransferFrom() to AMM address with default fee
Test Result
- Passed
Run Count
- 1M
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 that 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.