On-chain security analysis — is it a scam or legit?
EthereumThe audited contract implements a standard ERC20 token with renounced ownership.
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 locked or burned.
0xb3ac…68a00x6bf1…da0c0x3b72…d61f0x0000…8a900x1f2f…f3870x17bb…7e37No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
SafeMath library. However, Solidity version 0.8.19, used in this contract, provides native overflow and underflow protection by default. The try* functions within the SafeMath library explicitly use unchecked blocks, which bypass these native checks, although they implement their own checks. The add, sub, mul, div, mod functions without try or errorMessage parameters do not use unchecked and thus rely on the native compiler checks, making the library largely redundant and potentially confusing for maintainers.L-01The contract includes a SafeMath library. However, Solidity version 0.8.19, used in this contract, provides native overflow and underflow protection by default. The try* functions within the SafeMath library explicitly use unchecked blocks, which bypass these native checks, although they implement their own checks. The add, sub, mul, div, mod functions without try or errorMessage parameters do not use unchecked and thus rely on the native compiler checks, making the library largely redundant and potentially confusing for maintainers.
Consider removing the SafeMath library entirely and relying on Solidity's built-in overflow/underflow protection for arithmetic operations. If specific unchecked blocks are desired for gas optimization, ensure they are carefully placed and preceded by robust require statements, as is done in some parts of the ERC20 contract itself.
Unresolved
approve() function is susceptible to a front-running attack. If a token holder first approves an amount for a spender, and then decides to change that approved amount, an attacker can front-run the second approve transaction. This allows the attacker to execute the original approve with the initial amount, then immediately use transferFrom to drain that amount, and finally allow the second approve transaction to proceed, granting the spender the new amount as well.I-01The standard approve() function is susceptible to a front-running attack. If a token holder first approves an amount for a spender, and then decides to change that approved amount, an attacker can front-run the second approve transaction. This allows the attacker to execute the original approve with the initial amount, then immediately use transferFrom to drain that amount, and finally allow the second approve transaction to proceed, granting the spender the new amount as well.
While increaseAllowance() and decreaseAllowance() functions are provided, which mitigate this issue, users should be educated to use these functions instead of directly calling approve() when modifying an existing allowance.
Unresolved
ownership_renounced: true). This means the _owner address in the Ownable contract is set to address(0). Consequently, any functions protected by the onlyOwner modifier are permanently inaccessible and cannot be executed by any external account.I-02The provided prefill data indicates that the contract's ownership has been renounced (ownership_renounced: true). This means the _owner address in the Ownable contract is set to address(0). Consequently, any functions protected by the onlyOwner modifier are permanently inaccessible and cannot be executed by any external account.
Confirm that renouncing ownership was an intentional and well-considered decision. Ensure that no critical administrative functions or emergency controls are required post-renunciation, as they cannot be recovered or executed. This design choice enhances decentralization but removes any central control.
Unresolved
The audited contract implements a standard ERC20 token with renounced ownership. The code is generally well-structured and adheres to common patterns. Minor code quality concerns exist regarding the redundant use of a SafeMath library in Solidity 0.8.19. Overall, the contract presents a low security risk.
The contract implements a standard ERC20 token, inheriting from Context, IERC20, and IERC20Metadata. It includes a SafeMath library, though its utility is diminished in Solidity 0.8.19 due to built-in overflow checks (7.2 Code Security). The _transfer and _burn functions correctly use unchecked blocks after validating conditions with require statements, ensuring arithmetic safety. Access control is handled by the Ownable pattern, which is noted as renounced (7.3 Access Control), enhancing decentralization.
The economic model is a standard ERC20 token, with no complex mechanisms or external dependencies that introduce inherent economic risk (7.4 Economic). Governance is based on the Ownable pattern, but the ownership has been renounced (7.5 Governance). This means no single entity controls administrative functions, which significantly reduces governance risk and enhances decentralization.
The contract is not designed with an upgradeability pattern (e.g., proxy). Therefore, it is immutable once deployed, eliminating upgrade-related risks such as proxy misconfigurations or logic contract vulnerabilities introduced during upgrades (7.7 Upgrades). Any changes to the contract's logic would require a new deployment.
It is recommended to review the necessity of the custom SafeMath library, as Solidity 0.8.19 provides native overflow/underflow protection, making it largely redundant.
Confirm that the renounced ownership state is an intentional and permanent design choice, as it removes any central administrative control. Educate users on the benefits of increaseAllowance and decreaseAllowance to mitigate known ERC20 allowance race conditions.
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.
The Andy contract on Ethereum is 0x68bbed6a47194eff1cf514b50ea91895597fc91e. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for Andy is 0/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
Liquidity lock: Locked (as of Sep 4, 2026). Total DEX liquidity: $1.33M.
As of Sep 4, 2026, the 10 largest holders own 22.1% of the supply. The Holders section on this page shows who they are by holder type.
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
