Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is CLAWNCH Safe?

Base
Not verified This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →
Last checked Sep 4, 2026 · 1 audit on record
Chart
Low RiskHow is this score calculated?
How the score breaks downratings: 10 is safest
Technical9/10Governance6/10Upgrades9/10Checks passed6 of 7Findings1 High · 1 Medium · 1 Low · 2 Info5
SummaryAI Copilot

The ClankerToken contract is an ERC20 token implementation with additional features for cross-chain operations, admin-controlled metadata, and voting capabilities.

Read the full analysis
What raised the score
  • Top-10 concentration > 20%
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0%
  • LP top3 unlocked holders = 100.0%
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 20% (47.2% total → 23.1% effective; 7.0% in EOAs, 40.2% in contracts — mild)
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk, pool = 91% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 91% of DEX liquidity)
  • 1 High finding(s) from audit
  • 1 Medium finding(s) from audit
  • 1 Low finding(s) from audit

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

Security Checklist

as of audit · Sep 46 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
40.2%Contracts7.0%52.8%Everyone else
40.2%Contracts7.0%52.8%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
47.2%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking40.2%
  • Walletsanonymous holders, free to sell7.0%
  • Everyone elsethe rest of the supply52.8%
Effective concentrationwhat the score reads23.1%
How holder types affect the score

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

Liquidity

as of audit · Sep 4$172.4K across 9 pairs
Show 3 more pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$157.5KShare of depth91.3%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x63d2…34960xbd3b…b3760x5cda…cb970x1997…ac7f

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

Security Findings

1 High1 Medium1 Low2 Info
High

Centralized Control of Admin Role and Metadata

The _admin address has significant control over the contract, including the ability to transfer the admin role itself via updateAdmin and modify critical token metadata (updateImage, updateMetadata). A compromise of this single address would allow an attacker to seize control of these functions, potentially impacting the token's perceived legitimacy, branding, or even facilitating social engineering attacks. This represents a single point of failure for critical administrative functions (7.3 Access Control, 7.5 Governance).H-01

Issue

The _admin address has significant control over the contract, including the ability to transfer the admin role itself via updateAdmin and modify critical token metadata (updateImage, updateMetadata). A compromise of this single address would allow an attacker to seize control of these functions, potentially impacting the token's perceived legitimacy, branding, or even facilitating social engineering attacks. This represents a single point of failure for critical administrative functions (7.3 Access Control, 7.5 Governance).

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the _admin role to require multiple approvals for sensitive operations like updateAdmin and metadata changes. Alternatively, introduce a time-lock mechanism for updateAdmin to provide a window for community or team intervention in case of a compromised key.

Status

Unresolved

Medium

Reliance on External Superchain Token Bridge

The crosschainMint and crosschainBurn functions are exclusively callable by Predeploys.SUPERCHAIN_TOKEN_BRIDGE. The security and integrity of this external bridge are paramount, as any vulnerability or misconfiguration in the bridge could lead to unauthorized minting or burning of ClankerToken, directly impacting the token's supply, value, and overall economic stability (7.6 External, 7.4 Economic).M-01

Issue

The crosschainMint and crosschainBurn functions are exclusively callable by Predeploys.SUPERCHAIN_TOKEN_BRIDGE. The security and integrity of this external bridge are paramount, as any vulnerability or misconfiguration in the bridge could lead to unauthorized minting or burning of ClankerToken, directly impacting the token's supply, value, and overall economic stability (7.6 External, 7.4 Economic).

Fix

Ensure that the Predeploys.SUPERCHAIN_TOKEN_BRIDGE contract has undergone rigorous security audits and is maintained by a reputable team. Implement robust monitoring for crosschainMint and crosschainBurn events to detect any anomalous activity originating from the bridge. Consider a mechanism for emergency pausing of cross-chain operations if a bridge vulnerability is detected.

Status

Unresolved

Low

Single Point of Initial Supply Minting

The entire maxSupply_ is minted to msg.sender (the deployer) during construction if block.chainid matches initialSupplyChainId_. This design centralizes the initial token distribution entirely with the deployer. While common for new tokens, it could pose a risk if the deployer's address is compromised before distribution, or if the distribution strategy is not transparently communicated (7.4 Economic, 7.8 Operations).L-01

Issue

The entire maxSupply_ is minted to msg.sender (the deployer) during construction if block.chainid matches initialSupplyChainId_. This design centralizes the initial token distribution entirely with the deployer. While common for new tokens, it could pose a risk if the deployer's address is compromised before distribution, or if the distribution strategy is not transparently communicated (7.4 Economic, 7.8 Operations).

Fix

Ensure that the deployer's address is secured with best practices (e.g., hardware wallet, multi-sig). Clearly communicate the initial distribution strategy to the community to manage expectations and transparency. This is largely an operational concern for the project team.

Status

Unresolved

Info

Non-Upgradeable Contract Design

The ClankerToken contract is deployed as a standard implementation contract and does not utilize any proxy pattern. This means that its logic cannot be modified or upgraded after deployment, making it immutable. Any future bug fixes, security patches, or feature enhancements would require a new contract deployment and a migration of token holders (7.7 Upgrades).I-01

Issue

The ClankerToken contract is deployed as a standard implementation contract and does not utilize any proxy pattern. This means that its logic cannot be modified or upgraded after deployment, making it immutable. Any future bug fixes, security patches, or feature enhancements would require a new contract deployment and a migration of token holders (7.7 Upgrades).

Fix

Acknowledge the implications of a non-upgradeable design. While it provides immutability guarantees, it sacrifices flexibility. Ensure that the current contract logic is thoroughly tested and robust to minimize the need for future changes. If future upgradeability is desired, a proxy pattern should be considered for new deployments.

Status

Unresolved

Info

Unused ERC20Votes Functionality

The contract inherits ERC20Votes and correctly overrides the _update function, enabling voting power tracking based on token balances. However, no explicit governance mechanism or voting logic is implemented within this contract itself that utilizes this voting power. While this provides the foundation for future governance, its current inclusion without active use might be considered informational (7.1 Architecture).I-02

Issue

The contract inherits ERC20Votes and correctly overrides the _update function, enabling voting power tracking based on token balances. However, no explicit governance mechanism or voting logic is implemented within this contract itself that utilizes this voting power. While this provides the foundation for future governance, its current inclusion without active use might be considered informational (7.1 Architecture).

Fix

Clarify the project's intention for the ERC20Votes functionality. If a governance system is planned, ensure it integrates correctly with this token. If not, consider if the overhead of including ERC20Votes is justified, although it is a standard and well-audited OpenZeppelin extension.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4
Executive SummaryWhat the contract is and what the review found

The ClankerToken contract is an ERC20 token implementation with additional features for cross-chain operations, admin-controlled metadata, and voting capabilities. It leverages battle-tested OpenZeppelin libraries, contributing to its code security. However, the contract exhibits a high degree of centralization around its _admin role and relies heavily on an external Superchain Token Bridge for cross-chain minting/burning, introducing significant operational and economic risks. The contract is not upgradeable, which limits future flexibility.

Technical9/10Low risk

The contract leverages battle-tested OpenZeppelin libraries for its ERC20, ERC20Permit, ERC20Votes, and ERC20Burnable functionalities, ensuring a robust foundation (7.2 Code Security). The implementation of _update for ERC20Votes is correctly overridden, and supportsInterface adheres to IERC165 standards. However, the contract exhibits a high degree of centralization in its _admin role, which controls critical functions like updateAdmin and metadata modifications (7.3 Access Control).

Governance6/10Medium risk

The economic model involves an initial mint of the entire maxSupply_ to the deployer on a specific chain, centralizing initial distribution (7.4 Economic). The contract's cross-chain capabilities (crosschainMint, crosschainBurn) are entirely dependent on the Predeploys.SUPERCHAIN_TOKEN_BRIDGE, making its security a critical external factor (7.6 External). The _admin role holds significant power, including the ability to transfer the admin role and update token metadata, posing a centralization risk (7.5 Governance).

Upgrades9/10Low risk

The ClankerToken contract is deployed as a standard, non-proxy implementation, meaning its logic is immutable post-deployment (7.7 Upgrades). This design choice ensures immutability and predictability but precludes any future bug fixes or feature enhancements without a complete redeployment and token migration. This is an intentional design choice rather than a vulnerability.

Final RecommendationWhat to do about this score

Implement a multi-signature wallet or a time-locked governance mechanism for the _admin role to mitigate the risks associated with centralized control.

Conduct a thorough security audit of the Predeploys.SUPERCHAIN_TOKEN_BRIDGE contract, as its security directly impacts the integrity of the token's cross-chain supply. Consider the implications of the non-upgradeable design for long-term maintenance and future feature development.

Contract & Record

1 audit on record
TypeClankerToken
NetworkBase
Token age7mo
Contract0xa1f7…47be
Deployer0x5ec3…572d
Badge for your website
CLAWNCH security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 202623Low

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Frequently Asked Questions

What is the CLAWNCH contract address?

The CLAWNCH contract on Base is 0xa1f72459dfa10bad200ac160ecd78c6b77a747be. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.

Is CLAWNCH a scam?

Quantum Audit's risk score for CLAWNCH is 23/100 (Low risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Liquidity lock: Not locked; Upgradeability: Fixed code; Honeypot: None found; Buy / sell tax: 0% / 0%. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.

Is CLAWNCH liquidity locked?

Liquidity lock: Not locked (as of Sep 4, 2026). Total DEX liquidity: $172.4K.

Who holds CLAWNCH?

As of Sep 4, 2026, the 10 largest holders own 47.2% of the supply. The Holders section on this page shows who they are by holder type.

Related Audits

6 more on the recordAll audits
KittehCoinMEOW · Base23LowLimitless Official TokenLMTS · Base23LowAlphabet Inc.GOOGLC · Base22LowArcadiaAAA · Base24LowBTNBase22LowBankrCoinBNKR · Base25Low

Would You Like a More Detailed Audit of CLAWNCH?

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