Is 孙小圣 a Scam? New Token Security Check

Security Findings

1 Crit1 High1 Med2 Low1 Info

Critical

Incomplete Code Provided for Audit

C-01The provided source code for the `_liquidateTax` function is truncated, specifically the condition `taxAmount >= currentPoolState.liqu...`. This function is critical as it handles state transitions, tax processing, and potentially external calls (e.g., to `taxProcessor` or `dividendContract`). Without the complete code, it is impossible to fully assess the security and economic implications of the tax liquidation mechanism, including potential reentrancy, denial-of-service, or incorrect handling of accumulated funds. (7.2 Code Security, 7.4 Economic)

IssueThe provided source code for the `_liquidateTax` function is truncated, specifically the condition `taxAmount >= currentPoolState.liqu...`. This function is critical as it handles state transitions, tax processing, and potentially external calls (e.g., to `taxProcessor` or `dividendContract`). Without the complete code, it is impossible to fully assess the security and economic implications of the tax liquidation mechanism, including potential reentrancy, denial-of-service, or incorrect handling of accumulated funds. (7.2 Code Security, 7.4 Economic)

FixProvide the complete and verified source code for the `_liquidateTax` function and any other truncated sections to allow for a comprehensive security review.

StatusUnresolved

High

Centralized Control by Owner

H-01The contract relies heavily on `OwnableUpgradeable` for critical operations. The owner has exclusive control over initiating and finalizing migration states (`startMigration`, `finalizeMigration`), which directly impacts the token's tax mechanisms and transfer rules. The owner also minted the entire `maxSupply` during initialization. This high degree of centralization introduces a single point of failure and trust, as a compromised owner key could lead to significant economic manipulation or a rug pull scenario. (7.3 Access Control, 7.5 Governance)

IssueThe contract relies heavily on `OwnableUpgradeable` for critical operations. The owner has exclusive control over initiating and finalizing migration states (`startMigration`, `finalizeMigration`), which directly impacts the token's tax mechanisms and transfer rules. The owner also minted the entire `maxSupply` during initialization. This high degree of centralization introduces a single point of failure and trust, as a compromised owner key could lead to significant economic manipulation or a rug pull scenario. (7.3 Access Control, 7.5 Governance)

FixConsider implementing a multi-signature wallet for ownership or transitioning to a decentralized governance model (e.g., DAO) for critical functions to reduce the risk associated with a single point of control.

StatusUnresolved

Medium

Unused or Truncated External Dependencies and Variables

M-01Several imported interfaces (`ITaxProcessor`, `IDividend`) and state variables (`liqExpectedOutputAmount`, `initialLiquidationThreshold`, `metaURI`, `dividendContract`, `taxProcessor`) are initialized but not used within the provided code snippet. While some usage might be in the truncated `_liquidateTax` function, their absence in the visible logic suggests either dead code, incomplete implementation, or critical functionality being hidden. This makes it difficult to understand the full system's behavior and potential external interaction risks. (7.1 Architecture, 7.6 External)

IssueSeveral imported interfaces (`ITaxProcessor`, `IDividend`) and state variables (`liqExpectedOutputAmount`, `initialLiquidationThreshold`, `metaURI`, `dividendContract`, `taxProcessor`) are initialized but not used within the provided code snippet. While some usage might be in the truncated `_liquidateTax` function, their absence in the visible logic suggests either dead code, incomplete implementation, or critical functionality being hidden. This makes it difficult to understand the full system's behavior and potential external interaction risks. (7.1 Architecture, 7.6 External)

FixEnsure all declared variables and imported interfaces are actively used and their interactions are fully implemented and visible. If they are intended for future use, document their purpose clearly. If they are dead code, remove them to improve clarity and reduce attack surface.

StatusUnresolved

Low

Potential Truncation Risk for `antiFarmerExpirationTime`

L-01The `antiFarmerExpirationTime` variable is declared as `uint48`. While `uint48` provides a large enough range for typical `block.timestamp` values and `antiFarmerDuration` (up to approximately 2.78 million years), there is a theoretical risk of truncation if `block.timestamp + antiFarmerDuration` were to exceed `2^48 - 1`. Although highly improbable in practical scenarios, using a larger type like `uint64` for time-related variables is generally safer and more robust against extreme or long-term values. (7.2 Code Security)

IssueThe `antiFarmerExpirationTime` variable is declared as `uint48`. While `uint48` provides a large enough range for typical `block.timestamp` values and `antiFarmerDuration` (up to approximately 2.78 million years), there is a theoretical risk of truncation if `block.timestamp + antiFarmerDuration` were to exceed `2^48 - 1`. Although highly improbable in practical scenarios, using a larger type like `uint64` for time-related variables is generally safer and more robust against extreme or long-term values. (7.2 Code Security)

FixConsider using `uint64` for `antiFarmerExpirationTime` to align with `taxExpirationTime` and eliminate any theoretical truncation risk, even if practically negligible.

StatusUnresolved

Low

Ambiguity in Pool Tax Application Logic

L-02The `_getTaxWithPoolState` function applies tax logic differently based on the `PoolState`. In `PoolState.TaxEnforcedAntiFarmer`, it checks `pools[from]` or `pools[to]`, applying tax if either address is a configured pool. In `PoolState.TaxEnforced`, it specifically checks `from == mainPool` or `to == mainPool`. This distinction, while potentially intentional, could lead to confusion or unintended tax application if the `mainPool` is not the only address intended to be taxed in the `TaxEnforced` state, or if the `pools` mapping is not managed carefully. (7.1 Architecture, 7.4 Economic)

IssueThe `_getTaxWithPoolState` function applies tax logic differently based on the `PoolState`. In `PoolState.TaxEnforcedAntiFarmer`, it checks `pools[from]` or `pools[to]`, applying tax if either address is a configured pool. In `PoolState.TaxEnforced`, it specifically checks `from == mainPool` or `to == mainPool`. This distinction, while potentially intentional, could lead to confusion or unintended tax application if the `mainPool` is not the only address intended to be taxed in the `TaxEnforced` state, or if the `pools` mapping is not managed carefully. (7.1 Architecture, 7.4 Economic)

FixClearly document the intended behavior and rationale behind the differing tax application logic for `PoolState.TaxEnforcedAntiFarmer` and `PoolState.TaxEnforced`. Ensure that the `pools` mapping and `mainPool` variable are managed consistently with these rules.

StatusUnresolved

Info

Packed Storage for `PackedPoolState`

I-01The `PackedPoolState` struct uses packed storage (`uint8`, `uint16`, `uint16`, `bool`, `uint96`, `uint64`, `uint48`) to optimize gas costs by fitting multiple variables into a single storage slot. While efficient, this design requires careful consideration for future upgrades. Any change in the order or size of these variables in a subsequent implementation could lead to storage collisions and data corruption if not handled meticulously, potentially breaking the contract's state. (7.7 Upgrades)

IssueThe `PackedPoolState` struct uses packed storage (`uint8`, `uint16`, `uint16`, `bool`, `uint96`, `uint64`, `uint48`) to optimize gas costs by fitting multiple variables into a single storage slot. While efficient, this design requires careful consideration for future upgrades. Any change in the order or size of these variables in a subsequent implementation could lead to storage collisions and data corruption if not handled meticulously, potentially breaking the contract's state. (7.7 Upgrades)

FixWhen upgrading the contract, ensure that the `PackedPoolState` struct's layout remains identical or that any changes are managed with extreme care to prevent storage collisions. Thorough testing of upgrade scenarios is crucial.

StatusUnresolved

Category Ratings

TechnicalLow7/10

The contract implements an upgradeable ERC20 token with a complex state machine for tax enforcement and migration. It leverages OpenZeppelin's battle-tested upgradeable contracts, ensuring a solid foundation (7.1 Architecture). The tax calculation logic (`_getTaxWithPoolState`) is well-structured, preventing common arithmetic errors. However, a critical portion of the `_liquidateTax` function is truncated, preventing a full security assessment of the core tax processing and fund management (7.2 Code Security). Additionally, some initialized variables and imported interfaces appear unused in the visible code, suggesting potential incompleteness or dead code.

GovernanceMedium5/10

The economic model incorporates dynamic buy/sell taxes and an anti-farmer mechanism, managed through distinct pool states. The tax rates are applied using a standard basis point calculation, mitigating precision issues (7.4 Economic). However, the contract exhibits a high degree of centralization, with the `OwnableUpgradeable` role controlling critical state transitions and holding the entire token supply initially (7.5 Governance). This introduces significant trust assumptions and a single point of failure. The full economic implications of tax liquidation cannot be assessed due to truncated code.

UpgradesLow8/10

The contract is designed as an upgradeable proxy using OpenZeppelin's `Initializable` pattern, correctly disabling initializers in the constructor and using the `initializer` modifier (7.7 Upgrades). This allows for future enhancements and bug fixes. The `PackedPoolState` struct utilizes packed storage for gas efficiency, which is a positive. However, this packing requires meticulous attention during future upgrades to prevent storage collisions and data corruption if the struct's layout is altered.

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

53.6% in top 10

29.6% in wallets24.0% in contracts

Effective Concentration39.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

$47.9K across 2 pairs

Pancakeswap v2WBNBanalysed$47.8K Uniswap v2USDT$132

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

1 addresses

Deployer

0x1afc…2b84

What Raised This Score

7 factors

Top-10 concentration > 30% (53.6% total → 39.2% effective; 29.6% in EOAs, 24.0% in contracts — moderate)
Liquidity < $50k ($47,928 across 2 pairs — thin market)
Token age < 7 days (early, volatile)
1 Critical finding(s) from audit
1 High finding(s) from audit
1 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

Incomplete Code Provided for Audit

Centralized Control by Owner

Unused or Truncated External Dependencies and Variables

Potential Truncation Risk for `antiFarmerExpirationTime`

Ambiguity in Pool Tax Application Logic

Packed Storage for `PackedPoolState`

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 孙小圣?