Early-stage security check — honeypot & rug-pull analysis
The provided contract text was empty, preventing a comprehensive source code 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 19, 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.
0x35c2…74020x1d2a…158cNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
The contract at on Arbitrum does not have verified source code on block explorers. This prevents a thorough security audit and makes it impossible for users to understand the contract's intended functionality and security properties. (7.2 Code Security, 7.8 Operations)
Verify the contract source code on a public block explorer (e.g., Arbiscan) to enable transparency and allow for public scrutiny and security analysis.
Unresolved
Without verified source code, the exact functionality, purpose, and state-changing operations of the contract cannot be determined. This poses a significant risk as users interacting with the contract do so blindly, potentially exposing themselves to unexpected behavior, loss of funds, or unauthorized actions. (7.1 Architecture, 7.4 Economic)
Provide comprehensive documentation detailing the contract's architecture, intended use, and all external functions. This should accompany the verified source code.
Unresolved
The absence of source code significantly increases operational risk. In the event of an incident, bug, or unexpected behavior, debugging, analysis, and incident response become extremely challenging or impossible without visibility into the contract's logic. (7.8 Operations)
Ensure that all deployed contracts have verified source code and are thoroughly documented to facilitate efficient operational management and incident response.
Unresolved
Without source code, it is impossible to assess the contract's access control mechanisms (e.g., owner privileges, role-based access) or its economic model (e.g., fee structures, tokenomics, incentive mechanisms). This means potential centralization risks, rug pull vectors, or economic exploits cannot be identified. (7.3 Access Control, 7.4 Economic, 7.5 Governance)
Implement robust, transparent access control mechanisms and a well-defined, publicly auditable economic model. Verification of source code is crucial for this assessment.
Unresolved
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, 0x35c2…7402 — holds 99.9% 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 ten largest holders own 84.2% of supply. Of that, 4.2% in DEX pools — not holders that can sell, so excluded from the concentration score. What remains: 79.9% in wallets, 0.0% in other contracts. The deployer/owner wallet itself holds 8.2%. 2,233 holders in total.
Watch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
Acknowledged
2,233 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 $82K (DexScreener, all pools). 24h trading volume $97K (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 token issued by a project for use, governance or fundraising. Scored on its contract and market facts. The class itself adds no points; the contract and market facts decide the score. Basis: no class-specific evidence. 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: $82K of DEX liquidity across 1 pools. Launch: 1 days of market history.
Check the project's own documentation for what the token is used for; this report covers what the contract allows.
Acknowledged
The token's oldest DEX pool is 1 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 source code audit. This report is based on the limited information available (address, network, verification status) and general security best practices for unverified contracts. The absence of source code significantly elevates all categories of risk.
A comprehensive technical security assessment (7.1 Architecture, 7.2 Code Security) was not possible due to the absence of verified source code. This lack of transparency prevents any analysis of common vulnerabilities such as reentrancy, integer overflows, or logic errors. Consequently, the technical risk is significantly elevated, as the contract's bytecode could contain arbitrary, potentially malicious, logic without any public scrutiny.
The economic model and governance structure (7.4 Economic, 7.5 Governance) of the contract could not be assessed without source code. This means potential centralization risks, such as an owner having unlimited minting or withdrawal capabilities, cannot be identified. Users are exposed to unknown economic risks and potential manipulation due to this lack of transparency.
The upgradeability status and safety (7.7 Upgrades) of the contract could not be determined without source code. It is unknown if the contract is part of a proxy pattern, and if so, whether the upgrade mechanism is secure and properly managed. This introduces significant uncertainty regarding future changes and potential risks from malicious upgrades, as no assessment of upgrade safety can be made.
It is strongly recommended that the contract owner verify the source code on a public block explorer.
This action is fundamental for transparency, user trust, and enabling any form of security assessment. Without verified source code, users should exercise extreme caution and avoid interacting with the contract, as its functionality and security properties remain entirely unknown and unauditable.
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