On-chain security analysis — is it a scam or legit?
The provided contract code implements a standard ERC-20 token using OpenZeppelin's well-audited libraries.
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 not locked or burned, so whoever holds them can withdraw that liquidity.
0xd2be…98800xfa03…fd7a0x73e3…93d50x3945…6e360x4a4c…34ebA privileged address — the deployer, the owner, or the token contract itself — is among these holders, so that party can withdraw liquidity.
pragma solidity directives (e.g., >=0.4.16, >=0.6.2, ^0.8.20, >=0.8.4). While the compiler will use the most restrictive one for the relevant code blocks, having multiple pragmas can sometimes lead to confusion or potential compatibility issues if not consistently managed across the codebase, especially with different compiler versions.L-01The source code contains multiple pragma solidity directives (e.g., >=0.4.16, >=0.6.2, ^0.8.20, >=0.8.4). While the compiler will use the most restrictive one for the relevant code blocks, having multiple pragmas can sometimes lead to confusion or potential compatibility issues if not consistently managed across the codebase, especially with different compiler versions.
Consolidate pragma solidity directives to a single, most restrictive version (e.g., pragma solidity ^0.8.20;) at the top of each file, or ensure consistent use if different versions are intentionally required for specific interfaces/libraries.
Unresolved
_mint and _burn (Contextual)_mint and _burn functions are internal to the ERC20 abstract contract. If a concrete token contract inherits from ERC20 and exposes these functions externally without proper access control (e.g., only callable by an owner, minter role, or specific governance mechanism), it could allow unauthorized manipulation of the token supply, leading to severe economic consequences.L-02The _mint and _burn functions are internal to the ERC20 abstract contract. If a concrete token contract inherits from ERC20 and exposes these functions externally without proper access control (e.g., only callable by an owner, minter role, or specific governance mechanism), it could allow unauthorized manipulation of the token supply, leading to severe economic consequences.
For any concrete token implementation, ensure that if _mint or _burn functionalities are exposed externally, they are protected by robust access control mechanisms (e.g., OpenZeppelin's Ownable or AccessControl contracts) to restrict their execution to authorized entities only.
Unresolved
ERC20 contract, which serves as a base for concrete token implementations. It is not directly deployable as a token. A concrete contract inheriting from ERC20 would be required for deployment and would define the initial supply and any custom logic.I-01The provided code defines an abstract ERC20 contract, which serves as a base for concrete token implementations. It is not directly deployable as a token. A concrete contract inheriting from ERC20 would be required for deployment and would define the initial supply and any custom logic.
This is an observation of the contract's structure. Ensure that the concrete token contract inheriting from this abstract base is fully reviewed for its specific implementation details, including constructor logic and any added functionalities.
Unresolved
ERC20 and ECDSA implementations appear to be standard, well-audited OpenZeppelin libraries. These libraries are widely used and have undergone extensive security reviews, significantly reducing the likelihood of undiscovered vulnerabilities within these core components.I-02The ERC20 and ECDSA implementations appear to be standard, well-audited OpenZeppelin libraries. These libraries are widely used and have undergone extensive security reviews, significantly reducing the likelihood of undiscovered vulnerabilities within these core components.
Continue to rely on well-established and audited libraries like OpenZeppelin. Ensure that any modifications or custom additions to these standard components are thoroughly tested and reviewed.
Unresolved
The provided contract code implements a standard ERC-20 token using OpenZeppelin's well-audited libraries. The code appears robust and follows modern Solidity best practices. Due to the truncated nature of the provided source, a full analysis of any custom logic or deployment-specific configurations could not be performed.
The technical architecture is based on OpenZeppelin's battle-tested ERC-20 standard, ensuring a robust foundation (7.1 Architecture). Code security is high, utilizing modern Solidity features like custom errors and unchecked blocks where appropriate, which enhances safety and gas efficiency (7.2 Code Security). The core ERC-20 logic is well-implemented, preventing common vulnerabilities like integer overflows/underflows in critical paths. However, the provided code is an abstract contract, and any custom logic in a concrete implementation would require further review.
As a standard ERC-20 token, the contract does not inherently include complex economic models or governance mechanisms (7.4 Economic, 7.5 Governance). The economic stability relies on external market factors and the project's overall design. Access control (7.3 Access Control) for core token functions is standard, relying on msg.sender for transfers and approvals. If _mint or _burn are exposed in a concrete implementation, their access control would be critical.
The provided contract is not designed with upgradeability patterns (7.7 Upgrades) such as proxies. This means the contract's logic is immutable once deployed. For a simple token, this is often an acceptable design choice, ensuring predictability and reducing the attack surface associated with upgrade mechanisms. Any future changes would require a new deployment and migration.
Ensure that any concrete implementation inheriting from this abstract ERC-20 contract properly implements access control for sensitive functions like _mint or _burn if they are exposed externally.
Thoroughly review any additional custom logic added to the token contract for potential vulnerabilities. Consider the implications of immutability for the project's long-term strategy, as any future feature additions or bug fixes would necessitate a new token 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
