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 BoxaV4TokenV2 contract implements an ERC20 token with a fixed supply of 1,000,000,000 tokens minted once at launch, EIP-2612 permit support, and built-in bookkeeping for holder rewards that the BOXA hook pays in the pool's quote asset. A new instance is created for every launch on Elysium. This re-audit covers version 2 of the token 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 token has no owner and no admin role. The only privileged caller is the immutable BOXA hook, and the launcher received the supply once at creation. Their privileges and the limits that apply to everyone are:
- The hook can add holder rewards to the books when its pool releases the holders' share of trading fees.
- The hook can record a holder's claim when it pays that holder.
- The launcher received the entire supply once and placed it in the locked pool; it keeps no tokens afterwards.
- Holders can transfer, approve and sign permits freely, without fees or restrictions.
- Nobody can mint new tokens; the supply was created once and can never grow.
- Nobody can burn, freeze, blacklist or pause holders' tokens, and transfers carry no fee.
- The hook cannot move or take any holder's tokens, and it cannot share out rewards in a transaction in which an earning balance moved.
- The contract cannot be upgraded or reconfigured by anyone.
Security Features
The contract implements several positive security features:
- Fixed supply with no mint or burn functions and no owner keys.
- Standard ERC-20 and EIP-2612 behaviour; permits are bound to the chain and can only be used once.
- Reward bookkeeping that never moves rewards already earned when tokens are transferred, never credits the excluded pool, launcher, hook or dead addresses, and ignores tokens held only within a single transaction.
- A cap on the reward per share that keeps the reward math from overflowing or blocking transfers, events for every share-out and withdrawal, and checks against zero addresses at creation.
Auditor's Comments
The high-severity issue of the previous version is resolved. Rewards can no longer be shared out while borrowed or briefly held tokens are counted, because the hook only releases them outside of trades and the token itself refuses any share-out in a transaction in which an earning balance moved. We confirmed this with the original attacks and proved the new rule for all inputs. The reward per share is now capped, which removes the earlier risk of blocked large transfers, and the reward bookkeeping is visible through events and getters. Tokens held by contracts that cannot claim, such as other exchange pairs or bridge escrows, still keep a share of every distribution that is never paid out, and a holder that keeps its tokens across a release earns its share like any other holder. The flag behind the new protection would be safer in a dedicated storage slot, and the compiler version should be fixed before deployment. Tokens sent to the dead address by buybacks leave circulation, but the total supply figure stays at one billion.
Note - This Audit report consists of a security analysis of the BoxaV4TokenV2 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 launcher 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
high Issues | 1 findings
Resolved
#1 high Issue
Reward bookkeeping counts balances that exist only inside one transaction
distribute divides each reward by the earning supply at that instant, and every address outside a short fixed list starts earning the moment it receives tokens. The PoolManager does not earn, so the pool's reserves, still 87 to 100 percent of the tokens not yet burned in every live pool, do not count. A contract that borrows those reserves at no cost inside a Uniswap v4 unlock, however, becomes the dominant earner until it repays. Because the hook distributes inside swaps and from a public release function, such a contract collects almost the whole holder share, and the credit stays after repayment. On the live chain one transaction collected 99.7 percent of the pending holder rewards of every pool that had any.
low Issues | 2 findings
Acknowledged
#1 low Issue
Rewards accrue to holders that can never claim them
Only the PoolManager, the launcher, the hook, the dead address and the zero address are excluded from earning. Every other contract that holds tokens earns a full share of each distribution, but it can only receive that share if it is able to call claimRewards on the hook. Pairs on other exchanges, lending markets, bridge escrows such as the chain's mirror bridge, and the token contract itself usually cannot, so their share stays locked in the hook forever and the rewards of real holders are diluted.
Resolved
#2 low Issue
Unbounded reward per share can block very large transfers
The reward per share grows without an upper bound and is multiplied by balances and amounts on every transfer. The results are converted to int256 without a range check, and products above 2^256 revert. We tested the extreme case of 1e30 wei distributed while only one token earns. Ordinary transfers kept working, but a single transfer above about 34 percent of supply reverted, no account could hold more than about 17 percent, and the books stayed consistent where the conversion wraps. Reaching that state costs at least about 1.5e29 wei of the quote asset in fees nobody can recover. That is impossible with every quote allowed today, but becomes conceivable if the owner allowlists a quote asset with an extremely low unit value.
optimization Issues | 1 findings
Resolved
#1 optimization Issue
Reward tracking can return early when neither side earns
_track always multiplies the reward per share by the amount and converts the result, even for transfers where neither side earns, such as buyback burns from the PoolManager to the dead address and the launcher's transfers at launch.
informational Issues | 5 findings
Resolved
#1 informational Issue
Reward bookkeeping emits no events and hides its state
distribute and withdraw change reward state without emitting anything, and the reward per share and the per-account corrections are private. Holders and integrators can only reconstruct a token's reward history from the hook's events and cannot read the core values directly.
Acknowledged
#2 informational Issue
ERC-20 approve race condition
As with any standard ERC-20, changing a non-zero allowance directly to another non-zero value allows the spender to use both the old and the new allowance if it acts first. The inherited implementation offers no increase or decrease functions.
Resolved
#3 informational Issue
Constructor does not validate its addresses
The launcher, hook and PoolManager addresses passed to the constructor are not checked against the zero address. Today only the launcher deploys the token and always passes its own non-zero addresses, so this only matters if the contract is reused.
Pending
#4 informational Issue
Compiler with known bugs and unverified deployed code
Solidity 0.8.26 has known compiler bugs, but their conditions do not apply to this contract. The deployed tokens carry no source metadata hash and their source is not verified on the explorer, so holders cannot easily confirm the code. We reproduced the deployed bytecode exactly from the audited source.
Pending
#5 informational Issue
Deferral flag uses a raw transient storage slot
The flag that blocks share-outs after a balance move, which is now central to the protection of holder rewards, lives in transient storage slot 0 and is written in inline assembly. Solidity places transient state variables from slot 0 onwards, so a transient variable added in a later version of the token, or of an inherited contract, would share the slot and could set or clear the flag by accident. The current code is correct.