- Hacken
- Audits
- agentlauncher
- [SCA] Agentlauncher.io | Token Audit | Jan2025
Audit name:
[SCA] Agentlauncher.io | Token Audit | Jan2025
Date:
Jan 30, 2025
Table of Content
Introduction
We express our gratitude to the Agentlauncher team for the collaborative engagement that enabled the execution of this Smart Contract Security Assessment.
Project Agentlauncher centers around the CVAI ecosystem, which employs LayerZero’s OFT (Omnichain Fungible Token) standard to enable cross-chain token functionality.
Document | |
|---|---|
| Name | Smart Contract Code Review and Security Analysis Report for Agentlauncher |
| Audited By | Ivan Bondar |
| Approved By | Grzegorz Trawinski |
| Website | Agentlauncher.io |
| Changelog | 21/01/2025 - Preliminary Report |
| 30/01/2025 - Final Report | |
| Platform | Arbitrum, Base, Ethereum, Polygon |
| Language | Solidity |
| Tags | Fungible Token |
| Methodology | https://hackenio.cc/sc_methodology→ |
Document
- Name
- Smart Contract Code Review and Security Analysis Report for Agentlauncher
- Audited By
- Ivan Bondar
- Approved By
- Grzegorz Trawinski
- Website
- Agentlauncher.io
- Changelog
- 21/01/2025 - Preliminary Report
- 30/01/2025 - Final Report
- Platform
- Arbitrum, Base, Ethereum, Polygon
- Language
- Solidity
- Tags
- Fungible Token
- Methodology
- https://hackenio.cc/sc_methodology→
Review Scope | |
|---|---|
| Repository | https://github.com/CVPAD/cvpad-token→ |
| Commit | efb3e90 & 7679732 |
| Retest | b5bcdff & fa501d8 |
Review Scope
- Repository
- https://github.com/CVPAD/cvpad-token→
- Commit
- efb3e90 & 7679732
- Retest
- b5bcdff & fa501d8
Audit Summary
The system users should acknowledge all the risks summed up in the risks section of the report
Documentation quality
Functional requirements are missed.
Technical description is not provided.
Code quality
The development environment is configured.
Solidity Style Guide violations.
Test coverage
Code coverage of the project is 27.5% for the CVPAD__cvpad-access repository, with no test cases for the CVPAD__cvpad-token repository.
Deployment and basic user interactions are covered with tests.
Negative cases coverage is missed.
Interactions by several users are not tested thoroughly.
System Overview
Project Agentlauncher centers around the CVAI ecosystem, which employs LayerZero’s OFT (Omnichain Fungible Token) → standard to enable cross-chain token functionality. The primary components are:
CVAIToken
Implements an omnichain-compatible ERC20 token (CVAI) using the OFT framework.
Mints an initial supply (1 billion tokens) on the designated main chain.
Allows cross-chain interoperability by setting “peers” on remote chains, facilitating token sending and receiving across different networks.
Ownership and “delegate” privileges can be transferred.
CVAIAccess
Acts as an access-management and staking-like contract for tokens.
Users can deposit (“addTokens”) token into the contract, tracking their deposit amount and start time.
Withdrawals (“removeTokens”) may incur time-based penalties, deducted from the returned amount, then aggregated as “totalPenalty.”
The penalty schedule is configurable, enabling a custom lockup period or “cooldown” mechanic.
Contract owner can manage penalty parameters and withdraw accumulated penalties.
Together, these contracts form a cross-chain token environment (via OFT) with optional deposit/withdraw logic that applies time-based penalties, suitable for access control, membership gating, or other staking and liquidity scenarios.
Privileged roles
CVAIToken
Owner
Can set the LayerZero delegate address (
setDelegate).Can transfer contract ownership to a new owner (
transferOwnership).Can initialize peer endpoints for cross-chain interactions (
initPeerOnEids).
CVAIAccess
Owner
Can adjust penalty tiers (
addPenalty,removePenalty,changePenalty).Can withdraw accumulated penalty funds (
withdrawPenalties).Can perform an emergency token withdrawal for non-integrated tokens (
emergencyWithdraw).
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.
Owner's Unrestricted State Modification: The absence of restrictions on state variable modifications by the owner leads to arbitrary changes, affecting contract integrity.
Absence of Time-lock Mechanisms for Critical Operations: Without time-locks on critical operations, there is no buffer to review or revert potentially harmful actions, increasing the risk of rapid exploitation and irreversible changes.
Single Points of Failure and Control: The project is fully or partially centralized, introducing single points of failure and control. This centralization can lead to vulnerabilities in decision-making and operational processes, making the system more susceptible to targeted attacks or manipulation.
Interaction Time Reset on Token Deposit: Depositing tokens resets the interactionTime for a user, causing all previous and new deposits to restart from the beginning of the penalty structure. This behavior can unintentionally penalize users more harshly, reducing withdrawal flexibility and creating an inconsistent user experience.
Findings
Code ― | Title | Status | Severity | |
|---|---|---|---|---|
| F-2025-8397 | Inconsistent Penalty Ordering and Zero-Percent Tiers Cause Unpredictable Fee Structures | fixed | Low | |
| F-2025-8388 | Unbounded Penalty Percentage Permits Penalties Exceeding 100% | fixed | Low | |
| F-2025-8399 | Public Getters Duplicate Existing Mappings and Variables | accepted | Observation | |
| F-2025-8398 | Off-by-one and empty user data in iterateUsers function leads to incomplete or partially uninitialized pagination | fixed | Observation | |
| F-2025-8395 | Public Functions Intended for External Use Should Be Marked as External | fixed | Observation | |
| F-2025-8390 | Missing Events in Sensitive Functions | fixed | Observation | |
| F-2025-8373 | Usage of 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/CVPAD/cvpad-token→ |
| Commit | efb3e90 & 7679732 |
| Retest | b5bcdff & fa501d8 |
| Whitepaper | N/A |
| Requirements | |
| Technical Requirements |
Scope Details
- Repository
- https://github.com/CVPAD/cvpad-token→
- Commit
- efb3e90 & 7679732
- Retest
- b5bcdff & fa501d8
- Whitepaper
- N/A
- Requirements
- Technical Requirements
Assets in Scope
Appendix 3. Additional Valuables
Verification of System Invariants
During the audit of Agentlauncher, 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 Foundry fuzzing suite was prepared for this task, and throughout the assessment, 7 invariants were tested over 50,000, runs. This thorough testing ensured that the system works correctly even with unexpected or unusual inputs.
Invariant | Test Result | Run Count |
|---|---|---|
| Adding zero tokens must revert with the appropriate error message. | Passed | 50K+ |
| Removing zero tokens must revert with the appropriate error message. | Passed | 50K+ |
| Attempting to remove more tokens than a user’s balance must revert with the appropriate error. | Passed | 50K+ |
Adding tokens updates user balance and contract totalSupply correctly across randomized inputs. | Passed | 50K+ |
| Removing tokens deducts balances correctly and calculates penalties accurately across randomized inputs. | Passed | 50K+ |
| Removing penalty tiers maintains the penalty array’s order and structure. | Passed | 50K+ |
The contract’s totalSupply must always equal the sum of all user balances. | Passed | 50K+ |
Invariant
- Adding zero tokens must revert with the appropriate error message.
Test Result
- Passed
Run Count
- 50K+
Invariant
- Removing zero tokens must revert with the appropriate error message.
Test Result
- Passed
Run Count
- 50K+
Invariant
- Attempting to remove more tokens than a user’s balance must revert with the appropriate error.
Test Result
- Passed
Run Count
- 50K+
Invariant
- Adding tokens updates user balance and contract
totalSupplycorrectly across randomized inputs. Test Result
- Passed
Run Count
- 50K+
Invariant
- Removing tokens deducts balances correctly and calculates penalties accurately across randomized inputs.
Test Result
- Passed
Run Count
- 50K+
Invariant
- Removing penalty tiers maintains the penalty array’s order and structure.
Test Result
- Passed
Run Count
- 50K+
Invariant
- The contract’s
totalSupplymust always equal the sum of all user balances. Test Result
- Passed
Run Count
- 50K+
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.