Quantum Audit Logo

Is ZERO KNOWLEDGE CAT a Scam?

Early-stage security check — honeypot & rug-pull analysis

ZERO KNOWLEDGE CAT ZKAT
0x6055…f222
Base
Not verifiedThis 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.
Last checked 8d ago 1 audit on record New Launch · 1d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The AdvancedLaunchToken contract is an ERC20 token with custom logic for a maximum wallet cap and an external reward tracker integration. The audit identified a High-severity issue related to centralized control by the 'launcher' address, which poses a significant single point of failure. Additionally, a Medium-severity finding was noted regarding unhandled external call reverts. The contract exhibits good code quality and standard ERC20 implementation, but key economic parameters are immutable, limiting future flexibility. Overall, the contract presents a Medium risk profile, primarily due to the centralized control and potential for operational issues if the 'launcher' key is compromised or external calls fail silently.

1 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (1d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$261.7K
Liquidity
$87.4K
Price
$0.000604
Token Age
1d
Top 10 Holders
28.8%

Security Findings

1 High1 Med1 Low1 Info
High

Centralized Control by Launcher Address

H-01The `launcher` address holds significant power over critical contract functions, including `setExempt`, `setRewardTracker`, and `finishLaunch`. A compromise of this single address could lead to unauthorized manipulation of the token's core mechanics, such as bypassing max wallet caps for specific addresses, setting a malicious reward tracker, or prematurely activating the 'launched' state. This creates a single point of failure for the protocol's operational security (7.3 Access Control, 7.8 Operations).
IssueThe `launcher` address holds significant power over critical contract functions, including `setExempt`, `setRewardTracker`, and `finishLaunch`. A compromise of this single address could lead to unauthorized manipulation of the token's core mechanics, such as bypassing max wallet caps for specific addresses, setting a malicious reward tracker, or prematurely activating the 'launched' state. This creates a single point of failure for the protocol's operational security (7.3 Access Control, 7.8 Operations).
FixImplement a multi-signature wallet (e.g., Gnosis Safe) for the `launcher` address to distribute control and require multiple approvals for critical operations. Alternatively, consider a time-locked mechanism for sensitive actions to provide a window for intervention if a compromise occurs.
StatusUnresolved
Medium

Unhandled External Call Revert in `_update`

M-01The `_update` function makes an external call to `rewardTracker.ping` via `call{gas: 5_000_000}`. While the `ok` boolean is captured from the low-level call, it is not used to revert the transaction if the `ping` call fails. This 'fire-and-forget' approach means that if the `rewardTracker` is critical for certain off-chain or on-chain processes, its failure might go unnoticed, leading to inconsistencies or unexpected behavior in the broader ecosystem (7.2 Code Security, 7.6 External).
IssueThe `_update` function makes an external call to `rewardTracker.ping` via `call{gas: 5_000_000}`. While the `ok` boolean is captured from the low-level call, it is not used to revert the transaction if the `ping` call fails. This 'fire-and-forget' approach means that if the `rewardTracker` is critical for certain off-chain or on-chain processes, its failure might go unnoticed, leading to inconsistencies or unexpected behavior in the broader ecosystem (7.2 Code Security, 7.6 External).
FixConsider explicitly checking the `ok` boolean and reverting the transaction if the `ping` call is expected to always succeed and its failure would indicate a critical issue. For example: `require(ok, 'RewardTracker ping failed');`. If the 'fire-and-forget' behavior is intentional, document this design choice clearly.
StatusUnresolved
Low

Immutability of Key Economic Parameters

L-01The `maxWalletBps` parameter, which defines the maximum percentage of total supply an address can hold, is set in the constructor and declared as `immutable`. While immutability provides certainty and reduces governance complexity, it also means that this critical economic parameter cannot be adjusted after deployment. If the project needs to modify the maximum wallet cap due to changing market conditions, community feedback, or unforeseen circumstances, a new token contract would be required, necessitating a complex migration process (7.4 Economic).
IssueThe `maxWalletBps` parameter, which defines the maximum percentage of total supply an address can hold, is set in the constructor and declared as `immutable`. While immutability provides certainty and reduces governance complexity, it also means that this critical economic parameter cannot be adjusted after deployment. If the project needs to modify the maximum wallet cap due to changing market conditions, community feedback, or unforeseen circumstances, a new token contract would be required, necessitating a complex migration process (7.4 Economic).
FixEvaluate the long-term implications of an immutable `maxWalletBps`. If flexibility is desired, consider making this parameter configurable by a trusted role (e.g., `launcher` or a governance mechanism) with appropriate time-locks or multi-signature controls. If immutability is a core design principle, ensure this is clearly communicated to users.
StatusUnresolved
Info

Extensive List of Exempted Addresses from Max Wallet Cap

I-01Several addresses, including the `launcher`, `poolManager`, `creator`, and the `0x...dEaD` address, are permanently exempted from the `maxWalletBps` cap in the constructor. While `0x...dEaD` is a burn address and `creator` has no special privileges, the `launcher` and `poolManager` are operational roles. These exemptions mean these entities can accumulate an unlimited supply of tokens, potentially creating large whale holdings that could contradict the spirit of a max wallet cap designed for broader distribution (7.4 Economic).
IssueSeveral addresses, including the `launcher`, `poolManager`, `creator`, and the `0x...dEaD` address, are permanently exempted from the `maxWalletBps` cap in the constructor. While `0x...dEaD` is a burn address and `creator` has no special privileges, the `launcher` and `poolManager` are operational roles. These exemptions mean these entities can accumulate an unlimited supply of tokens, potentially creating large whale holdings that could contradict the spirit of a max wallet cap designed for broader distribution (7.4 Economic).
FixEnsure that the operational necessity for each exempted address to hold an unlimited supply is thoroughly justified and documented. Consider if any of these exemptions could be managed dynamically by the `launcher` via the `setExempt` function rather than being hardcoded, offering more flexibility if roles or operational needs change.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract demonstrates good adherence to ERC20 standards by inheriting from OpenZeppelin's implementation (7.1 Architecture). The `_update` function correctly implements custom logic for a max wallet cap and integrates an external `rewardTracker` ping (7.2 Code Security). However, the `launcher` address holds significant centralized control over critical functions like `setExempt` and `setRewardTracker` (7.3 Access Control). Additionally, the external call to `rewardTracker.ping` does not handle potential reverts, which could lead to silent failures (7.6 External).

GovernanceHigh1/10

The economic model includes a `maxWalletBps` to limit individual holdings, which is a positive feature for distribution (7.4 Economic). Key addresses like the `launcher` and `poolManager` are appropriately exempted from this cap to facilitate operational needs (7.4 Economic). However, the `launcher` role represents a single point of failure for critical operations, lacking decentralized governance (7.5 Governance). The immutability of the `maxWalletBps` parameter also limits future adaptability to changing market dynamics (7.4 Economic).

UpgradesMedium5/10

The `AdvancedLaunchToken` contract is not designed with an upgrade mechanism, such as a proxy pattern (7.7 Upgrades). This means that the contract's logic is immutable once deployed, providing certainty but precluding any future modifications or bug fixes to the core contract logic. Any significant changes would necessitate a new contract deployment and migration of assets.

Security Checklist

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

Holder Composition

28.8% in top 10
5.9% in wallets22.9% in contracts
Effective Concentration15.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

$88.4K across 10 pairs
Uniswap v4NOCKanalysed$87.4K98.9%Uniswap v4USDC$3300.4%Uniswap v4USDC$3030.3%Uniswap v4WETH$1380.2%Uniswap v4USDC$980.1%Uniswap v4USDC$430.0%
Show 4 more pairsShow less
Uniswap v4USDC$340.0%Uniswap v4ETH$40.0%Uniswap v4USDC$30.0%Uniswap v4USDC$10.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.

Key Addresses

1 addresses
Deployer
0x34a6…d2b0

What Raised This Score

6 factors
  • Ownership status UNKNOWN (owner could not be resolved)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • Token age < 7 days (early, volatile)
  • 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
Aerodrome Finance (AERO)Medium RiskB3Medium RiskSapienMedium RiskLienFi (LFI)Medium RiskRaveDAO (RAVE)Medium RiskMey Network (MEY)Medium Risk

Would You Like a More Detailed Audit of ZERO KNOWLEDGE CAT?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit