On-chain security analysis — is it a scam or legit?
EthereumThis report details the security audit of the Custom Token contract.
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 $108 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.
0x9210…7e7e0x8173…9596No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
balanceOf Addition (unchecked block)mint and _updateBalance functions use unchecked blocks for balanceOf[to] += value;. While totalSupply is capped by maxSupply, individual balanceOf values are not explicitly checked against type(uint256).max before addition within these unchecked blocks. If maxSupply is sufficiently large (e.g., close to type(uint256).max) and a large value is minted or transferred to an address already holding a large balance, the balanceOf[to] could wrap around, leading to an incorrect, lower balance for the recipient.H-01The mint and _updateBalance functions use unchecked blocks for balanceOf[to] += value;. While totalSupply is capped by maxSupply, individual balanceOf values are not explicitly checked against type(uint256).max before addition within these unchecked blocks. If maxSupply is sufficiently large (e.g., close to type(uint256).max) and a large value is minted or transferred to an address already holding a large balance, the balanceOf[to] could wrap around, leading to an incorrect, lower balance for the recipient.
Remove the unchecked block around balanceOf[to] += value; in both mint and _updateBalance functions. Solidity 0.8+ provides default overflow/underflow checks, which should be leveraged here to ensure balanceOf values do not wrap around.
Unresolved
totalSupplytotalSupply as a public state variable (uint256 public totalSupply;) instead of implementing it as a public view function (function totalSupply() external view returns (uint)), as required by the ERC-20 standard. This deviation can cause compatibility issues with wallets, exchanges, and other DeFi protocols that expect the totalSupply() function to exist.M-01The contract declares totalSupply as a public state variable (uint256 public totalSupply;) instead of implementing it as a public view function (function totalSupply() external view returns (uint)), as required by the ERC-20 standard. This deviation can cause compatibility issues with wallets, exchanges, and other DeFi protocols that expect the totalSupply() function to exist.
Change uint256 public totalSupply; to uint256 internal _totalSupply; and implement the totalSupply() function as `function totalSupply() external view override returns (uint) { return _totalSupply; }. Update all internal references to totalSupply to _totalSupply`.
Unresolved
owner and issuer roles. The owner can transfer ownership (via a two-step process) and change the issuer. The issuer has the sole ability to mint new tokens up to the maxSupply. This centralization introduces a single point of failure and trust, as a compromised owner or issuer account could lead to unauthorized minting or control transfer.M-02The contract design grants significant power to the owner and issuer roles. The owner can transfer ownership (via a two-step process) and change the issuer. The issuer has the sole ability to mint new tokens up to the maxSupply. This centralization introduces a single point of failure and trust, as a compromised owner or issuer account could lead to unauthorized minting or control transfer.
Acknowledge this centralization as part of the token's design. If decentralization is desired in the future, consider implementing a multi-signature wallet for the owner and issuer roles, or integrating a governance mechanism to manage these critical functions.
Unresolved
approve Function Front-Running Vulnerabilityapprove function, as implemented in the ERC-20 standard, is susceptible to a known front-running attack. If a user approves an amount X for a spender, and then decides to change the approved amount to Y (where Y < X), a malicious front-runner could observe the transaction to change the allowance, quickly execute the original allowance X, and then the user's transaction would set the allowance to Y, effectively allowing the front-runner to spend X + Y.L-01The approve function, as implemented in the ERC-20 standard, is susceptible to a known front-running attack. If a user approves an amount X for a spender, and then decides to change the approved amount to Y (where Y < X), a malicious front-runner could observe the transaction to change the allowance, quickly execute the original allowance X, and then the user's transaction would set the allowance to Y, effectively allowing the front-runner to spend X + Y.
Advise users to always set the allowance to zero before setting a new non-zero allowance, i.e., call approve(spender, 0) then approve(spender, newAmount). Alternatively, consider implementing an increaseAllowance and decreaseAllowance pattern to mitigate this user-side risk.
Unresolved
maxSupply). There is no mechanism to permanently remove tokens from circulation, which might be desired for certain economic models or to recover tokens sent to unrecoverable addresses.I-01The contract does not include a function to burn tokens, which means tokens can only be transferred or minted (up to maxSupply). There is no mechanism to permanently remove tokens from circulation, which might be desired for certain economic models or to recover tokens sent to unrecoverable addresses.
If a token burn mechanism is desired, consider adding a burn function that allows token holders to destroy their own tokens, or an ownerBurn function for administrative burning, ensuring appropriate access controls are in place.
Unresolved
This report details the security audit of the Custom Token contract. The audit identified a high-severity issue related to potential integer overflow in balance updates within unchecked blocks, two medium-severity issues concerning ERC-20 non-compliance and centralized control, and other minor findings. The contract implements a basic ERC-20-like token with minting capabilities up to a maximum supply.
The contract exhibits a clear structure and generally follows common Solidity patterns. Strengths include the use of immutable for critical parameters like decimals and maxSupply, and a two-step ownership transfer mechanism (7.3 Access Control). However, a significant concern is the use of unchecked blocks for balanceOf additions in mint and _updateBalance, which could lead to integer overflow and balance corruption (7.2 Code Security). Additionally, the totalSupply is implemented as a public state variable instead of a function, causing ERC-20 non-compliance (7.1 Architecture).
The token's economic model is straightforward, with a fixed maxSupply and a centralized issuer role responsible for minting (7.4 Economic). The owner role holds significant power, including the ability to change the issuer and transfer ownership (7.5 Governance). This centralization introduces a single point of failure, requiring strong operational security for the controlling addresses (7.8 Operations). The maxSupply is immutable, providing a predictable supply cap.
This contract is not designed to be upgradeable. Its logic is immutable once deployed, which eliminates upgrade-related risks such as proxy misconfigurations or malicious upgrade implementations (7.7 Upgrades). Any changes to the token's core logic would require a new deployment.
It is strongly recommended to address the high-severity integer overflow vulnerability by removing the unchecked blocks around balanceOf additions.
The ERC-20 non-compliance for totalSupply should also be corrected to ensure broad compatibility. For the centralized roles, implement robust operational security measures like multi-signature wallets. Thoroughly test all fixes in a staging environment before deployment.
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.
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
