On-chain security analysis — is it a scam or legit?
BNB ChainThe FourERC20 contract is a base ERC-20 implementation utilizing OpenZeppelin standards.
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.
The LP tokens of the analysed pool are locked or burned.
0xf54f…5d190x61d1…b874No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
FourERC20 contract, as provided, is an incomplete ERC-20 implementation. It lacks a constructor to call the internal _init function to set _name and _symbol. More critically, it does not implement any public minting mechanism (e.g., a _mint call in the constructor for initial supply, or a public mint function) or a burning mechanism. As a result, if deployed directly, the token would have an empty name, symbol, and a totalSupply of zero, making it non-functional as a standard ERC-20 token.C-01The FourERC20 contract, as provided, is an incomplete ERC-20 implementation. It lacks a constructor to call the internal _init function to set _name and _symbol. More critically, it does not implement any public minting mechanism (e.g., a _mint call in the constructor for initial supply, or a public mint function) or a burning mechanism. As a result, if deployed directly, the token would have an empty name, symbol, and a totalSupply of zero, making it non-functional as a standard ERC-20 token.
A derived contract must be implemented that provides a constructor to initialize the token's name and symbol via _init, and establish a supply mechanism (e.g., minting an initial supply to a deployer or a treasury, or implementing a controlled minting function).
Unresolved
_mint and _burn functions are internal. While FourERC20 itself doesn't expose them publicly, any derived contract that does expose them would need to implement robust access control (e.g., Ownable, AccessControl) to prevent unauthorized supply manipulation. Without such controls, a derived contract could allow anyone to mint or burn tokens, leading to severe economic instability.L-01The _mint and _burn functions are internal. While FourERC20 itself doesn't expose them publicly, any derived contract that does expose them would need to implement robust access control (e.g., Ownable, AccessControl) to prevent unauthorized supply manipulation. Without such controls, a derived contract could allow anyone to mint or burn tokens, leading to severe economic instability.
If a derived contract exposes minting or burning functionality, ensure strong access control mechanisms are in place to restrict these powerful functions to authorized entities only.
Unresolved
Context for _msgSender()Context contract to provide _msgSender() and _msgData(). This is a standard and generally good practice, especially for meta-transaction compatibility, as it abstracts the source of the transaction sender.I-01The contract uses OpenZeppelin's Context contract to provide _msgSender() and _msgData(). This is a standard and generally good practice, especially for meta-transaction compatibility, as it abstracts the source of the transaction sender.
No specific recommendation, as this is a standard and secure pattern. Ensure the Context contract itself is from a trusted source (which OpenZeppelin is).
Unresolved
_init Function Not Called in Base Contract's Constructor_init function, intended to set _name and _symbol, is internal and not called within the FourERC20 contract's constructor. This means if FourERC20 is deployed directly without a derived contract calling _init in its constructor, the token's name and symbol will remain empty strings.I-02The _init function, intended to set _name and _symbol, is internal and not called within the FourERC20 contract's constructor. This means if FourERC20 is deployed directly without a derived contract calling _init in its constructor, the token's name and symbol will remain empty strings.
Ensure that any contract inheriting from FourERC20 calls _init in its constructor to properly set the token's metadata.
Unresolved
The FourERC20 contract is a base ERC-20 implementation utilizing OpenZeppelin standards. However, it is incomplete as a standalone token, lacking a constructor to initialize its name and symbol, and crucially, any mechanism to mint an initial supply or allow for future supply management. If deployed directly, the token would be non-functional with a zero total supply, rendering it economically inert.
The contract leverages well-audited OpenZeppelin libraries for its core ERC-20 functionality, demonstrating good code security practices (7.2 Code Security). Standard functions like transfer, approve, transferFrom, increaseAllowance, and decreaseAllowance are correctly implemented, including protection against integer underflow in decreaseAllowance (7.2 Code Security). However, the contract is fundamentally incomplete, lacking a constructor to initialize token metadata and a public mechanism for supply creation (7.1 Architecture), which makes it non-functional as a standalone token.
The contract, as a base ERC-20 implementation, does not include specific governance or economic mechanisms (7.5 Governance, 7.4 Economic). The primary economic risk stems from the absence of any supply mechanism, meaning the token would have a zero total supply upon deployment, rendering it economically inert (7.4 Economic). Future derived contracts would need to implement robust access control for any minting/burning functions to prevent unauthorized supply manipulation (7.3 Access Control).
The contract is not designed with an upgrade mechanism (7.7 Upgrades), as indicated by is_proxy: false. This simplifies the architecture by removing upgrade-related complexities and risks, ensuring immutability once deployed. However, any necessary future changes would require a new deployment and migration of assets.
It is critical to implement a derived contract that inherits from FourERC20.
This derived contract must include a constructor to properly initialize the token's name and symbol by calling _init. Most importantly, it needs to establish a clear supply mechanism, such as minting an initial supply to a designated address upon deployment, or providing controlled public functions for minting and burning, protected by appropriate access control. Without these additions, the token will be non-functional.
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.
Our AI-powered scanner gives you a deeper, real-time smart contract analysis — free, with every scoring factor shown.
Get Detailed Audit Is this your token? Publish your own audit on this page
