Early-stage security check — honeypot & rug-pull analysis
The provided contract text was empty, preventing a comprehensive security audit.
Read the full analysisEach 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
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 Oct 18, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.
0x7d8d…324d0x1d2a…158cNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
0.0% of the pool's LP is burned or time-locked. 100.0% is held, unlocked, by 2 address(es) other than the owner/deployer. One of them — a wallet, 0x7d8d…324d — holds 99.8% and can remove that share at once; who controls it is not visible on-chain, so it is not treated as an independent provider.
Check the lock's end date and beneficiary on the locker's own page before relying on it.
Acknowledged
The source code for the contract at address was not provided. This prevents any meaningful security analysis, vulnerability identification, or assessment of the contract's functionality and adherence to security best practices.
Always provide the complete and verified source code for all contracts to be audited. This includes any libraries, interfaces, or inherited contracts. Verification on block explorers (e.g., Etherscan) is also highly recommended for transparency and public trust.
Unresolved
Without the contract's source code, it is impossible to evaluate critical technical security aspects such as reentrancy protection, integer overflow/underflow safeguards, access control mechanisms, input validation, or potential vulnerabilities related to external calls and gas limits. This directly impacts coverage items 7.1 Architecture, 7.2 Code Security, 7.3 Access Control, and 7.6 External.
A comprehensive code review is essential to identify and mitigate technical vulnerabilities. This involves static analysis, dynamic testing, and manual inspection by security experts to ensure the contract logic is sound and secure against known attack vectors.
Unresolved
The absence of source code prevents any assessment of economic models (7.4), governance structures (7.5), or upgradeability mechanisms (7.7). These areas are crucial for understanding the long-term stability, decentralization, and potential for future changes or exploits within the protocol.
For a complete security posture, the economic incentives, governance decision-making processes, and any upgrade paths (e.g., proxy patterns) must be clearly defined and thoroughly audited. This ensures alignment with protocol goals and minimizes risks associated with centralized control or unforeseen economic exploits.
Unresolved
The ten largest holders own 93.4% of supply. What remains: 91.0% in wallets, 2.5% in other contracts. The deployer/owner wallet itself holds 2.5%. 413 holders in total.
Watch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
Acknowledged
413 holders. Not listed by CoinGecko or any exchange GoPlus tracks. Nothing independent confirms who is behind this token, so every power its contract grants is scored at face value.
Match the contract address against the project's official channels before trading.
Acknowledged
Liquidity $81K (DexScreener, all pools). 24h trading volume $135K (DexScreener, all pools).
Size any position to the liquidity and daily volume shown — they set how much you can sell and at what price.
Acknowledged
A community token whose value comes from attention rather than a product. Being a meme is not a risk in itself: it is scored on exactly the same contract and market facts as any other token. The class itself adds no points; the contract and market facts decide the score. Basis: meme vocabulary in name/ticker (cat). Tokenomics — Supply: mint capability could not be read. Control: an owner that could not be resolved. Code: not upgradeable (no proxy). Fees: no buy or sell tax. Market: $81K of DEX liquidity across 1 pools. Launch: under a day of market history.
Expect attention-driven volatility; the facts in this report say whether the contract itself can be used against holders.
Acknowledged
The token's oldest DEX pool is less than a day old. Age is not part of the risk score — a new token is not a risky one by default — but a short history means fewer trades and holder changes behind the facts in this report.
Re-check ownership, liquidity and holder distribution as the token matures; those are the facts that move early.
Acknowledged
The provided contract text was empty, preventing a comprehensive security audit. This report outlines general security considerations and highlights the necessity of source code for a proper assessment. Without the source code, no specific vulnerabilities could be identified or analyzed.
Without the contract's source code, a detailed technical analysis (7.1 Architecture, 7.2 Code Security) cannot be performed. General best practices for EVM contracts include robust input validation and reentrancy protection. Access control (7.3) and external interactions (7.6) are critical areas that require code review to ensure security and proper functionality.
Economic (7.4) and governance (7.5) risks cannot be assessed without contract logic. Typically, these involve tokenomics, fee structures, and decision-making processes. Robust economic models and decentralized governance are key strengths, while centralized control or unvetted economic parameters pose risks. Operational aspects (7.8) like emergency pauses also depend on contract implementation.
Upgradeability (7.7) cannot be determined without source code. If the contract is upgradeable, proper proxy patterns (e.g., UUPS) and careful upgrade procedures are essential to prevent critical vulnerabilities. Non-upgradeable contracts offer immutability but lack flexibility, which can be a strength for trustless systems.
It is strongly recommended to provide the full and verified source code for any smart contract intended for deployment or public interaction.
A thorough audit requires complete visibility into the contract's logic, dependencies, and architecture. Engage with experienced auditors to review the code before deployment to identify and mitigate potential vulnerabilities.
This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.
Get Detailed Audit Is this your token? Publish your own audit on this page
