Early-stage security check — honeypot & rug-pull analysis
The audit evaluated the DERC20 token contract deployed on Base.
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 24, 2026
The risk score reads depth across every pair.
Whether the LP tokens are locked could not be determined.
updateMintRate(uint256) function. When invoked, it executes mintInflation(), creating new tokens that dilute existing holders up to the hardcoded maximum rate of 2% annually. Additionally, the release() function transfers vested tokens from contract custody to recipients based on vesting schedules.CP-01The contract allows the privileged owner to mint new tokens and adjust the annual inflation rate by calling the updateMintRate(uint256) function. When invoked, it executes mintInflation(), creating new tokens that dilute existing holders up to the hardcoded maximum rate of 2% annually. Additionally, the release() function transfers vested tokens from contract custody to recipients based on vesting schedules.
Subject the updateMintRate function to a transparent timelock contract or direct decentralized DAO governance voting, and consider enforcing strict time-delayed caps before inflation adjustments take effect.
Unresolved
lockPool(address) and unlockPool() to toggle the isPoolUnlocked boolean switch and assign the target pool address. When locked, token transfers or interactions routed through the specified liquidity pool can be restricted or refused, placing secondary market trading under centralized control.CP-05The contract contains an administrative transfer-gating mechanism where the owner can call lockPool(address) and unlockPool() to toggle the isPoolUnlocked boolean switch and assign the target pool address. When locked, token transfers or interactions routed through the specified liquidity pool can be restricted or refused, placing secondary market trading under centralized control.
Remove the ability to arbitrarily lock liquidity pools once trading has commenced, or strictly enforce automated time-based unlocks and multisig/timelock safeguards to avoid centralized trade restrictions.
Unresolved
The ten largest holders own 100.0% of supply. Of that, 3.8% burned — not holders that can sell, so excluded from the concentration score. What remains: 16.2% in wallets, 80.0% in other contracts. The deployer/owner wallet itself holds 16.2%. 10,027 holders in total.
Watch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.
Acknowledged
10,027 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 $130K (DexScreener, all pools). 24h trading volume $426K (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: mintable with no on-chain cap found. Control: a ProxyAdmin contract. Code: not upgradeable (no proxy). Fees: no buy or sell tax. Market: $130K 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
The audit evaluated the DERC20 token contract deployed on Base. The codebase implements a standard OpenZeppelin-derived ERC-20 structure with voting extensions (ERC20Votes), linear vesting logic, and an inflation mechanism capped at 2% annually. However, centralization vectors exist around transfer gating and mint rate manipulation controlled by a privileged owner address.
Under 7.1 Architecture and 7.2 Code Security, the contract relies heavily on robust OpenZeppelin primitives, including ERC20Votes, ERC20Permit, and standard Math libraries. Standard safe math protections native to Solidity 0.8.26 prevent integer overflows, and vesting releases utilize explicit linear math. However, under 7.6 External and 7.8 Operations, pool gating introduces operational dependencies where transfer paths can be restricted. For example, the lockPool and unlockPool mechanisms directly modulate pool interaction paths, posing transactional risk if improperly maintained.
In terms of 7.4 Economic considerations, the token enforces a hardcoded upper limit on yearly inflation at 2% (MAX_YEARLY_MINT_RATE_WAD), preventing hyperinflationary abuse. Additionally, 7.5 Governance is strengthened by multi-signature ownership controls (3-of-6 threshold) rather than an unconstrained EOA. Nevertheless, under 7.3 Access Control, the contract owner possesses unilateral authority to call updateMintRate and trigger minting, as well as halt pool liquidity via lockPool. An example of this risk is the owner's ability to trigger immediate supply dilution through periodic minting intervals.
Regarding 7.7 Upgrades, the deployed DERC20 contract is non-upgradeable and deployed without proxy indirection, preventing unauthorized implementation swaps. The contract relies on static storage layouts and immutable inheritance patterns for its voting and token behaviors. However, administrative functions such as transferOwnership and updateTokenURI retain mutable parameters that alter token presentation and operational management. For instance, modifying the token URI or transferring ownership without a two-step timelocked confirmation can lead to governance handover risks.
Implement a formal timelock and decentralized governance module to intermediate all administrative calls currently restricted to onlyOwner, particularly lockPool, unlockPool, and updateMintRate.
Additionally, adopt a two-step ownership transfer pattern (such as OpenZeppelin's Ownable2Step) to prevent accidental transfer of administrative privileges.
Consider bounding pool locking mechanics so that user funds cannot be permanently restricted in secondary liquidity pools, and ensure transparent emission schedules are published on-chain to provide predictable supply dynamics for token holders.
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
