Quantum Audit Logo

Is HEX Safe?

On-chain security analysis — is it a scam or legit?

Is this your token? Publish your own audit on this page →

HEX HEX
0x2b59…eb39
Ethereum Not verifiedLast checked 3d ago 1 audit on record
Executive SummaryAI Copilot

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.

3 Informational
Volume 24h
$86.5K
Liquidity
$497.6K
Price
$0.001166
Token Age
1y
Top 10 Holders
40.6%

Security Findings

Info

Older Solidity Compiler Version (0.5.13)

I-01The 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.
IssueThe 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.
FixConsider 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.
StatusUnresolved
Info

Missing Core Application Logic for Comprehensive Audit

I-02The 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).
IssueThe 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).
FixTo 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.
StatusUnresolved
Info

ERC20 `approve` Race Condition Warning

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`.
IssueThe `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`.
FixWhile 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)`.
StatusUnresolved

Category Ratings

TechnicalLow10/10

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.

GovernanceMedium4/10

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.

UpgradesMedium6/10

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.

Security Checklist

Contract VerifiedPass
Ownership Renounced?
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

20.2% in wallets20.3% in contracts
Effective Concentration28.4%

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.

Liquidity Depth

Show 4 more pairsShow less

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder57.0%
Top-3 Unlocked72.1%

Key Addresses

Deployer
0x896f…98cc
Unlocked LP Held By
0x0118…53f00xd7ce…e8fe0xbe06…b23a0xed0f…81140x4a90…656b0x6146…d70c0x1ffd…82910x4c8d…baf90xe2ff…9d6d0x373d…4462

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

What Raised This Score

  • Ownership status UNKNOWN (owner could not be resolved)
  • Top-10 concentration > 20% (40.6% total → 28.4% effective; 20.2% in EOAs, 20.3% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 57.0% (independent LP — depth risk, pool = 42% of DEX liquidity)

Each 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

Related Audits

Wrapped liquid staked Ether 2.0 (WSTETH)Low RiskManyuLow RiskRektLow RiskXEN Crypto (XEN)Low RiskEthereumcat (ETHCAT)Low RiskUnity Software (UNITY)Low Risk

Would You Like a More Detailed Audit of HEX?

Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.

Get Detailed Audit