On-chain security analysis — is it a scam or legit?
BNB ChainThis audit covers an ERC20 token contract deployed on the BSC network.
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
One more pair holds $4 and is not listed. 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.
0xd7ea…9c2e0xabe1…e0bf0x483c…71870xbee9…8e770x3cbc…57330xd379…60d80xd65d…769c0x3f2d…dd0c0xd329…9cec0xecee…ebc4No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Ownable ownership has been renounced, setting the owner address to address(0). This action permanently disables any functions protected by the onlyOwner modifier. If the contract included owner-specific functionalities such as minting, burning, pausing, setting fees, or other administrative controls, these are now irrevocably inaccessible. This can lead to a loss of operational control (7.8) and potentially impact the economic model (7.4) if supply management or emergency actions were intended.H-01The contract's Ownable ownership has been renounced, setting the owner address to address(0). This action permanently disables any functions protected by the onlyOwner modifier. If the contract included owner-specific functionalities such as minting, burning, pausing, setting fees, or other administrative controls, these are now irrevocably inaccessible. This can lead to a loss of operational control (7.8) and potentially impact the economic model (7.4) if supply management or emergency actions were intended.
Ensure that all necessary administrative functions are either not protected by onlyOwner or that the implications of their permanent disablement are fully understood and accepted. If future administrative actions are required, this contract will be unable to perform them. For future contracts, consider a multi-signature wallet or a time-locked ownership transfer if administrative control is desired but with safeguards.
Unresolved
ERC20 contract is truncated. This prevents a full and comprehensive review of any custom logic, additional functions, or modifications that might have been added beyond the standard OpenZeppelin ERC20 implementation. While the visible code appears standard, unseen sections could contain vulnerabilities (7.2) or unexpected behavior.I-01The provided source code for the ERC20 contract is truncated. This prevents a full and comprehensive review of any custom logic, additional functions, or modifications that might have been added beyond the standard OpenZeppelin ERC20 implementation. While the visible code appears standard, unseen sections could contain vulnerabilities (7.2) or unexpected behavior.
Provide the complete and untruncated source code for a comprehensive security audit. This ensures all aspects of the contract's functionality can be thoroughly examined for vulnerabilities.
Unresolved
approve function, as defined in the ERC20 standard and implemented here, is susceptible to a known front-running vulnerability. If a user increases an existing allowance, a malicious spender could front-run the transaction, spend the original allowance, and then spend the newly increased allowance before the owner's transaction confirms, effectively spending more than the intended total (7.2).I-02The approve function, as defined in the ERC20 standard and implemented here, is susceptible to a known front-running vulnerability. If a user increases an existing allowance, a malicious spender could front-run the transaction, spend the original allowance, and then spend the newly increased allowance before the owner's transaction confirms, effectively spending more than the intended total (7.2).
Users should be advised to first set the allowance to zero before increasing it, or to use increaseAllowance and decreaseAllowance functions if they are available in the full implementation (OpenZeppelin's ERC20 typically includes these). While this is a standard ERC20 behavior, it's important for users to be aware of the risk.
Unresolved
This audit covers an ERC20 token contract deployed on the BSC network. The contract utilizes standard OpenZeppelin implementations for ERC20 and Ownable. A significant finding is that the contract's ownership has been renounced, which permanently disables any owner-restricted functions. The provided source code was truncated, limiting the review of potential custom logic.
The contract is based on well-vetted OpenZeppelin ERC20 and Ownable libraries, which generally provide robust code security (7.2) and a sound architectural foundation (7.1). Solidity 0.8+ is used, benefiting from default overflow/underflow checks. However, the renounced ownership (7.3) means any owner-only functions, such as potential administrative controls or supply management, are permanently inaccessible, which is a significant technical limitation.
The economic model (7.4) is a standard ERC20 token. The governance (7.5) is effectively decentralized due to the renounced ownership, meaning no single entity can control the contract post-deployment. While this removes centralization risk, it also eliminates any possibility for administrative intervention, such as pausing transfers in an emergency or adjusting token parameters, which could be a significant economic and operational risk (7.8) if such capabilities were ever intended or become necessary.
The contract is not designed as an upgradeable proxy (7.7). This means its logic is immutable once deployed, eliminating upgrade-related risks like proxy misconfigurations or malicious upgrade paths. However, it also means that any bugs or desired feature changes cannot be implemented without a new deployment.
It is crucial to fully understand the implications of renounced ownership.
All functions protected by onlyOwner are permanently disabled, which means no administrative actions can be taken on the contract. Ensure that this state aligns with the project's long-term vision and that no future administrative control is anticipated. For any future deployments, ensure complete source code is provided for a comprehensive audit.
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, SIREN 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
