The FourERC20 contract provides a foundational ERC-20 token implementation based on OpenZeppelin standards. However, it is designed as an abstract base contract and lacks a constructor to initialize token metadata (name, symbol) and, critically, any public mechanism for initial token supply creation or subsequent minting/burning. If deployed directly without a derived contract adding these essential functionalities, the token would be non-functional with a zero supply. This architectural incompleteness represents a significant risk.

On-chain security analysis — is it a scam or legit?
Is 富贵 Safe?
Not verified
This record has not gone through deep verification and is not being monitored. The score is a dated snapshot — the token’s risk can change at any time.Own this token? Put it under verification →The FourERC20 contract provides a foundational ERC-20 token implementation based on OpenZeppelin standards.
- 1 Critical finding(s) from audit
- 1 High finding(s) from audit
- 1 Low finding(s) from audit
Exact factors
- 1 Critical finding(s) from audit
- 1 High finding(s) from audit
- 1 Low 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
Security Checklist
as of audit · Sep 4Holders
as of audit · Sep 4, 2026- Contractstreasury, vesting, bridge, staking14.2%
- Walletsanonymous holders, free to sell5.9%
- Everyone elsethe rest of the supply80.0%
How holder types affect the score
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
Liquidity
as of audit · Sep 4The risk score reads depth across every pair.
The LP tokens of the analysed pool are locked or burned.
0x5ec0…d8bcNo privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.
Security Findings
CriticalIncomplete Token Implementation (No Constructor/Minting Mechanism)
The FourERC20 contract lacks a constructor to initialize the token's _name and _symbol variables. More critically, it does not provide any public or external function to mint new tokens or create an initial supply. The _mint function is internal, meaning a derived contract must implement the minting logic. If deployed as-is, the token would have a totalSupply of zero and no mechanism to increase it, rendering it unusable.C-01
Issue
The FourERC20 contract lacks a constructor to initialize the token's _name and _symbol variables. More critically, it does not provide any public or external function to mint new tokens or create an initial supply. The _mint function is internal, meaning a derived contract must implement the minting logic. If deployed as-is, the token would have a totalSupply of zero and no mechanism to increase it, rendering it unusable.
Fix
A derived contract must be created that inherits from FourERC20. This derived contract should include a constructor that calls _init to set the token's name and symbol, and also calls _mint to create an initial token supply for a designated address (e.g., the deployer or a treasury). If dynamic minting is desired, the derived contract must implement a public mint function with appropriate access control.
Status
Unresolved
HighMissing Access Control for Supply Management in Derived Contracts
The FourERC20 contract provides internal _mint and _burn functions for supply management. However, it does not include any access control mechanisms (e.g., Ownable, AccessControl) that would restrict who can call these functions if exposed publicly by a derived contract. If a derived contract implements public mint or burn functions without proper access control, any user could potentially manipulate the token supply, leading to severe economic instability or unauthorized token creation/destruction.H-01
Issue
The FourERC20 contract provides internal _mint and _burn functions for supply management. However, it does not include any access control mechanisms (e.g., Ownable, AccessControl) that would restrict who can call these functions if exposed publicly by a derived contract. If a derived contract implements public mint or burn functions without proper access control, any user could potentially manipulate the token supply, leading to severe economic instability or unauthorized token creation/destruction.
Fix
Any derived contract that exposes _mint or _burn functionality via public or external functions must implement robust access control. It is highly recommended to use a battle-tested access control mechanism like OpenZeppelin's Ownable or AccessControl to restrict these critical functions to authorized addresses (e.g., a contract owner, a multi-signature wallet, or a governance system).
Status
Unresolved
LowUse of _init Instead of Constructor for Initialization
The contract uses an internal function _init(string memory name_, string memory symbol_) to set the token's name and symbol, rather than a standard constructor. While this pattern can be useful for upgradeable contracts (proxies), the is_proxy: false flag indicates this is not an upgradeable contract. For non-upgradeable contracts, using a constructor is the standard and most straightforward way to initialize immutable state variables. If _init is not called exactly once during deployment by a derived contract's constructor, the token's name and symbol will remain empty.L-01
_init Instead of Constructor for InitializationIssue
The contract uses an internal function _init(string memory name_, string memory symbol_) to set the token's name and symbol, rather than a standard constructor. While this pattern can be useful for upgradeable contracts (proxies), the is_proxy: false flag indicates this is not an upgradeable contract. For non-upgradeable contracts, using a constructor is the standard and most straightforward way to initialize immutable state variables. If _init is not called exactly once during deployment by a derived contract's constructor, the token's name and symbol will remain empty.
Fix
For non-upgradeable contracts, it is generally recommended to use a constructor to initialize immutable state variables like _name and _symbol. If _init is retained, ensure that any derived contract's constructor explicitly calls _init exactly once with the desired name and symbol.
Status
Unresolved
InfoAdherence to OpenZeppelin ERC-20 Standard Implementation
The FourERC20 contract largely follows the OpenZeppelin ERC-20 standard implementation, including best practices such as increaseAllowance and decreaseAllowance to mitigate front-running risks associated with approve. The use of unchecked for decreaseAllowance is correctly guarded by a require statement, preventing underflow. This adherence to well-audited patterns enhances the contract's reliability and security for core token operations.I-01
Issue
The FourERC20 contract largely follows the OpenZeppelin ERC-20 standard implementation, including best practices such as increaseAllowance and decreaseAllowance to mitigate front-running risks associated with approve. The use of unchecked for decreaseAllowance is correctly guarded by a require statement, preventing underflow. This adherence to well-audited patterns enhances the contract's reliability and security for core token operations.
Fix
Continue to leverage battle-tested libraries like OpenZeppelin for core functionalities. Regularly review OpenZeppelin updates for security patches and improvements to ensure ongoing robustness.
Status
Resolved
Analysis
AI Copilotas of audit · Sep 4The technical architecture (7.1) of FourERC20 leverages OpenZeppelin's robust ERC-20 standard, providing well-tested implementations for core token functionalities like transfer and approve. The code security (7.2) benefits from safe arithmetic and standard allowance management. However, the contract is fundamentally incomplete as a standalone token, lacking a constructor and any public minting mechanism (7.1). This architectural flaw means it cannot be deployed as a functional token directly, and any derived contract must carefully implement critical supply management with proper access control (7.3) to avoid severe vulnerabilities.
The contract does not implement any governance mechanisms (7.5), relying on direct owner actions if a derived contract adds such functionality. Economically (7.4), the token's supply mechanism is entirely delegated to a derived contract. While the base contract correctly implements _mint and _burn internally, the absence of a public interface for these functions means the token's economic model is undefined in this contract. This poses a risk if the derived contract implements an insecure or overly centralized minting policy, potentially impacting token value and distribution.
The FourERC20 contract is not designed with upgradeability in mind (7.7), as indicated by the is_proxy: false flag. This simplifies the deployment model by removing proxy-related complexities and associated risks. However, this also means that any future changes to the token's logic or parameters would necessitate a new deployment and a potentially complex and costly migration process for users and integrated protocols.
It is strongly recommended that FourERC20 be used exclusively as a base contract for a derived token implementation.
The derived contract must include a constructor to initialize the token's name and symbol, and implement a secure, access-controlled minting mechanism to create the initial supply and manage future token issuance. Ensure that any functions added to the derived contract that modify token supply or critical parameters are protected by robust access control, preferably using a battle-tested library like OpenZeppelin's Ownable or a multi-signature wallet. Thoroughly test the derived contract's complete lifecycle, including deployment, initial supply creation, and all supply-modifying operations.
Contract & Record
Free for any token on the record. It links to this page and always shows the current score and the date it was checked.
- Sep 4, 20261Low
- Aug 30, 20263Low
Score changes are recorded as dated snapshots — history is append-only and cannot be edited.
Would You Like a More Detailed Audit of 富贵?
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