Early-stage security check — honeypot & rug-pull analysis
EthereumThis audit covers an ERC-20 token contract. The contract's ownership has been renounced, which means no single entity can call owner-restricted functions like recoverStuckToken.
Each 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 16, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
transfer and transferFrom, are designed to return a true value regardless of whether the underlying transfer operation actually succeeded or failed. This means that external systems or users relying on the return value to confirm a successful token transfer might be misled, potentially leading to incorrect assumptions about transaction outcomes. The _transfer function, which is called by transfer and transferFrom, also does not return a boolean, but transfer and transferFrom explicitly return true.CD-02Several critical functions, including transfer and transferFrom, are designed to return a true value regardless of whether the underlying transfer operation actually succeeded or failed. This means that external systems or users relying on the return value to confirm a successful token transfer might be misled, potentially leading to incorrect assumptions about transaction outcomes. The _transfer function, which is called by transfer and transferFrom, also does not return a boolean, but transfer and transferFrom explicitly return true.
The return logic for transfer, transferFrom, and other affected functions should be revised. These functions should accurately reflect the success or failure of the operation by returning true only upon successful completion and false or reverting on failure. This ensures that external callers can reliably determine the outcome of their transactions.
Unresolved
provideLiquidity function might cause a very small amount of tokens to be lost due to how calculations are performed. When the contract divides a number before multiplying it, tiny fractions can be rounded down and lost, which could slightly reduce the amount of tokens received by the user or held by the contract in certain scenarios.CD-01The provideLiquidity function might cause a very small amount of tokens to be lost due to how calculations are performed. When the contract divides a number before multiplying it, tiny fractions can be rounded down and lost, which could slightly reduce the amount of tokens received by the user or held by the contract in certain scenarios.
To prevent this minor loss, the calculation in provideLiquidity should be reordered to perform multiplication before division. This ensures that intermediate results retain higher precision, minimizing rounding errors.
Unresolved
The ten largest holders own 8.6% of supply. Of that, 4.1% in DEX pools — not holders that can sell, so excluded from the concentration score. What remains: 4.4% in wallets, 0.0% in other contracts. 490 holders in total.
Watch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
Acknowledged
490 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
100.0% of the pool's LP is burned or time-locked. 100.0% is held by TeamFinance, but the lock's end date is not published in the data we can read — its duration is unverified. Some pools are concentrated-liquidity (V3/V4) positions; shares above are by position as GoPlus reports them.
Check the lock's end date and beneficiary on the locker's own page before relying on it.
Acknowledged
Liquidity $233K (DexScreener, all pools). 24h trading volume $2.0M (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: fixed — the contract has no mint function. Control: nobody (ownership renounced). Code: not upgradeable (no proxy). Fees: no buy or sell tax. Market: $233K 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 audit covers an ERC-20 token contract. The contract's ownership has been renounced, which means no single entity can call owner-restricted functions like recoverStuckToken. The audit identified two findings: a High-severity issue related to misleading return values in core transfer functions and a Low-severity issue concerning potential rounding loss in a liquidity provision function.
The contract implements the ERC-20 standard, providing essential token functionalities (7.1 Architecture). Ownership has been renounced, making owner-restricted functions like renounceOwnership and recoverStuckToken dormant (7.3 Access Control). However, a High-severity issue (CD-02) was found where core transfer functions like transfer and transferFrom always return true, potentially misleading callers about transaction success (7.2 Code Security). Additionally, a Low-severity issue (CD-01) indicates potential rounding loss in the provideLiquidity function due to division before multiplication (7.2 Code Security).
The contract exhibits a strong security posture regarding governance and economic control due to the renounced ownership (7.5 Governance). This means no single address can exert privileged control over the token's core operations or economic parameters (7.4 Economic). The recoverStuckToken function, which could move tokens out of the contract, is now dormant and cannot be called by anyone, mitigating potential centralization risks (7.3 Access Control, 7.8 Operations).
The contract is not implemented as a proxy and does not include any upgrade mechanisms (7.7 Upgrades). This design choice eliminates risks associated with upgradeability, such as proxy misconfigurations or malicious upgrade paths. However, it also means the contract's logic cannot be modified or patched after deployment, requiring careful initial deployment.
It is crucial to address the High-severity finding regarding misleading return values in the transfer and transferFrom functions.
These functions should accurately reflect the success or failure of the underlying operations to prevent external systems from making incorrect assumptions. Additionally, the provideLiquidity function should be reviewed to reorder arithmetic operations, performing multiplication before division, to mitigate potential rounding losses and ensure precise calculations.
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
