On-chain security analysis — is it a scam or legit?
The provided source code consists entirely of standard OpenZeppelin interfaces for ERC-20, ERC-721, and ERC-1155 token errors, as well as the core IERC20 interface.
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.
0xc606…36e60x8e38…e3420xf0a0…3e100x729d…9f35No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The provided contract code is limited to interface definitions and does not contain any custom business logic, state-modifying functions, or complex interactions. Consequently, common vulnerabilities related to contract implementation (e.g., reentrancy, access control, integer overflows, economic exploits) are not present in this specific codebase (7.2 Code Security, 7.3 Access Control).
This finding highlights a characteristic rather than a flaw in the interfaces themselves. Any contract that implements these interfaces must be rigorously audited for vulnerabilities in its own custom logic.
Unresolved
The provided Solidity source code defines standard interfaces (IERC20Errors, IERC721Errors, IERC1155Errors, IERC20) without any concrete contract implementations, state variables, or executable logic. This means there are no direct functional vulnerabilities such as reentrancy, access control flaws, or arithmetic issues within this specific codebase.
No direct recommendation for this code. Developers should ensure that any contracts implementing these interfaces are thoroughly audited for security vulnerabilities in their custom logic.
Unresolved
pragma solidity ^0.8.13 ^0.8.20; is syntactically incorrect. A single pragma statement should specify a single version range, e.g., pragma solidity ^0.8.20; or pragma solidity >=0.8.13 <0.9.0;.I-02The pragma statement pragma solidity ^0.8.13 ^0.8.20; is syntactically incorrect. A single pragma statement should specify a single version range, e.g., pragma solidity ^0.8.20; or pragma solidity >=0.8.13 <0.9.0;.
Correct the pragma statement to specify a valid Solidity version range, for example, pragma solidity ^0.8.20; to ensure consistent compilation behavior.
Unresolved
The provided source code consists entirely of standard OpenZeppelin interfaces for ERC-20, ERC-721, and ERC-1155 token errors, as well as the core IERC20 interface. As these are interface definitions without any executable logic or state, they inherently contain no direct vulnerabilities such as reentrancy, access control flaws, or economic exploits. The primary concern identified is a malformed Solidity pragma statement.
The codebase (7.1 Architecture, 7.2 Code Security) consists solely of well-established OpenZeppelin interfaces, which are robust and widely adopted. There is no custom implementation logic, state variables, or external calls that could introduce technical vulnerabilities like reentrancy or integer overflows. The code adheres to high standards of clarity and best practices for interface definitions, though a minor issue with the Solidity pragma was noted.
As the provided code comprises only interface definitions, there are no inherent governance mechanisms (7.5 Governance) or economic models (7.4 Economic) to assess. The interfaces themselves do not manage funds, control parameters, or interact with external protocols (7.6 External) in a way that could introduce economic or governance risks.
The provided code consists of interfaces, which are not deployable or upgradeable contracts themselves (7.7 Upgrades). Therefore, there are no upgradeability risks or operational considerations (7.8 Operations) associated with this specific codebase. Any contract implementing these interfaces would need its own upgradeability strategy.
Given that the provided code is solely interface definitions, the primary recommendation is to ensure that any contracts implementing these interfaces correctly adhere to their specifications.
Developers should meticulously audit the implementation logic of any contract that utilizes these interfaces, focusing on areas such as access control, external interactions, and economic models. Pay close attention to the correct usage of custom errors defined in ERC-6093 to enhance user experience and debugging.
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
