Is KellyClaude Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

Centralized Control of Admin Role

H-01The `_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).

IssueThe `_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).

FixConsider 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.

StatusUnresolved

Medium

Dependency on External Superchain Token Bridge

M-01The `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).

IssueThe `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).

FixEnsure 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.

StatusUnresolved

Medium

Admin Control Over Token Metadata and Image

M-02The `_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.

IssueThe `_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.

FixConsider 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.

StatusUnresolved

Low

Conditional Initial Supply Minting Logic

L-01The 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).

IssueThe 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).

FixEnsure 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.

StatusUnresolved

Info

Lack of Upgradeability

I-01The 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.

IssueThe 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.

FixAcknowledge 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.

StatusUnresolved

Category Ratings

TechnicalLow9/10

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.

GovernanceMedium5/10

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.

UpgradesLow9/10

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.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyPass

Holder Composition

61.8% in top 10

28.8% in wallets33.0% in contracts

Effective Concentration42.0%

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.

Liquidity Depth

$244.9K across 10 pairs

Uniswap v4WETHanalysed$241.4K Uniswap v3🌙8$1.6K Uniswap v3WETH$683 AerodromeUSDC$557 Uniswap v3USDC$234 AerodromeUSDC$217

Show 4 more pairsShow less

Uniswap v4ETH$194 Uniswap v3WETH$48 Uniswap v4USDC$2 Uniswap v4ETH$1

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

Top-1 Unlocked Holder100.0%

Top-3 Unlocked100.0%

Key Addresses

3 addresses

Deployer

0x2112…f3f9

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.

What Raised This Score

7 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

Is KellyClaude Safe?

Security Findings

Centralized Control of Admin Role

Dependency on External Superchain Token Bridge

Admin Control Over Token Metadata and Image

Conditional Initial Supply Minting Logic

Lack of Upgradeability

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of KellyClaude?