Honeypot, rug-pull and ownership checks
EthereumThis audit covers a standard ERC20 token implementation based on OpenZeppelin Contracts v2.x.
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 8 remaining pairs hold $11.5K between them and are 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.
0xe151…1a310x805e…96650xc78b…70100xe70f…1d7b0x9f06…afed0x5bbc…d3b80x06e7…5c730x3c08…ccb70xdb6a…68940x93a0…2569No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
approve Race Condition Vulnerabilityapprove function is susceptible to a known front-running attack. If a user calls approve(spender, newAmount) while the spender is concurrently attempting to transferFrom an oldAmount, a malicious actor could front-run the newAmount transaction. This could allow the spender to spend both the oldAmount and the newAmount, effectively doubling their allowance for a brief period. While this is an inherent design flaw in the ERC20 standard, it can lead to unexpected token transfers.M-01The ERC20 standard's approve function is susceptible to a known front-running attack. If a user calls approve(spender, newAmount) while the spender is concurrently attempting to transferFrom an oldAmount, a malicious actor could front-run the newAmount transaction. This could allow the spender to spend both the oldAmount and the newAmount, effectively doubling their allowance for a brief period. While this is an inherent design flaw in the ERC20 standard, it can lead to unexpected token transfers.
Implement and encourage the use of increaseAllowance and decreaseAllowance functions, which are designed to safely modify allowances by adding or subtracting from the current value. These functions prevent the race condition by ensuring that allowance changes are atomic relative to the current allowance. The provided OpenZeppelin ERC20 contract description mentions these functions as mitigations, but they are not present in the provided snippet.
Unresolved
transfer, transferFrom, approve, balanceOf, and totalSupply. However, it does not include mechanisms for token minting, burning, or any specific business logic. Its full functionality and security profile will depend on how it is extended by a derived contract.I-01The provided contract code represents a base implementation of the ERC20 standard. It includes core functionalities like transfer, transferFrom, approve, balanceOf, and totalSupply. However, it does not include mechanisms for token minting, burning, or any specific business logic. Its full functionality and security profile will depend on how it is extended by a derived contract.
Ensure that any derived contracts that extend this base ERC20 implementation are thoroughly audited. Pay close attention to the implementation of minting, burning, or any custom logic, as these are common sources of vulnerabilities if not handled correctly.
Unresolved
pragma solidity ^0.5.0 and appears to be based on an older version of OpenZeppelin Contracts (likely v2.x). While these versions are generally robust, newer versions (e.g., v4.x, v5.x) offer updated patterns, gas optimizations, and potentially new features or security enhancements that have been developed since this version was released.I-02The contract uses pragma solidity ^0.5.0 and appears to be based on an older version of OpenZeppelin Contracts (likely v2.x). While these versions are generally robust, newer versions (e.g., v4.x, v5.x) offer updated patterns, gas optimizations, and potentially new features or security enhancements that have been developed since this version was released.
Consider migrating to a more recent version of OpenZeppelin Contracts if possible. This would allow the project to benefit from the latest security best practices, gas efficiencies, and features. A migration would require careful testing and potentially adjustments to the codebase.
Unresolved
increaseAllowance/decreaseAllowance FunctionsERC20 contract description within the OpenZeppelin code explicitly mentions decreaseAllowance and increaseAllowance as functions added to mitigate the well-known issues around setting allowances (the approve race condition). However, these functions are not present in the provided ERC20 contract snippet. This means users are exposed to the approve race condition without the standard OpenZeppelin-provided safe allowance modification methods.I-03The ERC20 contract description within the OpenZeppelin code explicitly mentions decreaseAllowance and increaseAllowance as functions added to mitigate the well-known issues around setting allowances (the approve race condition). However, these functions are not present in the provided ERC20 contract snippet. This means users are exposed to the approve race condition without the standard OpenZeppelin-provided safe allowance modification methods.
Implement the increaseAllowance and decreaseAllowance functions as provided in standard OpenZeppelin ERC20 implementations. This will provide users with safer methods to adjust allowances, reducing the risk associated with the approve function.
Unresolved
This audit covers a standard ERC20 token implementation based on OpenZeppelin Contracts v2.x. The provided source code includes the IERC20 interface, SafeMath library, and the base ERC20 contract. The contract leverages well-audited components, contributing to a generally robust foundation. However, the inherent ERC20 approve function vulnerability and the base nature of the implementation are noted.
The technical architecture (7.1) is a standard ERC20 token, utilizing battle-tested OpenZeppelin libraries like SafeMath, which effectively prevents common integer overflow/underflow vulnerabilities (7.2 Code Security). The implementation adheres to the ERC20 standard, ensuring broad compatibility. However, the approve function, a part of the ERC20 standard, is susceptible to a known front-running race condition (7.2 Code Security). The provided code is a base ERC20, meaning its full security relies on how it is extended by derived contracts.
The provided contract code is a base ERC20 token and does not include any specific governance mechanisms (7.5 Governance) or complex economic models (7.4 Economic). Therefore, there are no inherent governance or economic risks within this specific codebase. Any economic or governance considerations would arise from how this base token is integrated into a broader protocol.
The contract is a standard, non-upgradeable ERC20 implementation (7.7 Upgrades). It does not utilize any proxy patterns or other upgradeability mechanisms. Consequently, there are no upgrade-specific risks associated with this contract. Any future changes would require a new deployment and migration of assets.
It is recommended to implement the increaseAllowance and decreaseAllowance functions to provide safer alternatives for modifying allowances, mitigating the known ERC20 approve race condition.
For any derived contracts extending this base ERC20, ensure that all custom logic is thoroughly audited for reentrancy, access control, and other common vulnerabilities. Consider upgrading to a more recent version of OpenZeppelin Contracts for potential gas optimizations and updated security patterns.
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, Shiba Inu scores 75/100 (Critical Risk) on our risk scale. No honeypot was detected, but always verify independently before investing.
Our scanner flagged a risk score of 75/100. Ownership has not been renounced, which is a risk factor. DYOR before purchasing any token.
The contract is open-source and 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.
Paste the contract address into our AI-powered scanner for a deeper real-time report — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
