On-chain security analysis — is it a scam or legit?
EthereumThe StandardToken contract implements a basic ERC-20 token with Ownable access control and a constructor-based fee mechanism.
Each 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.
_mint function is called in the constructor to mint the entire totalSupply to the owner(). This means the contract owner holds 100% of the initial token supply, creating a highly centralized distribution. This centralization poses a significant risk as the owner has unilateral control over the token's liquidity and potential market manipulation, and a compromise of the owner's private key would jeopardize the entire token supply (7.4 Economic, 7.3 Access Control).H-01The _mint function is called in the constructor to mint the entire totalSupply to the owner(). This means the contract owner holds 100% of the initial token supply, creating a highly centralized distribution. This centralization poses a significant risk as the owner has unilateral control over the token's liquidity and potential market manipulation, and a compromise of the owner's private key would jeopardize the entire token supply (7.4 Economic, 7.3 Access Control).
Consider implementing a more decentralized initial distribution mechanism, such as a vesting schedule, a public sale, or distributing tokens to multiple addresses. If the current distribution is intentional, ensure robust security measures are in place for the owner's private key, such as a multi-signature wallet or hardware security module.
Unresolved
args.serviceFee to args.serviceFeeReceiver using a call statement. While require(success) ensures the transfer succeeds for deployment, a malicious or improperly configured serviceFeeReceiver contract could intentionally revert the call transaction. This would prevent the StandardToken contract from being deployed, leading to a denial-of-service for the token's creation (7.8 Operations).M-01The constructor attempts to transfer args.serviceFee to args.serviceFeeReceiver using a call statement. While require(success) ensures the transfer succeeds for deployment, a malicious or improperly configured serviceFeeReceiver contract could intentionally revert the call transaction. This would prevent the StandardToken contract from being deployed, leading to a denial-of-service for the token's creation (7.8 Operations).
Ensure that the serviceFeeReceiver address is a trusted and robust contract or an EOA. If it's a contract, verify its fallback/receive function logic to ensure it does not revert unexpectedly. Consider alternative fee collection mechanisms if this risk is unacceptable, or deploy with a known-good receiver address.
Unresolved
ITokenRegistry contract in its constructor by calling register(). The security and behavior of this external ITokenRegistry are critical to the successful deployment and perceived legitimacy of this token. A malicious or compromised TokenRegistry could potentially lead to unexpected behavior during registration or impact the token's standing within the ecosystem (7.6 External).M-02The contract interacts with an external ITokenRegistry contract in its constructor by calling register(). The security and behavior of this external ITokenRegistry are critical to the successful deployment and perceived legitimacy of this token. A malicious or compromised TokenRegistry could potentially lead to unexpected behavior during registration or impact the token's standing within the ecosystem (7.6 External).
Thoroughly audit and verify the ITokenRegistry contract's code and its operational security. Ensure that the args.tokenRegistry address provided during deployment points to a trusted and secure registry. Understand the implications of being registered (or failing to register) with this external contract.
Unresolved
SafeMath for arithmetic operations, despite being compiled with Solidity 0.8.4. Solidity versions 0.8.0 and higher include built-in overflow and underflow checks by default, rendering SafeMath redundant. While not a vulnerability, its continued use adds unnecessary bytecode size and slightly increased gas costs for arithmetic operations (7.2 Code Security).L-01The contract uses SafeMath for arithmetic operations, despite being compiled with Solidity 0.8.4. Solidity versions 0.8.0 and higher include built-in overflow and underflow checks by default, rendering SafeMath redundant. While not a vulnerability, its continued use adds unnecessary bytecode size and slightly increased gas costs for arithmetic operations (7.2 Code Security).
Remove the using SafeMath for uint256; statement and all explicit SafeMath calls (.add(), .sub()). Rely on Solidity's native overflow/underflow checks. This will optimize gas usage slightly without compromising security.
Unresolved
approve Race Conditionapprove function is susceptible to a known front-running attack. If a user approves an amount, and then attempts to change that approved amount, a malicious actor could front-run the second transaction, causing the spender to spend the original approved amount, and then also the new approved amount, effectively spending twice. While increaseAllowance and decreaseAllowance are provided as mitigations, the base approve function itself remains vulnerable (7.2 Code Security).I-01The standard ERC-20 approve function is susceptible to a known front-running attack. If a user approves an amount, and then attempts to change that approved amount, a malicious actor could front-run the second transaction, causing the spender to spend the original approved amount, and then also the new approved amount, effectively spending twice. While increaseAllowance and decreaseAllowance are provided as mitigations, the base approve function itself remains vulnerable (7.2 Code Security).
Educate users to primarily use increaseAllowance and decreaseAllowance instead of directly calling approve to modify existing allowances. If approve must be used to change an allowance, users should first set the allowance to zero before setting a new non-zero value.
Unresolved
The StandardToken contract implements a basic ERC-20 token with Ownable access control and a constructor-based fee mechanism. The audit identified a high centralization risk due to the owner receiving the entire initial token supply, along with medium risks related to external dependencies and constructor-based ETH transfers. Minor informational findings were also noted.
The contract leverages OpenZeppelin's Ownable and SafeMath libraries, enhancing code security (7.2 Code Security). The implementation of ERC-20 functions is standard, including increaseAllowance and decreaseAllowance to mitigate approve race conditions. However, the constructor's ETH transfer mechanism introduces a potential denial-of-service risk during deployment if the serviceFeeReceiver reverts (7.8 Operations). Additionally, the reliance on an external ITokenRegistry introduces a dependency risk (7.6 External).
The economic model grants the contract owner significant control, as the entire totalSupply is minted to the owner's address during deployment (7.4 Economic). This centralization presents a high risk if the owner's key is compromised, potentially leading to market manipulation or loss of funds. While Ownable provides basic access control (7.3 Access Control), there are no further governance mechanisms defined within this contract (7.5 Governance) to mitigate this centralized power.
The StandardToken contract is not designed to be upgradeable, which simplifies its architecture and removes upgrade-related risks (7.7 Upgrades). The presence of a VERSION constant suggests potential future iterations or a versioning strategy, but this specific contract is immutable once deployed, ensuring its logic cannot be altered post-deployment.
It is recommended to carefully consider the implications of the owner holding the entire initial token supply and implement strategies to decentralize control or secure the owner's private key.
Thoroughly vet the tokenRegistry and serviceFeeReceiver contracts before deployment to mitigate external dependency risks. While SafeMath is redundant in Solidity 0.8.x, its removal is a minor optimization; focus should be on the higher-severity findings.
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
