Is 孙小圣 a Scam? New Token Security Check

Security Findings

1 High2 Med2 Low1 Info

High

Truncated `_liquidateTax` Function Logic

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

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

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

StatusUnresolved

Medium

Centralization Risk with Owner Privileges

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

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

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

StatusUnresolved

Medium

Time-Based State Transitions and Potential for Manipulation

M-02The `_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).

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

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

StatusUnresolved

Low

Fixed `liqExpectedOutputAmount`

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

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

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

StatusUnresolved

Low

`uint48` and `uint64` for Expiration Times

L-02The `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).

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

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

StatusUnresolved

Info

`_liquidateTax` Called on Every Transfer

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

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

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

StatusUnresolved

Category Ratings

TechnicalLow8/10

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

GovernanceMedium5/10

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

UpgradesMedium4/10

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

Security Checklist

3/5 checks passed

Contract VerifiedPass

Ownership RenouncedPass

No Mint FunctionPass

Liquidity LockedFail

Not a ProxyFail

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Proxy Upgrade Controls

Proxy TypeEtherscan Detected Custom

ImplementationVerified source

Holder Composition

30.3% in top 10

16.8% in wallets13.5% in contracts

Effective Concentration22.2%

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

$108.8K across 5 pairs

Pancakeswap v2QQQBanalysed$108.7K Pancakeswap v3USDT$69 Pancakeswap v2WBNB$30 Uniswap v2USDT$1 Uniswap v2WBNB$0

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 Holder93.1%

Top-3 Unlocked100.0%

Key Addresses

4 addresses

Deployer

0xd190…db9b

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.

What Raised This Score

10 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

Is 孙小圣 a Scam?

Security Findings

Truncated `_liquidateTax` Function Logic

Centralization Risk with Owner Privileges

Time-Based State Transitions and Potential for Manipulation

Fixed `liqExpectedOutputAmount`

`uint48` and `uint64` for Expiration Times

`_liquidateTax` Called on Every Transfer

Category Ratings

Security Checklist

Proxy Upgrade Controls

Holder Composition

Liquidity Depth

LP Distribution

Key Addresses

What Raised This Score

Related Audits

Would You Like a More Detailed Audit of 孙小圣?