Is POO.MEME (POO) a Scam? New Token Security Check

Security Findings

1 High3 Med1 Low7 Info

High

Potential Denial of Service in `pushOwed` due to Unbounded Loop

H-01The `pushOwed` function iterates through `_tax.payeeCount + 1` recipients to distribute accumulated quote tokens. Each iteration involves an external call to `TaxLib.pushQuote`, which itself can perform external transfers. If the number of tax payees (`_tax.payeeCount`) is not strictly limited to a small number, this loop could consume excessive gas, causing the transaction to exceed the block gas limit and revert. This would prevent the distribution of owed funds to all payees, leading to a denial of service for fund distribution and potentially locking funds for some recipients.

IssueThe `pushOwed` function iterates through `_tax.payeeCount + 1` recipients to distribute accumulated quote tokens. Each iteration involves an external call to `TaxLib.pushQuote`, which itself can perform external transfers. If the number of tax payees (`_tax.payeeCount`) is not strictly limited to a small number, this loop could consume excessive gas, causing the transaction to exceed the block gas limit and revert. This would prevent the distribution of owed funds to all payees, leading to a denial of service for fund distribution and potentially locking funds for some recipients.

FixImplement a hard limit on the number of tax payees (`p.taxPayees.length`) during contract construction to ensure `_tax.payeeCount` remains within safe gas limits. Alternatively, refactor the `pushOwed` function to allow payees to pull their owed funds individually, or implement a pagination mechanism for distribution.

StatusUnresolved

Medium

Oracle Manipulation Risk for `_windowPrice`

M-01The `_windowPrice` function calculates a time-weighted average price (TWAP) from Uniswap V2 reserves. While TWAPs are generally more resilient than spot prices, their robustness depends on the length of the observation window (`block.timestamp - _engine.priceAt`) and the liquidity of the pair. If the price window is short or the liquidity is low, a sophisticated attacker could manipulate the TWAP with a flash loan or large capital, potentially influencing the `_swap` function's execution and leading to unfavorable swaps for the protocol, resulting in economic loss.

IssueThe `_windowPrice` function calculates a time-weighted average price (TWAP) from Uniswap V2 reserves. While TWAPs are generally more resilient than spot prices, their robustness depends on the length of the observation window (`block.timestamp - _engine.priceAt`) and the liquidity of the pair. If the price window is short or the liquidity is low, a sophisticated attacker could manipulate the TWAP with a flash loan or large capital, potentially influencing the `_swap` function's execution and leading to unfavorable swaps for the protocol, resulting in economic loss.

FixEnsure that the `_engine.priceAt` is updated with a sufficiently long interval to create a robust TWAP. Consider implementing additional safeguards such as volume checks, deviation checks, or integrating with a more robust oracle solution (e.g., Chainlink) if the economic impact of price manipulation is significant.

StatusUnresolved

Medium

Front-running Opportunities in `open()` and `process()`

M-02The `open()` function, which initializes trading parameters like `_lpSupplyMark` and `_priceCumulative`, and the `process()` function, which triggers swap-backs and distributions, are publicly callable. An attacker could front-run the `open()` transaction by performing a large swap just before it, manipulating the initial state for price calculations. Similarly, `process()` can be front-run to execute profitable swaps or distributions, allowing an attacker to gain an unfair advantage or cause the original transaction to revert if the state changes.

IssueThe `open()` function, which initializes trading parameters like `_lpSupplyMark` and `_priceCumulative`, and the `process()` function, which triggers swap-backs and distributions, are publicly callable. An attacker could front-run the `open()` transaction by performing a large swap just before it, manipulating the initial state for price calculations. Similarly, `process()` can be front-run to execute profitable swaps or distributions, allowing an attacker to gain an unfair advantage or cause the original transaction to revert if the state changes.

FixFor `open()`, consider if a commit-reveal scheme or a small, fixed delay after scheduling could mitigate manipulation of initial state. For `process()`, acknowledge the inherent front-running risk of public functions that trigger profitable actions. Ensure that the economic impact of such front-running is minimal and does not lead to significant losses for the protocol or its users.

StatusUnresolved

Medium

The market for this token

QA-MARKETLiquidity $9K (DexScreener, all pools). 24h trading volume $37K (DexScreener, all pools).

IssueLiquidity $9K (DexScreener, all pools). 24h trading volume $37K (DexScreener, all pools).

FixSize any position to the liquidity and daily volume shown — they set how much you can sell and at what price.

StatusAcknowledged

Low

High Complexity of External Module Interactions

L-01The `PooToken` contract extensively uses external modules (`_tokenModules`) for various hooks (gate, track, operate on sell/buy). While the `runOperate` function includes a `_undoes` check to prevent modules from draining liquidity, the overall complexity introduced by arbitrary external code execution increases the attack surface. A subtle bug or unexpected behavior in a module, even with the `_undoes` safeguard, could lead to unintended consequences or denial of service for specific module functionalities.

IssueThe `PooToken` contract extensively uses external modules (`_tokenModules`) for various hooks (gate, track, operate on sell/buy). While the `runOperate` function includes a `_undoes` check to prevent modules from draining liquidity, the overall complexity introduced by arbitrary external code execution increases the attack surface. A subtle bug or unexpected behavior in a module, even with the `_undoes` safeguard, could lead to unintended consequences or denial of service for specific module functionalities.

FixThoroughly audit all deployed token modules. Implement strict validation and whitelisting for module addresses. Consider adding circuit breakers or pause mechanisms for individual modules if a vulnerability is discovered post-deployment to limit potential damage.

StatusUnresolved

Info

Use of Non-Standard `transient` Keyword

I-01The contract uses `bool private transient _inTransfer;` and similar declarations. The `transient` keyword is not a standard Solidity keyword and is treated as a comment by the compiler. While the variables are correctly declared as `private` and function as expected (not stored in state), this non-standard notation could be confusing for developers unfamiliar with this specific convention.

IssueThe contract uses `bool private transient _inTransfer;` and similar declarations. The `transient` keyword is not a standard Solidity keyword and is treated as a comment by the compiler. While the variables are correctly declared as `private` and function as expected (not stored in state), this non-standard notation could be confusing for developers unfamiliar with this specific convention.

FixRemove the `transient` keyword or replace it with a standard comment (e.g., `// transient`) to improve code clarity and adherence to Solidity best practices.

StatusUnresolved

Info

Unused Compile-Time Assertion Function

I-02The function `_assertTokenModulesFitRunsDueWidth(uint8[8 - TOKEN_MODULE_LIMIT] memory)` is a clever pattern for a compile-time assertion. However, it is declared `private pure` and is never called within the contract. While this pattern often works by causing a compilation error if the condition is not met, explicitly calling it (even in a dummy way) or ensuring the compiler's behavior is understood for unused functions would guarantee the check is always enforced.

IssueThe function `_assertTokenModulesFitRunsDueWidth(uint8[8 - TOKEN_MODULE_LIMIT] memory)` is a clever pattern for a compile-time assertion. However, it is declared `private pure` and is never called within the contract. While this pattern often works by causing a compilation error if the condition is not met, explicitly calling it (even in a dummy way) or ensuring the compiler's behavior is understood for unused functions would guarantee the check is always enforced.

FixVerify that the compiler enforces this compile-time check even if the function is unused. If not, consider calling this function in the constructor or another appropriate place to ensure the assertion is always active. Alternatively, if its purpose is purely documentation, clarify this intent.

StatusUnresolved

Info

Who holds the supply

QA-HOLDERSThe ten largest holders own 82.4% of supply. Of that, 30.0% burned, 8.0% locked, 25.6% in DEX pools — not holders that can sell, so excluded from the concentration score. What remains: 4.3% in wallets, 14.5% in other contracts. 2,161 holders in total.

IssueThe ten largest holders own 82.4% of supply. Of that, 30.0% burned, 8.0% locked, 25.6% in DEX pools — not holders that can sell, so excluded from the concentration score. What remains: 4.3% in wallets, 14.5% in other contracts. 2,161 holders in total.

FixWatch the largest wallets that are not exchanges, pools or locks — those are the ones that can move the price.

StatusAcknowledged

Info

Not listed by any independent source

QA-IDENTITY2,161 holders. Not listed by CoinGecko or any exchange GoPlus tracks. Nothing independent confirms who is behind this token, so every power its contract grants is scored at face value.

Issue2,161 holders. Not listed by CoinGecko or any exchange GoPlus tracks. Nothing independent confirms who is behind this token, so every power its contract grants is scored at face value.

FixMatch the contract address against the project's official channels before trading.

StatusAcknowledged

Info

Liquidity time-locked

QA-LIQUIDITY100.0% of the pool's LP is burned or time-locked. 100.0% is locked in PinkLock02 until 27 Mar 2027 (179 days). Until then nobody — the project included — can withdraw it unless the locker contract itself is flawed; after that date the lock's owner can.

Issue100.0% of the pool's LP is burned or time-locked. 100.0% is locked in PinkLock02 until 27 Mar 2027 (179 days). Until then nobody — the project included — can withdraw it unless the locker contract itself is flawed; after that date the lock's owner can.

FixCheck the lock's end date and beneficiary on the locker's own page before relying on it.

StatusAcknowledged

Info

Asset class: Meme token

QA-PROFILEA community token whose value comes from attention rather than a product. Being a meme is not a risk in itself: it is scored on exactly the same contract and market facts as any other token. The class itself adds no points; the contract and market facts decide the score. Basis: meme vocabulary in name/ticker (meme). Tokenomics — Supply: fixed — the contract has no mint function. Control: an owner that could not be resolved. Code: not upgradeable (no proxy). Fees: no buy or sell tax. Market: $9K of DEX liquidity across 1 pools. Launch: 1 days of market history.

IssueA community token whose value comes from attention rather than a product. Being a meme is not a risk in itself: it is scored on exactly the same contract and market facts as any other token. The class itself adds no points; the contract and market facts decide the score. Basis: meme vocabulary in name/ticker (meme). Tokenomics — Supply: fixed — the contract has no mint function. Control: an owner that could not be resolved. Code: not upgradeable (no proxy). Fees: no buy or sell tax. Market: $9K of DEX liquidity across 1 pools. Launch: 1 days of market history.

FixExpect attention-driven volatility; the facts in this report say whether the contract itself can be used against holders.

StatusAcknowledged

Info

Recently launched — 1 day of market history

QA-RECENTThe token's oldest DEX pool is 1 day old. Age is not part of the risk score — a new token is not a risky one by default — but a short history means fewer trades and holder changes behind the facts in this report.

IssueThe token's oldest DEX pool is 1 day old. Age is not part of the risk score — a new token is not a risky one by default — but a short history means fewer trades and holder changes behind the facts in this report.

FixRe-check ownership, liquidity and holder distribution as the token matures; those are the facts that move early.

StatusAcknowledged

Category Ratings

TechnicalLow8/10

The contract demonstrates strong technical foundations with robust reentrancy protection through `_inTransfer`, `_inSwap`, and `_running` flags, and utilizes checked arithmetic in Solidity 0.8+. Assembly blocks for Uniswap V2 interactions are optimized and appear correctly implemented. However, a high-severity issue exists in the `pushOwed` function, which could lead to a denial of service for fund distribution if the number of tax payees is unbounded, potentially exceeding block gas limits (7.2 Code Security). The intricate module interaction, while safeguarded by `_undoes` checks, adds to the overall complexity and attack surface (7.1 Architecture).

GovernanceHigh3/10

The contract's economic model is sophisticated, incorporating platform fees, token taxes, and a swap-back mechanism to manage liquidity. The launch process is structured, requiring seeding and a scheduled opening, which contributes to a controlled rollout (7.5 Governance). However, the `_windowPrice` function, which calculates a TWAP from Uniswap V2, presents a medium risk of oracle manipulation if the observation window is too short or liquidity is low (7.4 Economic). Additionally, public functions like `open()` and `process()` are susceptible to front-running, potentially allowing malicious actors to gain an unfair advantage or cause transaction reverts (7.4 Economic).

UpgradesLow7/10

The contract is not designed to be upgradeable. This eliminates risks associated with upgradeability patterns (e.g., proxy implementation bugs, improper initialization, or storage collisions). However, it means that any discovered vulnerabilities or desired feature changes would require a new deployment and migration.

Security Checklist

4/5 checks passed

Contract VerifiedPass

Ownership Renounced?

No Mint FunctionPass

Liquidity LockedPass

Not a ProxyPass

HoneypotNoneBuy Tax0.0%Sell Tax0.0%

Holder Composition

82.4% in top 10

4.3% in wallets14.5% in contracts

Effective Concentration10.1%

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

$9.1K

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 Locked100.0% · Null Address, PinkLock02

Key Addresses

1 addresses

Deployer

0x62d8…dd3f

What Raised This Score

2 factors

Ownership status UNKNOWN (owner could not be resolved)
Liquidity < $10k ($9,108 across 1 pairs — easily drained)

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 POO.MEME a Scam?

Security Findings

Potential Denial of Service in `pushOwed` due to Unbounded Loop

Oracle Manipulation Risk for `_windowPrice`

Front-running Opportunities in `open()` and `process()`

The market for this token

High Complexity of External Module Interactions

Use of Non-Standard `transient` Keyword

Unused Compile-Time Assertion Function

Who holds the supply

Not listed by any independent source

Liquidity time-locked

Asset class: Meme token

Recently launched — 1 day of market history

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 POO.MEME?