Quantum Audit Logo

Is CLAWNCH Safe?

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

CLAWNCH CLAWNCH
0xa1f7…47be
Base Not verifiedLast checked 2d ago 1 audit on record
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

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.

1 High1 Medium1 Low2 Informational
Volume 24h
$288.9K
Liquidity
$157.5K
Price
$0.000003345
Token Age
7mo
Top 10 Holders
47.2%

Security Findings

1 High1 Med1 Low2 Info
High

Centralized Control of Admin Role and Metadata

H-01The `_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).
IssueThe `_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).
FixConsider 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.
StatusUnresolved
Medium

Reliance on External Superchain Token Bridge

M-01The `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).
IssueThe `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).
FixEnsure 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.
StatusUnresolved
Low

Single Point of Initial Supply Minting

L-01The 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).
IssueThe 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).
FixEnsure 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.
StatusUnresolved
Info

Non-Upgradeable Contract Design

I-01The `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).
IssueThe `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).
FixAcknowledge 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.
StatusUnresolved
Info

Unused ERC20Votes Functionality

I-02The 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).
IssueThe 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).
FixClarify 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.
StatusUnresolved

Category Ratings

TechnicalLow9/10

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

GovernanceMedium6/10

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

UpgradesLow9/10

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.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

47.2% in top 10
7.0% in wallets40.2% in contracts
Effective Concentration23.1%

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

$172.4K across 9 pairs
Uniswap v4WETHanalysed$157.5K91.3%Uniswap v3WETH$13.4K7.8%Uniswap v3🌙8$1.4K0.8%Uniswap v3USDT$250.0%0xB0C2…9C88WETH$40.0%Uniswap v4ETH$40.0%
Show 3 more pairsShow less
Uniswap v4USDC$30.0%Uniswap v4USDC$10.0%Uniswap v4ETH$00.0%

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

5 addresses
Deployer
0x5ec3…572d
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.

What Raised This Score

7 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

Related Audits

6 more on the record
KittehCoin (MEOW)Medium RiskAlphabet Inc. (GOOGLC)Medium RiskBankrCoin (BNKR)Medium Risko1.exchange (O)Medium RiskNVIDIA Corporation (NVDAC)Medium RiskSurplus Intelligence (SURPLUS)Medium Risk

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