Early-stage security check — honeypot & rug-pull analysis
BNB ChainThe FourERC20 contract is a basic ERC-20 token implementation based on OpenZeppelin's battle-tested libraries.
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 Sep 4, 2026
The risk score reads depth across every pair.
Whether the LP tokens are locked could not be determined.
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.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.
A 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.
Unresolved
_init Function Not Called in Base Contract_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.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.
Any 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.
Unresolved
_transfer Function in Provided Code_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.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.
Ensure 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.
Unresolved
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.
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.
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.
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.
To make the FourERC20 token functional, it is critically important to implement a token minting mechanism.
This should be done in a derived contract that inherits from FourERC20 and includes a function to call _mint (or a similar supply creation method) to establish an initial supply and allow for future token issuance if desired. Additionally, ensure the derived contract's constructor properly calls the _init function to set the token's name and symbol.
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.
The TrenchesStarterPack (战壕入门包) contract on BNB Chain is 0x99f5054f1d9799f901df533fbfe5d9b3f25b4444. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.
Quantum Audit's risk score for TrenchesStarterPack is 41/100 (Medium risk) as of Sep 4, 2026, computed by a deterministic function from on-chain facts — Contract verified: Verified; Ownership: Renounced; Mint: No mint; Upgradeability: Fixed code. A score is a dated snapshot of those facts, not a guarantee; each one is listed on this page.
As of Sep 4, 2026, the 10 largest holders own 100.0% of the supply. The Holders section on this page shows who they are by holder type.
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
