Quantum Audit Logo
Launch App

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

Is KellyClaude Safe?

KELLYCLAUDEBase
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/10Governance5/10Upgrades9/10Checks passed4 of 5Findings1 High · 2 Medium · 1 Low · 1 Info5
SummaryAI Copilot

The ClankerToken contract is an ERC-20 token with extensions for burning, permits, and voting, designed for cross-chain functionality via a Superchain Token Bridge.

Read the full analysis
What raised the score
  • Top-10 concentration > 30%
  • 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
  • 2 Medium finding(s) from audit
  • 1 Low finding(s) from audit
Exact factors
  • Top-10 concentration > 30% (61.8% total → 42.0% effective; 28.8% in EOAs, 33.0% in contracts — moderate)
  • 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 = 99% of DEX liquidity)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk, pool = 99% of DEX liquidity)
  • 1 High finding(s) from audit
  • 2 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 44 of 5 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockNot locked
UpgradeabilityFixed code

Holders

as of audit · Sep 4, 2026
33.0%Contracts28.8%Wallets38.2%Everyone else
33.0%Contracts28.8%Wallets38.2%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
61.8%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking33.0%
  • Walletsanonymous holders, free to sell28.8%
  • Everyone elsethe rest of the supply38.2%
Effective concentrationwhat the score reads42.0%
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$244.9K across 10 pairs
Show 4 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$241.4KShare of depth98.6%
Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%
Unlocked LP held by
0x63d2…34960xb525…ae5e

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

Security Findings

1 High2 Medium1 Low1 Info
High

Centralized Control of Admin Role

The _admin address has extensive control over critical contract functions, including the ability to update the token's _image, _metadata, and, most significantly, to transfer the _admin role to any other address via updateAdmin(). This centralized control (7.3) creates a single point of failure; if the _admin key is compromised, an attacker could seize control of these parameters, potentially impacting the token's branding, perceived value, and future operational integrity (7.8).H-01

Issue

The _admin address has extensive control over critical contract functions, including the ability to update the token's _image, _metadata, and, most significantly, to transfer the _admin role to any other address via updateAdmin(). This centralized control (7.3) creates a single point of failure; if the _admin key is compromised, an attacker could seize control of these parameters, potentially impacting the token's branding, perceived value, and future operational integrity (7.8).

Fix

Consider implementing a multi-signature wallet for the _admin role to require multiple approvals for sensitive operations like updateAdmin(), updateImage(), and updateMetadata(). Alternatively, introduce a timelock mechanism for admin role transfers to provide a window for community or team intervention in case of a compromised key.

Status

Unresolved

Medium

Dependency on External Superchain Token Bridge

The crosschainMint and crosschainBurn functions, which directly affect the token's total supply, are exclusively callable by Predeploys.SUPERCHAIN_TOKEN_BRIDGE. This design (7.6) makes the token's supply management entirely dependent on the security and correct functioning of this external bridge. Any vulnerability or compromise within the Superchain Token Bridge could lead to unauthorized minting or burning of ClankerTokens, directly impacting the token's economic stability (7.4).M-01

Issue

The crosschainMint and crosschainBurn functions, which directly affect the token's total supply, are exclusively callable by Predeploys.SUPERCHAIN_TOKEN_BRIDGE. This design (7.6) makes the token's supply management entirely dependent on the security and correct functioning of this external bridge. Any vulnerability or compromise within the Superchain Token Bridge could lead to unauthorized minting or burning of ClankerTokens, directly impacting the token's economic stability (7.4).

Fix

Ensure a thorough understanding and ongoing monitoring of the security posture of the Predeploys.SUPERCHAIN_TOKEN_BRIDGE. While direct control over the bridge's security may be limited, awareness of its audit status, operational procedures, and any reported vulnerabilities is crucial for assessing the overall risk to ClankerToken.

Status

Unresolved

Medium

Admin Control Over Token Metadata and Image

The _admin address has the authority to unilaterally change the token's _metadata and _image strings via updateMetadata() and updateImage() functions. While these are typically off-chain representations, malicious or accidental changes to these publicly visible attributes could negatively impact user perception, trust, and the token's branding (7.4). This centralized control (7.3) over mutable data could be exploited to misrepresent the token.M-02

Issue

The _admin address has the authority to unilaterally change the token's _metadata and _image strings via updateMetadata() and updateImage() functions. While these are typically off-chain representations, malicious or accidental changes to these publicly visible attributes could negatively impact user perception, trust, and the token's branding (7.4). This centralized control (7.3) over mutable data could be exploited to misrepresent the token.

Fix

Consider whether these metadata fields truly require mutable control by a single admin. If mutability is necessary, implement a timelock for changes or a multi-signature approval process to add a layer of security and transparency before updates are finalized. Clearly communicate the implications of these mutable fields to token holders.

Status

Unresolved

Low

Conditional Initial Supply Minting Logic

The constructor's initial minting of maxSupply_ to msg.sender is conditional on block.chainid == initialSupplyChainId_. If the contract is deployed on a chain where this condition is false, the msg.sender (deployer) will receive zero tokens, potentially leading to an unexpected empty initial supply for the deployer (7.8). While this might be an intentional design for multi-chain deployment strategies, it introduces a subtle point of failure if the initialSupplyChainId_ is misconfigured or misunderstood during deployment (7.1).L-01

Issue

The constructor's initial minting of maxSupply_ to msg.sender is conditional on block.chainid == initialSupplyChainId_. If the contract is deployed on a chain where this condition is false, the msg.sender (deployer) will receive zero tokens, potentially leading to an unexpected empty initial supply for the deployer (7.8). While this might be an intentional design for multi-chain deployment strategies, it introduces a subtle point of failure if the initialSupplyChainId_ is misconfigured or misunderstood during deployment (7.1).

Fix

Ensure that the initialSupplyChainId_ parameter is carefully chosen and verified during deployment to match the intended chain for initial supply distribution. Document this behavior clearly to prevent deployment errors or misunderstandings regarding the initial token allocation.

Status

Unresolved

Info

Lack of Upgradeability

The ClankerToken contract is deployed as a standard, non-upgradeable contract. This means there is no built-in mechanism (e.g., proxy pattern) to modify the contract's logic after deployment (7.7). While this simplifies the contract's architecture and removes upgrade-related risks, it also implies that any future bug fixes, feature enhancements, or changes to the token's core functionality would require a complete redeployment of the contract and a potentially complex migration of existing token holders and associated liquidity.I-01

Issue

The ClankerToken contract is deployed as a standard, non-upgradeable contract. This means there is no built-in mechanism (e.g., proxy pattern) to modify the contract's logic after deployment (7.7). While this simplifies the contract's architecture and removes upgrade-related risks, it also implies that any future bug fixes, feature enhancements, or changes to the token's core functionality would require a complete redeployment of the contract and a potentially complex migration of existing token holders and associated liquidity.

Fix

Acknowledge the implications of non-upgradeability. For a token contract, this is often a desired security feature, as it guarantees immutability of core logic. If future flexibility is ever considered critical, a new contract would need to be deployed. Ensure all current functionality is thoroughly tested and deemed final.

Status

Unresolved

Analysis

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

The ClankerToken contract is an ERC-20 token with extensions for burning, permits, and voting, designed for cross-chain functionality via a Superchain Token Bridge. The contract exhibits a robust foundation using OpenZeppelin standards. Key risks include the centralized control held by the _admin address over critical token parameters and the inherent dependency on the security of the external Superchain Token Bridge for supply management. The contract is not upgradeable, which simplifies its security profile but limits future flexibility.

Technical9/10Low risk

The contract is built upon well-audited OpenZeppelin ERC-20 standards, including extensions for burning, permits, and voting, which enhances its code security (7.2). The architecture (7.1) clearly defines roles for _admin and _originalAdmin and integrates cross-chain mint/burn functionality. However, the _admin role has significant control over mutable token metadata and can transfer the admin role, presenting a centralized point of failure if compromised (7.3). No reentrancy or integer overflow vulnerabilities were identified.

Governance5/10Medium risk

The economic model (7.4) relies on a fixed maxSupply_ for initial minting, contingent on the deployment chain ID, and allows for dynamic supply adjustments via crosschainMint/crosschainBurn by the Superchain Token Bridge. Governance (7.5) is highly centralized, with the _admin address controlling key operational parameters like metadata, image, and the ability to transfer the admin role. This centralization, while simplifying operations (7.8), introduces a single point of failure. The contract's external dependency (7.6) on the Superchain Token Bridge for cross-chain operations means its economic integrity is tied to the bridge's security.

Upgrades9/10Low risk

The ClankerToken contract is implemented as a standard, non-upgradeable contract (7.7). This design choice eliminates the complexities and potential risks associated with upgrade mechanisms (e.g., proxy patterns), such as storage collisions or faulty upgrade logic. However, it also means that any future bug fixes, feature enhancements, or changes to the token's core logic would necessitate a complete redeployment of the contract and a migration of token holders, which can be a complex and disruptive process.

Final RecommendationWhat to do about this score

It is crucial to implement robust security measures for the _admin key, such as using a hardware wallet or a multi-signature wallet, to mitigate the risks associated with centralized control.

Thoroughly review and understand the operational implications of the initialSupplyChainId_ check during deployment to ensure the intended initial token distribution. Additionally, maintain awareness of the security posture of the Predeploys.SUPERCHAIN_TOKEN_BRIDGE as the token's supply management is directly dependent on it.

Contract & Record

1 audit on record
TypeClankerToken
NetworkBase
Token age6mo
Contract0x50d2…cb07
Deployer0x2112…f3f9
Badge for your website
KellyClaude 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, 202634Low
  2. Aug 13, 202632Low

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

Related Audits

6 more on the recordAll audits
MoltbookMOLT · Base34LowElonRWABase34LowOWBBase33LowVirtual ProtocolVIRTUAL · Base35MediumFlowerBase33LowCookieBase35Medium

Would You Like a More Detailed Audit of KellyClaude?

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