Early-stage security check — honeypot & rug-pull analysis
The audit of the Token contract, an ERC-20 token, revealed a generally robust technical implementation leveraging OpenZeppelin's battle-tested libraries.
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 Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x40ee…3abbNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Token contract's constructor mints the entire TOTAL_SUPPLY (100,000,000 tokens) to a single recipient address. This design choice results in a highly centralized initial distribution, granting the recipient complete control over the token supply. This centralization can lead to significant market manipulation risks, lack of decentralization, and potential single point of failure for the token's ecosystem.H-01The Token contract's constructor mints the entire TOTAL_SUPPLY (100,000,000 tokens) to a single recipient address. This design choice results in a highly centralized initial distribution, granting the recipient complete control over the token supply. This centralization can lead to significant market manipulation risks, lack of decentralization, and potential single point of failure for the token's ecosystem.
If decentralization is a goal, consider implementing a more distributed initial supply mechanism. This could involve a vesting contract, a multi-signature wallet for the recipient, a public sale, or a phased distribution strategy. Clearly communicate the distribution strategy to stakeholders.
Unresolved
The contract extensively utilizes battle-tested OpenZeppelin contracts (ERC20, ERC20Burnable, ERC20Permit). This is a strong security practice as these libraries are widely audited and maintained. However, it also means that any undiscovered vulnerability in the specific versions of the OpenZeppelin contracts used would directly impact this token.
Regularly monitor OpenZeppelin security advisories and consider upgrading to newer versions of the libraries if critical vulnerabilities are patched. Ensure the exact versions of OpenZeppelin contracts used are pinned in the package.json or equivalent dependency management system.
Unresolved
TOTAL_SUPPLY are set as constants or in the constructor and cannot be modified after deployment. While this provides predictability and transparency, it removes any flexibility for future adjustments, such as re-branding or supply modifications, which might be desired in some long-term project roadmaps.I-02The token's name, symbol, decimals (fixed at 18), and TOTAL_SUPPLY are set as constants or in the constructor and cannot be modified after deployment. While this provides predictability and transparency, it removes any flexibility for future adjustments, such as re-branding or supply modifications, which might be desired in some long-term project roadmaps.
This is a design choice inherent to standard ERC-20 tokens. Ensure that the project's long-term vision aligns with these immutable parameters. If future flexibility is desired, an upgradeable token contract or a different tokenomics model would be required.
Unresolved
pragma solidity 0.8.35;. While this prevents unexpected behavior from future compiler changes, it might miss out on minor bug fixes or optimizations introduced in newer patch versions within the 0.8.x series.I-03The contract specifies a fixed Solidity compiler version pragma solidity 0.8.35;. While this prevents unexpected behavior from future compiler changes, it might miss out on minor bug fixes or optimizations introduced in newer patch versions within the 0.8.x series.
Consider using a floating pragma (e.g., ^0.8.35) if minor patch updates are desired, or regularly review and update the fixed version to the latest stable patch within the major version if no breaking changes are introduced. Always test thoroughly after any compiler version change.
Unresolved
The audit of the Token contract, an ERC-20 token, revealed a generally robust technical implementation leveraging OpenZeppelin's battle-tested libraries. The primary concern identified is the highly centralized initial distribution of the entire token supply to a single recipient, which poses significant economic and governance risks.
The contract demonstrates strong technical security by inheriting from OpenZeppelin's ERC20, ERC20Burnable, and ERC20Permit libraries, which are widely audited and considered secure (7.2 Code Security). Standard ERC20 functionalities like transfers, approvals, and burning are implemented correctly. The use of Solidity 0.8.35 ensures protection against integer overflows/underflows by default, except in explicitly unchecked blocks which are used appropriately within OZ logic. No reentrancy or other common technical vulnerabilities were found (7.2 Code Security).
The contract's economic model is straightforward, with a clearly defined TOTAL_SUPPLY and initial distribution mechanism (7.4 Economic). However, this model introduces a high centralization risk as the entire token supply is minted to a single recipient address during deployment. This grants the initial recipient complete control over the token's distribution and potential market influence, lacking any on-chain governance mechanisms (7.5 Governance) for broader community input.
The contract is not designed to be upgradeable, as indicated by is_proxy: false in the provided information (7.7 Upgrades). This eliminates upgrade-related risks such as proxy misconfigurations or logic inconsistencies between implementation versions. The immutability of the contract ensures predictable behavior post-deployment.
It is strongly recommended to carefully consider the implications of the highly centralized initial token distribution.
If a decentralized distribution is desired, mechanisms such as a vesting schedule, multi-signature wallet for the recipient, or a public sale contract should be explored to mitigate the risks associated with a single point of control. For future token designs, consider implementing a more distributed initial supply or incorporating governance features if broader community participation is intended.
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
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
