TrustNet Score
The TrustNet Score evaluates crypto projects based on audit results, security, KYC verification, and social media presence. This score offers a quick, transparent view of a project's credibility, helping users make informed decisions in the Web3 space.
Real-Time Threat Detection
Real-time threat detection, powered by Cyvers.io,
is currently not
activated
for this project.
This advanced feature provides continuous monitoring and instant alerts to safeguard your assets from potential security threats. Real-time detection enhances your project's security by proactively identifying and mitigating risks.
For more information, click here.
Security Assessments
Summary and Final Words
No crucial issues found
The contract does not contain issues of high or medium criticality. This means that no known vulnerabilities were found in the source code.
Contract owner cannot mint
It is not possible to mint new tokens.
Contract owner cannot blacklist addresses.
It is not possible to lock user funds by blacklisting addresses.
Contract owner cannot set high fees
The fees, if applicable, can be a maximum of 25% or lower. The contract can therefore not be locked. Please take a look in the comment section for more details.
Contract cannot be locked
Owner cannot lock any user funds.
Token cannot be burned
There is no burning within the contract without any allowances
Ownership is renounced
The contract does not include owner functions that allow post-deployment modifications.
Contract is not upgradeable
The contract does not use proxy patterns or other mechanisms to allow future upgrades. Its behavior is locked in its current state.
Scope of Work
This audit encompasses the evaluation of the files listed below, each verified with a SHA-1 Hash. The team referenced above has provided the necessary files for assessment.
The auditing process consists of the following systematic steps:
- Specification Review: Analyze the provided specifications, source code, and instructions to fully understand the smart contract's size, scope, and functionality.
- Manual Code Examination: Conduct a thorough line-by-line review of the source code to identify potential vulnerabilities and areas for improvement.
- Specification Alignment: Ensure that the code accurately implements the provided specifications and intended functionalities.
- Test Coverage Assessment: Evaluate the extent and effectiveness of test cases in covering the codebase, identifying any gaps in testing.
- Symbolic Execution: Analyze the smart contract to determine how various inputs affect execution paths, identifying potential edge cases and vulnerabilities.
- Best Practices Evaluation: Assess the smart contracts against established industry and academic best practices to enhance efficiency, maintainability, and security.
- Actionable Recommendations: Provide detailed, specific, and actionable steps to secure and optimize the smart contracts.
A file with a different Hash has been intentionally or otherwise modified after the security review. A different Hash may indicate a changed condition or potential vulnerability that was not within the scope of this review.
Final Words
The following provides a concise summary of the audit report, accompanied by insightful comments from the auditor. This overview captures the key findings and observations, offering valuable context and clarity.
Smart Contract Analysis Statement
Contract Analysis
The BoxaUniLauncherV2 contract implements a one-transaction launch factory for BOXA tokens on Elysium. It deploys a new token with a fixed supply, registers and opens its Uniswap v4 pool with the BOXA hook at the configured opening price, places the whole supply as liquidity that can never be removed, optionally makes the creator's first buy, and burns the rounding dust. This re-audit covers version 2 of the launcher at commit d1d5a98, which had not been deployed at the time of the review.
Ownership Privileges
The ownership of the contract has been left out entirely: the launcher has no owner, no admin and no withdrawal function. Anyone can launch a token and becomes the creator of that pool. The relevant privileges and limits are:
- Any address can launch a token and choose its name, symbol, quote asset, fee shares and an extra tax of up to 9% per side.
- The creator may make an optional first buy in the launch transaction, protected by a deadline and a minimum output.
- The hook owner, outside this contract, decides which ERC-20 quote assets are allowed, their opening prices and the treasury's share of the extra tax; the creator names the values it expects, and the launch reverts if they changed.
- The PoolManager is the only contract that can call back into the launcher, and only during a launch.
- Nobody can withdraw, move or remove the launch liquidity, including the launcher itself.
- The launcher keeps no funds; any HYPE, quote tokens or launch tokens that come in during a launch are forwarded within the same transaction.
- Nobody can change a token's supply, fees or terms after the launch.
- The contract cannot be upgraded or paused.
Security Features
The contract implements several positive security features:
- Launches are atomic: the pool is created, filled and optionally bought into in one transaction, so nobody can trade before the creator's first buy.
- A reentrancy lock, a deadline and a minimum output protect each launch, and a first buy is either filled completely or the launch reverts.
- Creators fix the treasury cut and the opening price they expect, so a settings change just before a launch cannot alter the permanent terms of their pool.
- Token addresses are tied to the creator, every token transfer goes through a safe-transfer library that refuses addresses without code, and there is no owner, no stored funds and no upgrade path.
Auditor's Comments
The low-severity issue of the previous version is resolved: a creator now names the treasury cut and the opening tick it expects, and the launch reverts if the hook owner changed either of them. Transfers now use a current safe-transfer library, and the code-quality points were addressed apart from one small documentation slip on two errors. A creator's first buy remains unlimited, and with anti-snipe removed there is no protection against large early buys, which investors should keep in mind. The compiler version should be fixed and the build settings published before deployment. Pools created by this launcher use the version 2 hook, whose earlier high and medium issues are resolved; one new low-severity point about sustained price manipulation of the buyback is described in the hook statement.
Note - This Audit report consists of a security analysis of the BoxaUniLauncherV2 smart contract. This analysis did not include economic analysis of the contract's tokenomics. Moreover, we only audited the main contract for the BOXA team; the hook and the launch token are covered by their own statements. Other contracts associated with the project, such as the Uniswap v4 PoolManager and the quote tokens, were not audited by our team. We recommend investors do their own research before investing.
Files and details
Findings and Audit result
low Issues | 1 findings
Resolved
#1 low Issue
Owner-controlled launch terms are not bounded by the creator's transaction
Two terms that stay fixed for a pool's whole life are read from the hook at execution time: the treasury's share of the extra tax and, for ERC-20 quotes, the opening price. The hook owner, a single externally owned account, can change both at any time without delay. The launch parameters carry a deadline and a minimum output, but no expected values for these terms. A change that lands just before a launch therefore alters the permanent fee split by up to 10 percent of the extra tax, or the price at which an ERC-20-quoted pool opens, without the creator being able to stop it.
optimization Issues | 1 findings
Resolved
#1 optimization Issue
Reentrancy lock can use transient storage
The launch lock is a storage variable that is written twice on every launch, although the chain supports cheaper transient storage.
informational Issues | 7 findings
Acknowledged
#1 informational Issue
The creator's first buy is unlimited and exempt from anti-snipe
The first buy made inside the launch transaction is not subject to the anti-snipe cap and is limited only by the size of the curve. A creator can therefore acquire a large share of the supply at the opening price, which investors may not expect when a pool advertises anti-snipe protection.
Resolved
#2 informational Issue
Exact delivery check for ERC-20 quotes only runs when there is a first buy
The check that refuses quote tokens which deliver less than was sent only runs when the launch includes a first buy. Launches without one accept any allowlisted quote without that check.
Resolved
#3 informational Issue
Unchecked token transfer results and a transfer library without a code check
The launcher ignores the boolean returned by the launch token's transfer, which is safe because that token always returns true or reverts. The deployed build also uses a version of solmate's SafeTransferLib that does not check whether the token address has code. That is mitigated because quote assets must have code when they are allowlisted, and because the launcher compares balances before and after the transfer.
Acknowledged
#4 informational Issue
Free-form name, symbol and metadata
Any name, symbol and metadata are accepted, so a launch can imitate an established asset. This is inherent to a permissionless launchpad, but users can be misled.
Resolved
#5 informational Issue
Misleading error, implicit zero locals, duplicated constants and event naming
A first buy larger than the curve reverts with the same InsufficientOutput error as the minimum output check. Two locals rely on their implicit zero value. The tick spacing, supply and dead address repeat values that must stay in sync with the hook and token. The Launched event field firstBuyHype also carries ERC-20 amounts.
Pending
#6 informational Issue
Compiler with known bugs and unverified deployed code
Solidity 0.8.26 has known compiler bugs whose conditions do not apply here. The deployed launcher carries no source metadata hash and is not verified on the explorer. It only reproduces with one specific solmate commit, which must be published for others to verify it. We reproduced it exactly.
Pending
#7 informational Issue
Misplaced error documentation and raw transient storage slot
The notice for Expired, The deadline has passed, sits above ZeroAddress, so ZeroAddress carries two notices and Expired none, which misleads readers of the code and of generated documentation. The launch lock also writes transient storage slot 0 directly, which a transient state variable added in a later version would share.