Early-stage security check — honeypot & rug-pull analysis
This report is based on a security audit of the contract at 0x23c26bc380475e4b52aa304607662fbf5e9aa8a3 on the Base network.
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 15, 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.
0x03c8…e5a20x9bd2…168c0.0% of the pool's LP is burned or time-locked. 100.0% is held, unlocked, by 1 address(es) other than the owner/deployer. One of them — a contract, 0x03c8…e5a2 — holds 100.0% 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 Solidity source code for the contract at was not provided for analysis. This prevents a comprehensive security audit and independent verification of the contract's logic and functionality by users and auditors.
Publish the full Solidity source code for the contract on a block explorer (e.g., Basescan) and provide it for security audits. Ensure that the deployed bytecode matches the compiled source code.
Unresolved
Without the source code, it is impossible to identify common technical vulnerabilities such as reentrancy, integer overflows/underflows, access control flaws, denial-of-service vectors, or other logic errors (7.2 Code Security, 7.3 Access Control).
Provide the source code to allow for a detailed technical security review. This includes analysis of all functions, state variables, and external interactions.
Unresolved
The absence of source code makes it impossible to determine if the contract is upgradeable (e.g., via a proxy pattern) or immutable (7.7 Upgrades). Consequently, potential risks associated with upgrade mechanisms, administrative privileges, or operational procedures (7.8 Operations) cannot be assessed.
Clearly document the contract's upgradeability status and any associated administrative roles. If upgradeable, provide the source code for all proxy and implementation contracts.
Unresolved
The ten largest holders own 87.3% of supply. Of that, 1.6% in DEX pools — not holders that can sell, so excluded from the concentration score. What remains: 67.7% in wallets, 18.1% in other contracts. 1,742 holders in total.
Watch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
Acknowledged
1,742 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 $72K (DexScreener, all pools). 24h trading volume $100K (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: $72K of DEX liquidity across 1 pools. Launch: under a day 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 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
This report is based on a security audit of the contract at 0x23c26bc380475e4b52aa304607662fbf5e9aa8a3 on the Base network. No Solidity source code was provided for analysis, therefore, a comprehensive security assessment could not be performed. The findings below are general informational points regarding best practices and missing information.
Due to the absence of Solidity source code (7.2 Code Security), a detailed technical analysis of the contract's architecture (7.1 Architecture) and implementation was not possible. Without the code, specific vulnerabilities like reentrancy, integer overflows, or access control flaws (7.3 Access Control) cannot be identified. The technical risk is currently assessed as Low, as no specific vulnerabilities could be found, but this is solely due to the lack of information.
Without the contract's source code, it is impossible to assess its economic model (7.4 Economic) or governance mechanisms (7.5 Governance). This includes evaluating tokenomics, fee structures, or decision-making processes. Similarly, external dependencies (7.6 External) such as oracles or other DeFi protocols cannot be identified or their risks evaluated. The economic and governance risk is currently assessed as Low, as no specific issues could be found, but this is solely due to the lack of information.
The contract's upgradeability status (7.7 Upgrades) cannot be determined without its source code. It is unknown if it implements a proxy pattern (e.g., UUPS, Transparent) or if it is immutable. This also impacts the assessment of operational risks (7.8 Operations) related to potential upgrades or administrative functions. The upgrade risk is currently assessed as Low, as no specific issues could be found, but this is solely due to the lack of information.
To ensure the security and transparency of the protocol, it is crucial to provide the full Solidity source code for all deployed contracts.
This enables a thorough audit for vulnerabilities, adherence to best practices, and proper verification on block explorers. Without source code, users and auditors cannot independently verify the contract's intended functionality or security posture, posing a significant trust and security risk.
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
