On-chain security analysis — is it a scam or legit?
EthereumThe provided source code implements a standard OpenZeppelin ERC20 token.
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.
0x375f…9491No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
approve Race Conditionapprove function is susceptible to a known race condition. If a user approves an allowance for a spender, and then attempts to change that allowance to a different value, a malicious spender could potentially exploit the time window between the two transactions to spend both the old and new allowances. This is a design limitation of the ERC20 standard, not an implementation flaw in OpenZeppelin's code, which even includes a warning about it.I-01The ERC20 approve function is susceptible to a known race condition. If a user approves an allowance for a spender, and then attempts to change that allowance to a different value, a malicious spender could potentially exploit the time window between the two transactions to spend both the old and new allowances. This is a design limitation of the ERC20 standard, not an implementation flaw in OpenZeppelin's code, which even includes a warning about it.
Users should be advised to use increaseAllowance and decreaseAllowance functions (if available in a derived contract) instead of directly calling approve to modify an existing allowance. If only approve is available, users should first set the allowance to zero and wait for that transaction to confirm before setting the new desired allowance.
Unresolved
ERC20 contract is a base implementation from OpenZeppelin. It includes state variables for _totalSupply and _balances but lacks any _mint function or other mechanism to increase _totalSupply or assign initial balances. As a result, totalSupply() will always return 0, and balanceOf() will always return 0 for all accounts, rendering the token unusable as a standalone asset. A derived contract is expected to implement the token creation logic.I-02The provided ERC20 contract is a base implementation from OpenZeppelin. It includes state variables for _totalSupply and _balances but lacks any _mint function or other mechanism to increase _totalSupply or assign initial balances. As a result, totalSupply() will always return 0, and balanceOf() will always return 0 for all accounts, rendering the token unusable as a standalone asset. A derived contract is expected to implement the token creation logic.
Ensure that a derived contract implements a proper minting mechanism (e.g., using _mint from OpenZeppelin's ERC20 or a custom minting function) to set the initial supply and distribute tokens, making the token functional.
Unresolved
decimals() function is hardcoded to return 18. While 18 decimals is a common standard for ERC20 tokens, imitating Ether, this value cannot be changed after deployment. If a different decimal precision is ever required, the contract would need to be redeployed.I-03The decimals() function is hardcoded to return 18. While 18 decimals is a common standard for ERC20 tokens, imitating Ether, this value cannot be changed after deployment. If a different decimal precision is ever required, the contract would need to be redeployed.
If flexibility in decimal precision is desired, consider making the decimals value configurable during contract construction, though this is rarely necessary for standard tokens. For most use cases, hardcoding to 18 is acceptable.
Unresolved
The provided source code implements a standard OpenZeppelin ERC20 token. It benefits from battle-tested code and adherence to established standards, resulting in a low technical risk profile. However, as a base ERC20, it lacks a minting mechanism, which means a derived contract must implement token creation for it to be fully functional.
The contract utilizes the well-audited OpenZeppelin ERC20 implementation, providing a strong foundation for code security (7.2) and architecture (7.1). It adheres strictly to the ERC20 standard, ensuring broad compatibility and minimizing custom logic. The absence of complex features reduces the attack surface. A key observation is the lack of an explicit minting mechanism in this base contract, which means it requires a derived contract to become a functional token (I-02).
As a basic ERC20 token, the contract has no inherent governance (7.5) or complex economic (7.4) mechanisms. There are no custom fees, special roles, or rebase functionalities. The primary economic consideration for users is the well-known ERC20 approve race condition (I-01), which is a standard limitation of the ERC20 specification rather than an implementation flaw.
The contract is not designed to be upgradeable (7.7), as it does not implement any proxy patterns. This means its logic is immutable once deployed, providing certainty but requiring a new deployment for any future modifications. This design choice eliminates upgrade-related risks such as proxy initialization flaws or storage collisions.
It is recommended that the deployer ensures a derived contract properly implements a minting mechanism to make the token functional, as the current base ERC20 contract has a zero total supply.
Users should be aware of the standard ERC20 approve race condition and consider using increaseAllowance and decreaseAllowance functions where possible to mitigate this risk. Maintain vigilance over external dependencies and ensure proper operational security (7.8) for any privileged roles.
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.
Based on automated analysis, VANRY scores 63/100 (High Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.
Our scanner flagged a risk score of 63/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.
The contract has not been verified on-chain. Verification is not the same as a full security audit. Use Quantum Audit's free tool to run a deeper analysis of the contract code.
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
