On-chain security analysis — is it a scam or legit?
The ClankerToken contract is an ERC-20 token utilizing OpenZeppelin standards.
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 11 remaining pairs hold $198 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.
0x5ec4…3d860x5581…06b10x5e64…9f050x7d27…fd550x13d2…fe040x0527…fc4e0xd392…74700x715e…ec210x3d70…2f650xb7e7…1151No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
updateImage FunctionupdateImage function can only be called by the _deployer address. While this function only modifies a metadata string, a compromised _deployer key could lead to unauthorized changes to the token's associated image, potentially impacting branding or user trust.M-01The updateImage function can only be called by the _deployer address. While this function only modifies a metadata string, a compromised _deployer key could lead to unauthorized changes to the token's associated image, potentially impacting branding or user trust.
Consider if this function truly needs to be mutable post-deployment. If so, evaluate whether a more decentralized approach (e.g., governance vote, time-locked changes) or a multi-signature wallet for the _deployer address would be appropriate.
Unresolved
maxSupply_ of the token is minted to msg.sender (the deployer) in the constructor. This grants the deployer significant control over the initial token distribution, which could lead to concerns about centralization, potential for market manipulation, or a single point of failure for distribution.M-02The entire maxSupply_ of the token is minted to msg.sender (the deployer) in the constructor. This grants the deployer significant control over the initial token distribution, which could lead to concerns about centralization, potential for market manipulation, or a single point of failure for distribution.
For new token launches, consider distributing the initial supply through more decentralized or transparent mechanisms, such as a vesting contract, a liquidity pool, or a public sale, rather than holding the entire supply in a single address. Clearly communicate the distribution plan to the community.
Unresolved
crosschainMint and crosschainBurn functions rely on the Predeploys.SUPERCHAIN_TOKEN_BRIDGE address for authorization. The security and integrity of the token's supply across chains are entirely dependent on the robustness and security of this external bridge contract. Any vulnerability or compromise in the bridge could directly impact the ClankerToken.L-01The crosschainMint and crosschainBurn functions rely on the Predeploys.SUPERCHAIN_TOKEN_BRIDGE address for authorization. The security and integrity of the token's supply across chains are entirely dependent on the robustness and security of this external bridge contract. Any vulnerability or compromise in the bridge could directly impact the ClankerToken.
Ensure that the SUPERCHAIN_TOKEN_BRIDGE contract is thoroughly audited, regularly monitored, and maintained with the highest security standards. Implement robust incident response plans for potential bridge exploits.
Unresolved
_decimals State Variableprivate immutable _decimals state variable, but it is never initialized or used. The ERC20 base contract already handles the decimals() function, which defaults to 18. This redundant variable adds unnecessary complexity and could be misleading.I-01The contract declares a private immutable _decimals state variable, but it is never initialized or used. The ERC20 base contract already handles the decimals() function, which defaults to 18. This redundant variable adds unnecessary complexity and could be misleading.
Remove the private immutable _decimals declaration as it is not used and the ERC20 base contract correctly handles the decimals() function.
Unresolved
The ClankerToken contract is an ERC-20 token utilizing OpenZeppelin standards. It includes extensions for voting, burning, and cross-chain functionality via a Superchain Token Bridge. The contract exhibits good code quality but has centralized control points for certain administrative functions and relies on external bridge security.
The contract (7.1 Architecture, 7.2 Code Security) is well-structured, inheriting from battle-tested OpenZeppelin ERC20 standards, including ERC20Permit, ERC20Votes, and ERC20Burnable. This significantly reduces the risk of common vulnerabilities like reentrancy or integer overflows. Custom logic is minimal and correctly implemented, such as the _update override and supportsInterface function. A minor observation is the redundant _decimals state variable, which is declared but unused, as ERC20 defaults to 18 decimals.
The contract (7.3 Access Control, 7.4 Economic, 7.5 Governance) implements centralized access control for specific functions. The _deployer address has exclusive permission to call updateImage, which could be a single point of failure if the deployer key is compromised. Additionally, the initial maxSupply_ is minted entirely to the deployer's address, granting significant control over the token's initial distribution. Cross-chain minting and burning operations are restricted to Predeploys.SUPERCHAIN_TOKEN_BRIDGE, making the token's supply integrity dependent on the security of this external bridge (7.6 External).
The ClankerToken contract (7.7 Upgrades) is implemented as a standard, non-upgradeable ERC20 token. This design choice eliminates all risks associated with upgrade mechanisms, such as proxy implementation bugs or upgrade path vulnerabilities. Once deployed, the contract's logic is immutable, providing predictable and stable behavior.
It is recommended to implement robust security measures for the _deployer address, such as multi-signature wallets, to mitigate the risk associated with centralized control over the updateImage function.
For the initial token distribution, consider transparent and decentralized methods to reduce perceived centralization risks. Furthermore, ensure the SUPERCHAIN_TOKEN_BRIDGE is thoroughly audited and maintained, as its security directly impacts the integrity of the token's cross-chain supply. Regular security reviews and monitoring of the bridge are advised.
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
