Is 币安人生 Safe? Smart Contract Security Analysis

Security Findings

1 Low2 Info

Low

Reliance on Derived Contracts for Supply Management and Initialization

L-01As `_mint` and `_burn` are internal functions, any token built upon `FourERC20` will need to implement its own supply management logic. Similarly, the `_init` function is internal, requiring a derived contract to call it for setting token metadata. This introduces a dependency on the security and correctness of the derived contract for controlling the total supply, distribution, and initial setup of tokens. While flexible, it shifts the responsibility for critical economic parameters and initial configuration to external code (7.1 Architecture, 7.3 Access Control).

IssueAs `_mint` and `_burn` are internal functions, any token built upon `FourERC20` will need to implement its own supply management logic. Similarly, the `_init` function is internal, requiring a derived contract to call it for setting token metadata. This introduces a dependency on the security and correctness of the derived contract for controlling the total supply, distribution, and initial setup of tokens. While flexible, it shifts the responsibility for critical economic parameters and initial configuration to external code (7.1 Architecture, 7.3 Access Control).

FixWhen developing the derived contract, ensure that minting, burning, and initialization functions are implemented with robust access control (e.g., `onlyOwner` or a multi-signature wallet) and adhere to best security practices. Thoroughly audit the derived contract's specific logic for these critical operations.

StatusUnresolved

Info

Incomplete Token Implementation (No Mint/Burn Mechanism or Public Constructor)

I-01The `FourERC20` contract serves as a base for an ERC-20 token but lacks a public constructor to initialize `name` and `symbol` and does not implement any minting or burning mechanisms. These functionalities (`_init`, `_mint`, `_burn`) are internal and must be implemented or called by a derived contract to create a fully functional token. This is an architectural design choice rather than a vulnerability, but it means the contract cannot be deployed as a standalone, fully functional token without further development.

IssueThe `FourERC20` contract serves as a base for an ERC-20 token but lacks a public constructor to initialize `name` and `symbol` and does not implement any minting or burning mechanisms. These functionalities (`_init`, `_mint`, `_burn`) are internal and must be implemented or called by a derived contract to create a fully functional token. This is an architectural design choice rather than a vulnerability, but it means the contract cannot be deployed as a standalone, fully functional token without further development.

FixEnsure that any derived contract inheriting from `FourERC20` implements a public constructor that calls `_init` to set the token's metadata and provides appropriate, access-controlled functions for `_mint` and `_burn` to manage the token supply. Document these dependencies clearly for future developers and auditors.

StatusUnresolved

Info

Standard ERC-20 `approve` Race Condition

I-02The `approve` function, while compliant with the ERC-20 standard, is susceptible to a known race condition where a malicious spender can exploit a user's attempt to change an allowance. If a user approves `X` amount, then approves `Y` amount, a front-running attacker can spend `X` before the `Y` transaction confirms, resulting in the attacker spending `X+Y`. This is a characteristic of the ERC-20 standard, not a flaw in this specific implementation (7.2 Code Security).

IssueThe `approve` function, while compliant with the ERC-20 standard, is susceptible to a known race condition where a malicious spender can exploit a user's attempt to change an allowance. If a user approves `X` amount, then approves `Y` amount, a front-running attacker can spend `X` before the `Y` transaction confirms, resulting in the attacker spending `X+Y`. This is a characteristic of the ERC-20 standard, not a flaw in this specific implementation (7.2 Code Security).

FixAdvise users and integrated applications to prefer using `increaseAllowance` and `decreaseAllowance` functions over directly calling `approve` when modifying existing allowances. If `approve` must be used, the recommended safe practice is to first set the allowance to zero, wait for that transaction to confirm, and then set the new desired allowance.

StatusUnresolved

Category Ratings

TechnicalLow10/10

The technical architecture (7.1) is sound, utilizing battle-tested OpenZeppelin patterns for ERC-20 implementation. Code security (7.2) is robust, with proper handling of integer arithmetic and standard checks. Access control (7.3) for core token operations like transfer and allowance is standard ERC-20. However, the contract is incomplete, requiring a derived contract for minting/burning and initialization, which shifts the responsibility for these critical functions.

GovernanceMedium6/10

The contract itself does not implement any specific economic models (7.4) beyond standard ERC-20 token transfers, nor does it include any governance mechanisms (7.5). Its economic stability relies entirely on the design of the derived contract that utilizes it and the broader ecosystem. There are no inherent economic or governance risks within this base contract.

UpgradesLow10/10

The FourERC20 contract is not designed with explicit upgradeability features (7.7) such as proxy patterns. If this contract were to be used as an implementation in an upgradeable proxy system, careful consideration would be needed regarding the `_init` function to prevent re-initialization issues. As a standalone contract, upgradeability is not a direct concern.

Security Checklist

5/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

Holder Composition

81.8% in top 10

81.8% in wallets0.0% in contracts

Effective Concentration81.8%

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

$8.26M across 15 pairs

Pancakeswap v2WBNBanalysed$7.91M Pancakeswap v3USDT$147.4K UniswapUSDT$130.4K Pancakeswap v3WBNB$58.9K Pancakeswap v3WBNB$12.1K Pancakeswap v3USDT$2.2K

Show 4 more pairsShow less

UniswapUSDT$660 Uniswap比特币$284 UniswapWBNB$230 Pancakeswap v2USDT$167

The 5 remaining pairs hold $90 between them and are not listed.

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%

Key Addresses

10 addresses

Deployer

0x8463…6533

Unlocked LP Held By

0x7ab1…46580xfe91…f0f10x82ed…93540x23d2…e81d0x83e8…5eff0x59b1…d6220x5520…f1e80xe7fb…4a340xc368…e2d7

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

What Raised This Score

2 factors

Top-10 concentration > 70% (81.8% total → 81.8% effective; 81.8% in EOAs, 0.0% in contracts — extreme)
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

Not Signed In

Is 币安人生 Safe?

Security Findings

Reliance on Derived Contracts for Supply Management and Initialization

Incomplete Token Implementation (No Mint/Burn Mechanism or Public Constructor)

Standard ERC-20 `approve` Race Condition

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 币安人生?