Is 富贵 Safe? Smart Contract Security Analysis

Security Findings

1 Crit1 High1 Low1 Info

Critical

Incomplete Token Implementation (No Constructor/Minting Mechanism)

C-01The `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.

IssueThe `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.

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

StatusUnresolved

High

Missing Access Control for Supply Management in Derived Contracts

H-01The `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.

IssueThe `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.

FixAny 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).

StatusUnresolved

Low

Use of `_init` Instead of Constructor for Initialization

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

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

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

StatusUnresolved

Info

Adherence to OpenZeppelin ERC-20 Standard Implementation

I-01The `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.

IssueThe `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.

FixContinue to leverage battle-tested libraries like OpenZeppelin for core functionalities. Regularly review OpenZeppelin updates for security patches and improvements to ensure ongoing robustness.

StatusResolved

Category Ratings

TechnicalLow7/10

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.

GovernanceLow8/10

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.

UpgradesLow9/10

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.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

20.0% in top 10

5.9% in wallets14.2% in contracts

Effective Concentration11.5%

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.

Liquidity Depth

$295.2K across 3 pairs

Pancakeswap v2WBNBanalysed$295.2K Pancakeswap v3USDT$22 UniswapUSDT$1

The risk score reads depth across every pair. The volume figure and the volume-to-liquidity ratio elsewhere on this page describe only the pair this audit analysed, so the two are not directly comparable.

LP Distribution

LP Burned100.0% · ≈ permanent lock

LP Locked100.0% · Null Address

Key Addresses

2 addresses

Deployer

0x5555…c479

Unlocked LP Held By

0x5ec0…d8bc

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

What Raised This Score

3 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

Final Recommendation

AI Copilot

It is strongly recommended that `FourERC20` be used exclusively as a base contract for a derived token implementation.…

Read the verdictHide

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

TypeToken

Audit History

1 audit on record

Aug 303Sep 41

Score changes are recorded as dated snapshots — history is append-only and cannot be edited.

Is 富贵 Safe?

Security Findings

Incomplete Token Implementation (No Constructor/Minting Mechanism)

Missing Access Control for Supply Management in Derived Contracts

Use of `_init` Instead of Constructor for Initialization

Adherence to OpenZeppelin ERC-20 Standard Implementation

Category Ratings

Security Checklist

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of 富贵?