Quantum Audit Logo

Is TrenchesStarterPack a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

TrenchesStarterPack 战壕入门包
0x99f5…4444
BNB Chain Not verifiedLast checked 3d ago 1 audit on record New Launch · 3d old
DexScreener ↗
How is this score calculated? → Medium Risk
Executive SummaryAI Copilot

The `FourERC20` contract is a basic ERC-20 token implementation based on OpenZeppelin's battle-tested libraries. However, a critical functional flaw exists: the contract, as provided, lacks any mechanism to mint new tokens, rendering the token non-functional as its total supply will always be zero. This fundamental issue prevents the token from being used for any economic purpose.

1 Critical2 Informational
! Early-stage analysis. This token has limited on-chain history (3d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$22.1K
Liquidity
$29.5K
Price
$0.00006087
Token Age
3d
Top 10 Holders
100.0%

Security Findings

1 Crit2 Info
Critical

Missing Token Minting Mechanism

C-01The `FourERC20` contract, as implemented, does not include any function (public or internal) to mint new tokens. The `_totalSupply` variable will therefore always remain zero, and no tokens can ever be created or distributed. The contract comments explicitly state that a supply mechanism must be added in a derived contract using `_mint`, but without such a derived contract, the token is non-functional and cannot be used for any purpose.
IssueThe `FourERC20` contract, as implemented, does not include any function (public or internal) to mint new tokens. The `_totalSupply` variable will therefore always remain zero, and no tokens can ever be created or distributed. The contract comments explicitly state that a supply mechanism must be added in a derived contract using `_mint`, but without such a derived contract, the token is non-functional and cannot be used for any purpose.
FixA derived contract must be created that inherits from `FourERC20` and implements a `_mint` function (or similar mechanism) to create and distribute tokens, updating `_totalSupply` and `_balances`. This derived contract should also call `_init` in its constructor to properly initialize the token's metadata.
StatusUnresolved
Info

`_init` Function Not Called in Base Contract

I-01The `_init(string memory name_, string memory symbol_)` function is internal and intended to set the token's name and symbol. However, `FourERC20` itself does not have a constructor that calls this function. This means that if `FourERC20` is deployed directly (without a derived contract calling `_init`), its `name()` and `symbol()` functions will return empty strings, leading to improper token metadata.
IssueThe `_init(string memory name_, string memory symbol_)` function is internal and intended to set the token's name and symbol. However, `FourERC20` itself does not have a constructor that calls this function. This means that if `FourERC20` is deployed directly (without a derived contract calling `_init`), its `name()` and `symbol()` functions will return empty strings, leading to improper token metadata.
FixAny contract deriving from `FourERC20` must implement a constructor that calls `_init` with the desired name and symbol to ensure proper token metadata is set upon deployment.
StatusUnresolved
Info

Truncated `_transfer` Function in Provided Code

I-02The provided source code for the `_transfer` function in `FourERC20.sol` is truncated. While it is likely intended to be the standard OpenZeppelin implementation, the full code is not available for a complete review. Assuming it's the standard implementation, it should include checks for zero addresses and sufficient balances.
IssueThe provided source code for the `_transfer` function in `FourERC20.sol` is truncated. While it is likely intended to be the standard OpenZeppelin implementation, the full code is not available for a complete review. Assuming it's the standard implementation, it should include checks for zero addresses and sufficient balances.
FixEnsure the full and correct OpenZeppelin `_transfer` implementation is used, including all necessary checks (e.g., `to` not zero address, `from` having sufficient balance) to prevent potential issues. Provide the complete source code for all contracts for a thorough audit.
StatusUnresolved

Category Ratings

TechnicalLow8/10

The contract leverages battle-tested OpenZeppelin libraries (v4.9.4) for its ERC-20 implementation, providing a solid foundation for security and adherence to standards (7.2 Code Security). Standard functions like `transfer`, `approve`, and `transferFrom` are correctly overridden. However, the `FourERC20` contract itself lacks any mechanism to mint new tokens, meaning `_totalSupply` will always be zero and no tokens can ever exist or be transferred (7.1 Architecture). The internal `_init` function for setting name/symbol is also not called within the contract, requiring a derived contract to properly initialize it.

GovernanceHigh3/10

The economic model is severely impacted by the absence of a token minting mechanism (7.4 Economic). As designed, the token cannot have any supply, making it economically non-viable and preventing any value transfer. There are no explicit governance mechanisms (7.5 Governance) or complex economic parameters, which simplifies the contract but does not mitigate the fundamental lack of token supply.

UpgradesLow7/10

The contract is not designed with upgradeability in mind (7.7 Upgrades), which eliminates risks associated with proxy patterns or upgrade logic. This simplifies the deployment and reduces the attack surface related to upgrade mechanisms. However, this also means that the critical functional flaw of missing a minting mechanism cannot be rectified without a complete redeployment of a new contract.

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass

Holder Composition

100.0% in top 10
0.0% in wallets100.0% in contracts
Effective Concentration40.0%

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.

Liquidity Depth

$29.5K

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

Key Addresses

1 addresses
Deployer
0x17e9…c66f

What Raised This Score

5 factors
  • Top-10 concentration > 30% (100.0% total → 40.0% effective; 0.0% in EOAs, 100.0% in contracts — moderate)
  • Liquidity NOT locked (owner can withdraw — rug-pull risk)
  • Liquidity < $50k ($29,500 across 1 pairs — thin market)
  • Token age < 7 days (early, volatile)
  • 1 Critical finding(s) from audit

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

Related Audits

6 more on the record
GUAMedium RiskChainbase Token (C)Medium RiskmemestockMedium RiskGiggle Cat (NIANNIAN)Medium RiskBabySharkMedium Risk吉祥马Medium Risk

Would You Like a More Detailed Audit of TrenchesStarterPack?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit