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

Is 孙小圣 a Scam?

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 recordNew Launch · 5d old

Chart

60/ 100

Medium RiskHow is this score calculated?

How the score breaks downratings: 10 is safest

Technical8/10 Governance5/10 Upgrades4/10 Checks passed4 of 7 Findings1 High · 2 Medium · 2 Low · 1 Info6

SummaryAI Copilot

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a complex, multi-state tax mechanism.

Read the full analysis

What raised the score

Proxy contract
Non-standard proxy storage
Top-10 concentration > 20%
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 93.1%
LP top3 unlocked holders = 100.0%
Token age < 7 days
1 High finding(s) from audit
2 Medium finding(s) from audit
2 Low finding(s) from audit

Exact factors

Proxy contract (upgradeable — admin can replace logic)
Non-standard proxy storage (Etherscan-confirmed)
Top-10 concentration > 20% (30.3% total → 22.2% effective; 16.8% in EOAs, 13.5% in contracts — mild)
Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 93.1% (independent LP — depth risk)
LP top3 unlocked holders = 100.0% (independent LP — depth risk)
Token age < 7 days (early, volatile)
1 High finding(s) from audit
2 Medium finding(s) from audit
2 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

Early-stage analysis. This token has limited on-chain history (5d old). New tokens carry elevated risk — data may change rapidly. Always verify independently before investing.

Security Checklist

as of audit · Sep 44 of 7 checks passed

Contract verifiedVerified

OwnershipRenounced

MintNo mint

Liquidity lockNot locked

UpgradeabilityUpgradeable

HoneypotNone found

Buy / sell tax2% / 2%

Holders

as of audit · Sep 4, 2026

ContractsWalletsEveryone elseBubble area = share of supply

30.3%of supply sits with the top 10 holders

Contractstreasury, vesting, bridge, staking13.5%
Walletsanonymous holders, free to sell16.8%
Everyone elsethe rest of the supply69.7%

Effective concentrationwhat the score reads22.2%

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$108.8K across 5 pairs

The risk score reads depth across every pair.

LP tokensNot locked

The LP tokens of the analysed pool are not locked or burned, so whoever holds them can withdraw that liquidity.

Analysed pool$108.7KShare of depth99.9%

Top-1 Unlocked Holder93.1%

Top-3 Unlocked100.0%

Unlocked LP held by

0x0b98…91310x5810…8eaf0x7b30…6412

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

Security Findings

1 High2 Medium2 Low1 Info

High

Truncated `_liquidateTax` Function Logic

The provided source code for the _liquidateTax function is incomplete. This function contains critical logic for state transitions, tax processing, and potentially external calls to ITaxProcessor. Without the full code, a comprehensive security assessment of this core mechanism, including potential reentrancy vulnerabilities, gas consumption, and correct handling of tax funds, is impossible.H-01

Issue

Fix

Provide the complete and verified source code for the _liquidateTax function to allow for a full security audit. Pay particular attention to external calls within this function and implement reentrancy guards if necessary.

Status

Unresolved

Medium

Centralization Risk with Owner Privileges

The startMigration and finalizeMigration functions, which control critical PoolState transitions, are restricted to onlyOwner. This grants significant power to a single address. A compromised owner key or a malicious owner could lead to unauthorized and disruptive state changes, potentially impacting the token's economic model and user trust (7.3 Access Control, 7.5 Governance).M-01

Issue

Fix

Consider implementing a multi-signature wallet (e.g., Gnosis Safe) for the owner address to require multiple approvals for critical operations. Alternatively, explore a time-locked governance mechanism for highly sensitive state changes to provide a window for community review and reaction.

Status

Unresolved

Medium

Time-Based State Transitions and Potential for Manipulation

The _liquidateTax function triggers PoolState changes (e.g., to TaxFree or TaxEnforced) based on block.timestamp exceeding taxExpirationTime or antiFarmerExpirationTime. While block.timestamp is generally reliable, miners have a limited ability to manipulate it within a certain range (up to 900 seconds deviation from median). This could allow for minor manipulation of when state transitions occur, potentially impacting users who are sensitive to tax rate changes (7.2 Code Security).M-02

Issue

Fix

While this is a common pattern, be aware of the inherent limitations of block.timestamp. For highly critical, time-sensitive events, consider using a decentralized oracle for time if precise, unmanipulable timing is paramount, or implement a grace period around state transitions.

Status

Unresolved

Low

Fixed `liqExpectedOutputAmount`

The liqExpectedOutputAmount is set only once during initialization and is immutable thereafter. In a dynamic market, a fixed expected output amount for tax liquidation might become suboptimal or even detrimental over time, potentially leading to inefficient tax processing or missed opportunities for the protocol (7.4 Economic).L-01

Issue

Fix

Consider making liqExpectedOutputAmount a configurable parameter, allowing the owner or a governance mechanism to update it as market conditions evolve. This would provide greater flexibility and optimize the tax processing mechanism.

Status

Unresolved

Low

`uint48` and `uint64` for Expiration Times

The antiFarmerExpirationTime is stored as uint48 and taxExpirationTime as uint64. While block.timestamp is currently well within these limits, using smaller types for time-related variables that store block.timestamp values introduces a theoretical, albeit distant, risk of overflow/truncation in the very long term (e.g., uint48 overflows in ~8900 years, uint64 in ~580 billion years). It's generally safer to use uint256 for block.timestamp values unless gas savings are critical and the lifespan of the contract is well-understood (7.2 Code Security).L-02

Issue

Fix

For maximum future-proofing, consider using uint256 for time-related variables that store block.timestamp values. If gas optimization is a primary concern, ensure the expected lifespan of the contract is well within the limits of uint48 and uint64.

Status

Unresolved

Info

`_liquidateTax` Called on Every Transfer

The _liquidateTax function is called on every _transfer operation. While this ensures timely state updates and tax processing, if the logic within _liquidateTax becomes complex or involves multiple external calls (as hinted by the truncation), it could lead to increased gas costs for every token transfer, potentially impacting user experience or transaction throughput (7.8 Operations).I-01

Issue

Fix

Monitor the gas consumption of _liquidateTax once the full implementation is available. Optimize its logic to minimize gas costs, especially if it involves external calls. Consider if there are scenarios where liquidation can be batched or triggered less frequently without compromising the protocol's economic model.

Status

Unresolved

Analysis

AI Copilotas of audit · Sep 4

Executive SummaryWhat the contract is and what the review found

The FlapTaxTokenV3 contract implements an upgradeable ERC20 token with a complex, multi-state tax mechanism. The contract utilizes OpenZeppelin's upgradeable standards and SafeERC20 for secure token interactions. A significant portion of the core tax liquidation logic in _liquidateTax was truncated in the provided source, preventing a full security assessment of this critical component. Identified issues include centralization risks, potential time-based manipulation, and minor economic inflexibilities.

Technical8/10Low risk

The contract leverages OpenZeppelin's upgradeable ERC20, Ownable, and Permit standards, ensuring a robust foundation (7.1 Architecture, 7.2 Code Security). The use of SafeERC20 for external token interactions is a strong security practice. However, the provided source code for the critical _liquidateTax function is truncated, preventing a complete assessment of its security and potential reentrancy vectors (7.2 Code Security). Time-based state transitions in _liquidateTax introduce a minor risk of manipulation (7.2 Code Security).

Governance5/10Medium risk

The contract defines immutable liquidation thresholds and a constant maxSupply, contributing to economic stability (7.4 Economic). The initialize function includes important sanity checks for parameters. However, the owner possesses significant control over critical PoolState transitions via startMigration and finalizeMigration, introducing centralization risk (7.3 Access Control, 7.5 Governance). The liqExpectedOutputAmount is fixed at initialization, which might become economically suboptimal over time (7.4 Economic).

Upgrades4/10Medium risk

The contract is built on OpenZeppelin's upgradeable patterns, correctly using Initializable and _disableInitializers() in the constructor, which is a strong practice for upgrade safety (7.7 Upgrades). The initializer modifier is correctly applied. The use of a PackedPoolState struct requires careful consideration for future upgrades to avoid storage collisions if fields are reordered or new fields are inserted mid-struct (7.7 Upgrades).

Final RecommendationWhat to do about this score

A complete and verified source code for the _liquidateTax function is essential for a thorough security assessment.

Without it, critical vulnerabilities related to reentrancy, external calls, and complex state transitions cannot be fully evaluated. It is recommended to reduce owner privileges where possible or implement a multi-signature wallet for critical administrative functions to mitigate centralization risks. Consider making liqExpectedOutputAmount configurable by governance to adapt to changing market conditions.

Contract & Record

1 audit on record

TypeFlapTaxTokenV3

NetworkBNB Chain

Token age5d

Contract0x0185…7777

Deployer0xd190…db9b

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Badge for your website

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

Sep 4, 202660Medium
Sep 3, 202641Medium

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

Frequently Asked Questions

What is the 孙小圣 contract address?

The 孙小圣 contract on BNB Chain is 0x01856bda968ddca3ae5f866a4e07405480967777. Compare it with the address the project itself publishes before trading: other contracts can carry the same name and ticker.