Quantum Audit Logo

Is 人生好物 a Scam?

Early-stage security check — honeypot & rug-pull analysis

Is this your token? Publish your own audit on this page →

人生好物 人生好物
0x1e3e…7777
BNB Chain
Not verifiedThis 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 today 1 audit on record New Launch · 1h old
DexScreener ↗
How is this score calculated? → High Risk
Executive SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a complex state-based tax mechanism. A critical portion of the contract's core economic logic, the `_liquidateTax` function, was truncated in the provided source code. This prevents a full security assessment of the tax collection, liquidation, and state transition processes, introducing significant unquantifiable risk. Other findings include potential reentrancy, centralization risks, and minor precision loss in tax calculations.

1 Critical1 High1 Medium1 Low1 Informational
! Early-stage analysis. This token has limited on-chain history (1h old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.
Volume 24h
$205.4K
Liquidity
$46.2K
Price
$0.0002564
Token Age
1h
Top 10 Holders
20.4%

Security Findings

1 Crit1 High1 Med1 Low1 Info
Critical

Critical Logic Unauditable Due to Truncation

C-01The provided source code for the `_liquidateTax` function is truncated. This function is critical for the contract's economic model, handling tax collection, liquidation, and state transitions. Without the full code, a comprehensive security assessment of this core functionality is impossible, leaving a significant unknown risk (7.2 Code Security, 7.4 Economic).
IssueThe provided source code for the `_liquidateTax` function is truncated. This function is critical for the contract's economic model, handling tax collection, liquidation, and state transitions. Without the full code, a comprehensive security assessment of this core functionality is impossible, leaving a significant unknown risk (7.2 Code Security, 7.4 Economic).
FixProvide the complete and untruncated source code for the `_liquidateTax` function to enable a full security audit. Until the complete code is available, the contract's core economic security cannot be fully guaranteed.
StatusUnresolved
High

Potential Reentrancy in `_liquidateTax`

H-01The `_liquidateTax` function is called on every transfer to `mainPool`. If the full, truncated implementation of `_liquidateTax` makes external calls (e.g., to `taxProcessor` or `dividendContract`) before updating internal state or handling collected taxes, it could be vulnerable to reentrancy attacks. An attacker could re-enter the contract during an external call, potentially manipulating balances or state before the initial transaction completes (7.2 Code Security, 7.6 External).
IssueThe `_liquidateTax` function is called on every transfer to `mainPool`. If the full, truncated implementation of `_liquidateTax` makes external calls (e.g., to `taxProcessor` or `dividendContract`) before updating internal state or handling collected taxes, it could be vulnerable to reentrancy attacks. An attacker could re-enter the contract during an external call, potentially manipulating balances or state before the initial transaction completes (7.2 Code Security, 7.6 External).
FixImplement the 'checks-effects-interactions' pattern within the `_liquidateTax` function. Ensure all state changes related to tax collection and liquidation are completed before any external calls are made. Consider using OpenZeppelin's `ReentrancyGuard` if complex external interactions are unavoidable.
StatusUnresolved
Medium

Centralization Risk with Owner Privileges

M-01The `OwnableUpgradeable` contract grants significant control to the owner, including the ability to `startMigration` and `finalizeMigration`, which directly changes the `PoolState`. This centralization of control means a compromised owner key or a malicious owner could unilaterally alter the contract's operational state, potentially impacting tokenomics and user funds (7.3 Access Control, 7.5 Governance, 7.8 Operations).
IssueThe `OwnableUpgradeable` contract grants significant control to the owner, including the ability to `startMigration` and `finalizeMigration`, which directly changes the `PoolState`. This centralization of control means a compromised owner key or a malicious owner could unilaterally alter the contract's operational state, potentially impacting tokenomics and user funds (7.3 Access Control, 7.5 Governance, 7.8 Operations).
FixConsider implementing a multi-signature wallet for ownership or critical administrative functions. Alternatively, introduce a time-lock mechanism for sensitive state-changing operations to provide a window for community review or intervention.
StatusUnresolved
Low

Precision Loss in Tax Calculation

L-01The tax calculation `(amount * rate) / 10000` uses integer division. For small `amount` values or low `rate` values, this can lead to a loss of precision, resulting in a slightly lower tax collected than a mathematically precise calculation would yield. While common in Solidity, it means the protocol might not collect the exact intended tax amount in all scenarios (7.2 Code Security, 7.4 Economic).
IssueThe tax calculation `(amount * rate) / 10000` uses integer division. For small `amount` values or low `rate` values, this can lead to a loss of precision, resulting in a slightly lower tax collected than a mathematically precise calculation would yield. While common in Solidity, it means the protocol might not collect the exact intended tax amount in all scenarios (7.2 Code Security, 7.4 Economic).
FixAcknowledge this behavior as an inherent characteristic of integer arithmetic in Solidity. For most practical purposes, the impact is negligible. If higher precision is critical for very small transactions, consider adjusting the tax rate basis (e.g., `100_000` instead of `10_000`) or implementing a more complex fixed-point arithmetic library, though this adds complexity and gas cost.
StatusUnresolved
Info

Reliance on `block.timestamp` for Expiration

I-01The contract uses `block.timestamp` to determine `taxExpirationTime` and `antiFarmerExpirationTime`. While `block.timestamp` is commonly used, miners have a limited ability to manipulate its value (typically within a few seconds of the actual time). This could potentially allow for minor front-running or delayed execution of time-sensitive state transitions (7.4 Economic).
IssueThe contract uses `block.timestamp` to determine `taxExpirationTime` and `antiFarmerExpirationTime`. While `block.timestamp` is commonly used, miners have a limited ability to manipulate its value (typically within a few seconds of the actual time). This could potentially allow for minor front-running or delayed execution of time-sensitive state transitions (7.4 Economic).
FixBe aware of the inherent limitations of `block.timestamp` for highly time-sensitive operations. For most use cases, the minor manipulation risk is acceptable. If precise, unmanipulable timing is critical, consider alternative oracle-based time sources, though this introduces external dependencies and additional complexity.
StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract implements an upgradeable ERC20 token with a complex state-based tax mechanism (7.1 Architecture). It leverages OpenZeppelin's upgradeable contracts and `SafeERC20` for secure external token interactions (7.6 External). The `PackedPoolState` struct efficiently stores critical parameters. However, the `_liquidateTax` function, which is central to the token's economic model and state transitions, is truncated in the provided source, preventing a full security assessment (7.2 Code Security). This truncation raises concerns about potential reentrancy vulnerabilities if external calls are made within this critical function (7.2 Code Security).

GovernanceHigh2/10

The contract's economic model revolves around dynamic tax rates and state transitions (7.4 Economic). Taxes are collected into the contract itself, awaiting liquidation, but the full logic for this process is unavailable due to truncation (7.4 Economic). The `OwnableUpgradeable` pattern grants the deployer significant control over critical state changes, such as `startMigration` and `finalizeMigration`, introducing a centralization risk (7.3 Access Control, 7.5 Governance). The reliance on `block.timestamp` for tax and anti-farmer expiration times introduces a minor risk of miner manipulation (7.4 Economic).

UpgradesLow8/10

The contract is designed as an upgradeable proxy using OpenZeppelin's `Initializable` pattern, indicating a UUPS proxy implementation (7.7 Upgrades). The constructor correctly calls `_disableInitializers`, and the `initialize` function handles initial setup. This standard approach generally ensures safe upgrades. However, any future upgrades must carefully manage storage layout to avoid collisions or data corruption, especially concerning the `PackedPoolState` struct (7.7 Upgrades).

Security Checklist

4/5 checks passed
Contract VerifiedPass
Ownership RenouncedPass
No Mint FunctionPass
Liquidity LockedFail
Not a ProxyPass
HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

20.4% in top 10
10.2% in wallets10.2% in contracts
Effective Concentration14.3%

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

$46.2K across 2 pairs

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

Top-1 Unlocked Holder100.0%
Top-3 Unlocked100.0%

Key Addresses

2 addresses
Deployer
0x0f2d…78b6
Unlocked LP Held By
0x2d6c…043c

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

What Raised This Score

9 factors
  • Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
  • Liquidity < $50k ($46,190 across 2 pairs — thin market)
  • LP top1 unlocked holder = 100.0% (independent LP — depth risk)
  • LP top3 unlocked holders = 100.0% (independent LP — depth risk)
  • Token age < 24h (brand new — bot activity, unproven)
  • 1 Critical finding(s) from audit
  • 1 High finding(s) from audit
  • 1 Medium 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

Related Audits

6 more on the record
o1.exchange (O)High RiskBaby Ansem (BABYANSEM)High RiskEVAAHigh RiskCRYSTAL STONESHigh RiskBubblemaps (BMT)High RiskPIZZAHigh Risk

Would You Like a More Detailed Audit of 人生好物?

This token is brand new. Run a deeper AI-powered analysis of the contract code — free and instant.

Get Detailed Audit