On-chain security analysis — is it a scam or legit?
EthereumThis audit covers standard OpenZeppelin library contracts (Context, IERC20, SafeMath) from Solidity version 0.5.13. These foundational components are generally robust and widely used.
Read the full analysisEach factor is an on-chain fact recorded at the time of this analysis. The score is computed from them by a deterministic function, so the same contract returns the same score for anyone who runs the audit. How scores are computed
Share held by contracts — treasury, vesting, bridge or staking — is discounted against share held by wallets when the score is computed: a contract cannot decide to sell the way an anonymous holder can, though it can still be drained or voted to sell. Effective concentration is the figure the risk score is actually calculated from.
Holder balances as recorded by the audit of Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x0118…53f00xd7ce…e8fe0xbe06…b23a0xed0f…81140x4a90…656b0x6146…d70c0x1ffd…82910x4c8d…baf90xe2ff…9d6d0x373d…4462No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The contracts are compiled with Solidity version 0.5.13. While functional, this is an older compiler version. Newer versions (e.g., 0.8.x) include native overflow/underflow checks, improved optimizer, and new language features that enhance security and developer experience. Relying on older versions might miss out on these advancements and potentially expose the project to known compiler-related quirks or bugs that have since been patched.
Consider upgrading to a more recent Solidity compiler version (e.g., 0.8.x) for new development. If upgrading is not feasible for existing contracts, ensure thorough testing and awareness of any known issues specific to Solidity 0.5.13. For new contracts, leverage the native overflow checks in Solidity 0.8.0+ to simplify code and reduce reliance on SafeMath.
Unresolved
The audit scope was limited to foundational libraries (Context, IERC20, SafeMath). The main application contract, referred to as 'HEX' in the prefill data, was not provided for review. This limitation prevents a comprehensive security assessment of the entire protocol's business logic, access control mechanisms (7.3 Access Control), economic model (7.4 Economic), and interactions with external contracts (7.6 External).
To obtain a complete security posture, the core application contract(s) must be provided for a full audit. This would allow for a thorough analysis of potential vulnerabilities such as reentrancy, access control flaws, economic exploits, and integration risks specific to the protocol's unique design.
Unresolved
approve Race Condition WarningIERC20 interface documentation explicitly highlights a potential race condition when changing an allowance using the approve function. If a user calls approve(spender, newAmount) while a malicious spender is monitoring the transaction, the spender could front-run the transaction, spend the oldAmount, and then allow the newAmount to be set, effectively spending oldAmount + newAmount.I-03The IERC20 interface documentation explicitly highlights a potential race condition when changing an allowance using the approve function. If a user calls approve(spender, newAmount) while a malicious spender is monitoring the transaction, the spender could front-run the transaction, spend the oldAmount, and then allow the newAmount to be set, effectively spending oldAmount + newAmount.
While this is a known ERC20 design consideration and not a vulnerability in the interface itself, implementers or users of approve should be aware of this pitfall. To mitigate this, it is recommended to first reduce the spender's allowance to zero with approve(spender, 0) and then set the desired new value with a subsequent approve(spender, newAmount).
Unresolved
This audit covers standard OpenZeppelin library contracts (Context, IERC20, SafeMath) from Solidity version 0.5.13. These foundational components are generally robust and widely used. The core application logic, such as the 'HEX' contract, was not provided for review, limiting the scope to these dependencies. No critical or high-severity vulnerabilities were found within the provided code.
The provided code consists of well-established OpenZeppelin libraries (Context, IERC20, SafeMath) from Solidity 0.5.13. These contracts are designed for robustness, with SafeMath effectively preventing integer overflow/underflow vulnerabilities (7.2 Code Security). The architecture (7.1 Architecture) is modular and follows standard patterns. No direct technical vulnerabilities were identified within these specific components, demonstrating strong foundational security practices.
The provided contracts (Context, IERC20, SafeMath) do not contain any governance or economic logic (7.4 Economic, 7.5 Governance). Therefore, no specific economic or governance risks can be assessed from these components alone. Any such risks would reside within the application contract that utilizes these libraries, which was not part of this audit.
The provided contracts do not implement any upgrade mechanisms (7.7 Upgrades). They are standard libraries and interfaces, typically not designed for direct upgradeability. Upgrade safety would depend entirely on the main application contract's design and its interaction with these components, which was outside the scope of this review.
While the reviewed standard libraries are robust, a comprehensive security assessment requires evaluating the main application contract (e.g., 'HEX') that utilizes these components.
It is crucial to audit the business logic, access control, and economic model of the primary contract. Additionally, consider migrating to a newer Solidity version (e.g., 0.8.x) for enhanced security features and native overflow checks, or ensure all arithmetic operations in the main contract consistently use SafeMath or similar libraries.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
