Is Stonks Safe? Smart Contract Security Analysis

Security Findings

1 High2 Med1 Low1 Info

High

Incomplete Liquidation Logic in `_liquidateTax`

H-01The `_liquidateTax` function, which is called on every transfer to the `mainPool` and is responsible for critical state transitions and potential tax liquidation, is truncated in the provided source code. The incomplete condition `taxAmount >= currentPoolState.liqu...` prevents a full assessment of the liquidation mechanism, its triggers, and its economic implications. This poses a significant risk as the core logic governing tax handling and state changes cannot be fully audited for vulnerabilities such as reentrancy, economic exploits, or denial of service.

IssueThe `_liquidateTax` function, which is called on every transfer to the `mainPool` and is responsible for critical state transitions and potential tax liquidation, is truncated in the provided source code. The incomplete condition `taxAmount >= currentPoolState.liqu...` prevents a full assessment of the liquidation mechanism, its triggers, and its economic implications. This poses a significant risk as the core logic governing tax handling and state changes cannot be fully audited for vulnerabilities such as reentrancy, economic exploits, or denial of service.

FixProvide the complete and verified source code for the `_liquidateTax` function. A full audit of this critical component is necessary to ensure the contract's security and economic stability. Without the full code, the system's behavior under various conditions, especially during liquidation, remains unknown and potentially exploitable.

StatusUnresolved

Medium

Centralized Control over Key State Transitions

M-01The `startMigration` and `finalizeMigration` functions are restricted to the `onlyOwner`. These functions control significant changes in the token's operational `PoolState` (e.g., from `BondingCurve` to `Migrating`, and then to `TaxEnforcedAntiFarmer`). This centralized control means a single compromised owner key or a malicious owner could unilaterally alter the token's tax structure and operational phase, potentially leading to unexpected economic consequences or user distrust (7.3 Access Control, 7.5 Governance).

IssueThe `startMigration` and `finalizeMigration` functions are restricted to the `onlyOwner`. These functions control significant changes in the token's operational `PoolState` (e.g., from `BondingCurve` to `Migrating`, and then to `TaxEnforcedAntiFarmer`). This centralized control means a single compromised owner key or a malicious owner could unilaterally alter the token's tax structure and operational phase, potentially leading to unexpected economic consequences or user distrust (7.3 Access Control, 7.5 Governance).

FixConsider implementing a multi-signature wallet for the owner address or introducing a time-locked governance mechanism for critical state transitions. This would add an extra layer of security and decentralization, reducing the risk associated with a single point of control.

StatusUnresolved

Medium

Potential Reentrancy in `_liquidateTax` (Unconfirmed due to truncation)

M-02The `_liquidateTax` function is called within `_transfer`, and its full implementation is truncated. If the complete logic involves external calls (e.g., to `ITaxProcessor` or `IDividend` for processing taxes or dividends) and modifies state before or after these calls without proper reentrancy guards (like Checks-Effects-Interactions pattern or reentrancy locks), it could be vulnerable to reentrancy attacks. An attacker could repeatedly call `_transfer` while the contract is in an inconsistent state, leading to unintended behavior or loss of funds (7.2 Code Security).

IssueThe `_liquidateTax` function is called within `_transfer`, and its full implementation is truncated. If the complete logic involves external calls (e.g., to `ITaxProcessor` or `IDividend` for processing taxes or dividends) and modifies state before or after these calls without proper reentrancy guards (like Checks-Effects-Interactions pattern or reentrancy locks), it could be vulnerable to reentrancy attacks. An attacker could repeatedly call `_transfer` while the contract is in an inconsistent state, leading to unintended behavior or loss of funds (7.2 Code Security).

FixOnce the full `_liquidateTax` source code is available, thoroughly review it for any external calls. Ensure that all state changes occur before any external calls are made (Checks-Effects-Interactions pattern) and consider using a reentrancy guard if multiple external calls or complex interactions are necessary.

StatusUnresolved

Low

Reliance on `block.timestamp` for Critical State Transitions

L-01The `_liquidateTax` function uses `block.timestamp` to determine `PoolState` transitions, specifically for `taxExpirationTime` and `antiFarmerExpirationTime`. While common, `block.timestamp` can be manipulated by miners within a certain range (up to 900 seconds on Ethereum, similar on BSC). This could allow a miner or a sophisticated attacker to slightly front-run or delay state changes, potentially gaining a minor advantage or causing a slight disruption to the intended timing of tax-related events (7.2 Code Security).

IssueThe `_liquidateTax` function uses `block.timestamp` to determine `PoolState` transitions, specifically for `taxExpirationTime` and `antiFarmerExpirationTime`. While common, `block.timestamp` can be manipulated by miners within a certain range (up to 900 seconds on Ethereum, similar on BSC). This could allow a miner or a sophisticated attacker to slightly front-run or delay state changes, potentially gaining a minor advantage or causing a slight disruption to the intended timing of tax-related events (7.2 Code Security).

FixFor time-sensitive operations where precise timing is critical, consider using a more robust time oracle or a time-averaged block number if the exact second is not paramount. If `block.timestamp` is deemed acceptable for the current use case, acknowledge the inherent miner manipulability and ensure the system's economics are resilient to minor time shifts.

StatusUnresolved

Info

Complex State Machine

I-01The contract implements a multi-state `PoolState` machine (BondingCurve, Migrating, TaxEnforcedAntiFarmer, TaxEnforced, TaxFree) with transitions managed by `onlyOwner` functions and the `_liquidateTax` function. While providing flexibility, this complexity increases the surface area for logical errors, makes the system harder to reason about, and can complicate future upgrades or maintenance (7.1 Architecture).

IssueThe contract implements a multi-state `PoolState` machine (BondingCurve, Migrating, TaxEnforcedAntiFarmer, TaxEnforced, TaxFree) with transitions managed by `onlyOwner` functions and the `_liquidateTax` function. While providing flexibility, this complexity increases the surface area for logical errors, makes the system harder to reason about, and can complicate future upgrades or maintenance (7.1 Architecture).

FixEnsure comprehensive unit and integration tests cover all possible state transitions and edge cases. Maintain clear documentation of the state machine's logic, including transition conditions and effects, to aid in future development and security reviews.

StatusUnresolved

Category Ratings

TechnicalLow9/10

The contract utilizes OpenZeppelin's upgradeable ERC20 standards, enhancing code security and modularity (7.2 Code Security). The `PackedPoolState` struct demonstrates an effort towards gas efficiency (7.1 Architecture). However, the critical `_liquidateTax` function is truncated, making it impossible to fully assess potential reentrancy vulnerabilities or other logical flaws within the tax liquidation process (7.2 Code Security). The complex multi-state machine (BondingCurve, Migrating, TaxEnforcedAntiFarmer, TaxEnforced, TaxFree) increases the attack surface for logical errors (7.1 Architecture).

GovernanceLow7/10

The contract's economic model is centered around a dynamic tax mechanism and a multi-state system, designed to manage token liquidity and anti-farmer measures (7.4 Economic). Key state transitions, such as `startMigration` and `finalizeMigration`, are controlled by the contract owner, introducing a degree of centralization (7.3 Access Control, 7.5 Governance). The truncation of the `_liquidateTax` function significantly hinders the ability to evaluate the full economic implications and potential risks associated with the liquidation threshold and tax processing (7.4 Economic).

UpgradesLow9/10

The contract correctly implements the UUPS proxy pattern using OpenZeppelin's upgradeable contracts, including `Initializable` and `_disableInitializers()` in the constructor, which is a strong practice for upgrade safety (7.7 Upgrades). This design allows for future enhancements and bug fixes. However, careful management of storage layout, especially with the `PackedPoolState` struct, is crucial during subsequent upgrades to prevent storage collisions (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

21.2% in top 10

8.5% in wallets12.7% in contracts

Effective Concentration13.5%

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

$219.9K across 5 pairs

Pancakeswap v2QQQBanalysed$184.3K Pancakeswap v3USDT$35.5K Pancakeswap v2USDT$10 Uniswap v2USDT$0 Pancakeswap 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 Holder56.6%

Top-3 Unlocked70.9%

Key Addresses

11 addresses

Deployer

0x0f93…abb3

Unlocked LP Held By

0x6b0c…c6fb0x71a0…4e0b0x543a…a80a0xf92f…4a700x80b3…4a590xddec…cb520x8d43…865f0xef7c…22c20x26b3…c34c0xacd8…6549

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

What Raised This Score

6 factors

Liquidity not locked, but no owner/deployer address holds LP — market-depth risk, not rug risk
LP top1 unlocked holder = 56.6% (independent LP — depth risk, pool = 84% of DEX liquidity)
Token age < 30 days (still settling)
1 High finding(s) from audit
2 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

Not Signed In

Is Stonks Safe?

Security Findings

Incomplete Liquidation Logic in `_liquidateTax`

Centralized Control over Key State Transitions

Potential Reentrancy in `_liquidateTax` (Unconfirmed due to truncation)

Reliance on `block.timestamp` for Critical State Transitions

Complex State Machine

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 Stonks?