Early-stage security check — honeypot & rug-pull analysis
This report is based on an audit request for the contract at 0xf3e4788407151f02a0d009a10527d123e65e9af4 on Arbitrum.
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.
0x3de3…02150x1d2a…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, 0x3de3…0215 — 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 is not publicly verified on the Arbitrum block explorer. This significantly hinders transparency and the ability for independent security analysis, impacting overall code security (7.2).
Verify and publish the contract's source code on the block explorer to enable public scrutiny and enhance trust in the contract's operations.
Unresolved
Without source code, it's impossible to confirm the extent of testing performed. Inadequate testing can lead to undiscovered vulnerabilities, impacting code security (7.2) and economic stability (7.4) of the protocol.
Ensure all smart contracts undergo rigorous and comprehensive testing, including unit tests, integration tests, and property-based/fuzz testing, covering all possible execution paths and edge cases.
Unresolved
Access control (7.3) is a critical component of smart contract security. Without source code, it's impossible to verify if appropriate role-based access control or multi-signature mechanisms are implemented for sensitive functions, potentially leading to unauthorized actions.
Implement granular access control mechanisms, preferably using a multi-signature wallet for critical administrative functions, to prevent single points of failure and unauthorized operations.
Unresolved
Proper event emission is crucial for off-chain monitoring, user interface updates, and transparent operations (7.8). Without source code, it's unknown if all state-changing operations emit relevant events, which can hinder auditing and user experience.
Ensure all significant state changes and critical actions within the contract emit clear and informative events. This aids in off-chain indexing, auditing, and provides transparency to users.
Unresolved
The ten largest holders own 80.5% of supply. What remains: 80.5% in wallets, 0.0% in other contracts. The deployer/owner wallet itself holds 5.5%. 2,242 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,242 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 $77K (DexScreener, all pools). 24h trading volume $128K (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: $77K 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
This report is based on an audit request for the contract at 0xf3e4788407151f02a0d009a10527d123e65e9af4 on Arbitrum. Due to the absence of provided source code, a comprehensive security assessment for specific vulnerabilities could not be performed. The risk levels and findings presented are generalized best practices and do not reflect a deep analysis of the contract's specific implementation.
Without access to the contract's source code, a detailed technical analysis of its architecture (7.1), code security (7.2), and access control mechanisms (7.3) is not possible. Therefore, no specific technical strengths or vulnerabilities can be identified. General best practices for secure smart contract development are assumed but cannot be verified.
The economic model (7.4) and governance structure (7.5) of the contract cannot be evaluated without the underlying source code and protocol documentation. This prevents assessment of potential economic exploits or governance risks. External dependencies (7.6) also remain unknown, making it impossible to identify potential oracle manipulation or flash loan attack vectors.
The contract's upgradeability features (7.7) and operational procedures (7.8) cannot be determined without source code analysis. It is unknown if the contract is upgradeable, and if so, what proxy pattern is used or what safety mechanisms are in place. This limits the ability to assess future risk or operational flexibility.
For any smart contract deployment, it is crucial to ensure that the source code is publicly verified and available on block explorers.
This transparency allows for community review and independent security audits. Additionally, comprehensive testing, including unit, integration, and fuzz testing, should be conducted prior to deployment to mitigate potential vulnerabilities. Implement robust access control and consider a multi-signature setup for critical operations.
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
