Quantum Audit Logo
Launch App

On-chain security analysis — is it a scam or legit?

Is 富贵 Safe?

BNB Chain
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 →
Last checked Sep 4, 2026 · 1 audit on record
SummaryAI Copilot

The FourERC20 contract provides a foundational ERC-20 token implementation based on OpenZeppelin standards.

Read the full analysis
What raised the score
  • 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 47 of 7 checks passed
Contract verifiedVerified
OwnershipRenounced
MintNo mint
Liquidity lockLocked
UpgradeabilityFixed code
HoneypotNone found
Buy / sell tax0% / 0%

Holders

as of audit · Sep 4, 2026
14.2%Contracts5.9%80.0%Everyone else
14.2%5.9%80.0%Everyone else
ContractsWalletsEveryone elseBubble area = share of supply
20.0%of supply sits with the top 10 holders
  • Contractstreasury, vesting, bridge, staking14.2%
  • Walletsanonymous holders, free to sell5.9%
  • Everyone elsethe rest of the supply80.0%
Effective concentrationwhat the score reads11.5%
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 4$295.2K across 3 pairs
LP tokensLocked

The LP tokens of the analysed pool are locked or burned.

Analysed pool$295.2KShare of depth100.0%
LP Burned100.0% · ≈ permanent lock
LP Locked100.0% · Null Address
Unlocked LP held by
0x5ec0…d8bc

No privileged address appears among these holders: the unlocked liquidity sits with independent providers, not with the deployer.

Security Findings

1 Critical1 High1 Low1 Info
Critical

Incomplete 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

High

Missing 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

Low

Use 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

Issue

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

Info

Adherence 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 4
Executive SummaryWhat the contract is and what the review found

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.

Technical7/10Low risk

The 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.

Governance8/10Low risk

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.

Upgrades9/10Low risk

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.

Final RecommendationWhat to do about this score

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

1 audit on record
TypeToken
NetworkBNB Chain
Token age1mo
Contract0x198d…4444
Deployer0x5555…c479
Badge for your website
富贵 security record badge

Free for any token on the record. It links to this page and always shows the current score and the date it was checked.

Audit History
  1. Sep 4, 20261Low
  2. 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