On-chain security analysis — is it a scam or legit?
BNB ChainThe FourERC20 contract implements a standard ERC-20 token using OpenZeppelin's battle-tested patterns.
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 Sep 4, 2026
The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x0ed9…9706No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
approve Front-Running Risk (Mitigated)approve function is susceptible to a front-running attack where an attacker can sandwich a user's approve transaction to steal tokens. If a user approves an amount, then approves a different amount, an attacker can front-run the second approval, transfer the original approved amount, and then allow the second approval to go through, effectively getting two transfers for one approval. This contract provides increaseAllowance and decreaseAllowance functions which mitigate this risk by allowing atomic adjustments to allowances.L-01The standard ERC-20 approve function is susceptible to a front-running attack where an attacker can sandwich a user's approve transaction to steal tokens. If a user approves an amount, then approves a different amount, an attacker can front-run the second approval, transfer the original approved amount, and then allow the second approval to go through, effectively getting two transfers for one approval. This contract provides increaseAllowance and decreaseAllowance functions which mitigate this risk by allowing atomic adjustments to allowances.
Educate users to prefer increaseAllowance and decreaseAllowance over directly calling approve when adjusting existing allowances. If approve must be used to change an existing allowance, users should first set the allowance to zero and wait for that transaction to confirm before setting the new allowance.
Unresolved
FourERC20 contract provides the core ERC-20 logic but does not include public functions for minting or burning tokens. These functionalities are exposed only via internal _mint and _burn functions. This design choice means that a derived contract must be implemented to provide the actual supply mechanism (e.g., a minter role, a fixed supply, or a burn function).I-01The FourERC20 contract provides the core ERC-20 logic but does not include public functions for minting or burning tokens. These functionalities are exposed only via internal _mint and _burn functions. This design choice means that a derived contract must be implemented to provide the actual supply mechanism (e.g., a minter role, a fixed supply, or a burn function).
This is an intentional design pattern for a base ERC-20 implementation. Ensure that any contract inheriting from FourERC20 implements its supply management (minting/burning) functions with appropriate access control and economic considerations.
Unresolved
_init function is used to set _name and _symbol. While this contract is not explicitly a proxy implementation, if it were to be used as one in the future without proper initializer safeguards (e.g., an initializer modifier or an _initialized flag), the _init function could be called multiple times by malicious actors, potentially altering the token's name and symbol.I-02The _init function is used to set _name and _symbol. While this contract is not explicitly a proxy implementation, if it were to be used as one in the future without proper initializer safeguards (e.g., an initializer modifier or an _initialized flag), the _init function could be called multiple times by malicious actors, potentially altering the token's name and symbol.
If this contract is ever intended to be used as an implementation contract for an upgradeable proxy, ensure that the _init function is protected by an initializer modifier (e.g., from OpenZeppelin's Initializable contract) to prevent multiple invocations and re-initialization attacks.
Unresolved
The FourERC20 contract implements a standard ERC-20 token using OpenZeppelin's battle-tested patterns. It adheres to best practices for token functionality and includes mitigations for common ERC-20 allowance issues. The contract is designed as a base implementation, requiring a derived contract to define specific supply management (minting/burning) mechanisms. Overall, the contract exhibits high code quality and low inherent risk.
The technical implementation of the FourERC20 token is robust, leveraging OpenZeppelin's well-audited ERC-20 base (7.1 Architecture). It correctly handles token transfers and allowance mechanisms (7.2 Code Security), including increaseAllowance and decreaseAllowance to mitigate front-running risks associated with approve. The use of Solidity 0.8.0+ inherently protects against integer overflows/underflows, and the unchecked block is used safely. The contract lacks specific access control (7.3 Access Control) beyond standard ERC-20 roles, as it's intended as a base implementation.
The FourERC20 contract is a foundational ERC-20 token and does not implement complex economic models or governance mechanisms (7.5 Governance). Its economic stability (7.4 Economic) is therefore dependent on the broader protocol it integrates with, rather than internal logic. There are no specific parameters or fees managed within this contract that could introduce economic vulnerabilities. External dependencies (7.6 External) are limited to the well-vetted OpenZeppelin contracts.
The FourERC20 contract is not designed as an upgradeable proxy (7.7 Upgrades) and does not contain any proxy-related logic. It is a standard, non-upgradeable implementation. If future upgradeability is desired, a separate proxy pattern (e.g., UUPS or Transparent) would need to be implemented, with careful consideration for initializer functions to prevent re-initialization.
Ensure that any derived contracts extending FourERC20 implement robust access control for sensitive functions like _mint or _burn to prevent unauthorized supply manipulation.
If this token is to be integrated into a larger DeFi ecosystem, thoroughly review the interactions with other protocols for potential external risks. Consider the implications of its non-upgradeable nature for long-term protocol flexibility and future feature additions.
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
