PonsV2LauncherToken $SNOP

Risks (8)

• CriticalWithdrawing through the dApp failed ("Sell")honeypotDeterministic

  We ran the project's own dApp on a local fork. The "Sell" step did not work. Expected: It isn't real money and no one can withdraw it. (source: https://snopfamily.app/docs). Observed: wallet +0.0098 ETH, -5858334.81 SNOPCAT; contracts: 0xbd75…4800 (site-mention) +5858334.81 SNOPCAT, 0xbd75…4800 (site-mention) -0.0098 ETH; 2 tx (approve ok, sell ok). returned 0.0098 ETH of 0.01 ETH deposited (98.01%) | driver: done — Successfully sold all SNOPCAT back to ETH.. Money deposited may be impossible to take out.

  Evidence

  • forkdApp test "Sell" on a local fork (https://snopfamily.app/launchpad/0xb980c97daf4b5cf8ad71fdda9d8e40c49c8df955)
    Show source

    wallet +0.0098 ETH, -5858334.81 SNOPCAT; contracts: 0xbd75…4800 (site-mention) +5858334.81 SNOPCAT, 0xbd75…4800 (site-mention) -0.0098 ETH; 2 tx (approve ok, sell ok). returned 0.0098 ETH of 0.01 ETH deposited (98.01%) | driver: done — Successfully sold all SNOPCAT back to ETH.

  Confirmed by: facts

• HighClaim contradicted: 100% of the protocol revenue will be used to buy back SNOP tokens.claims-mismatchDeterministic

  The project claims buyback & burn, but none of the 14 burn(s) seen was preceded by a buy from a pool in the same transaction (1.5% of supply burned in total).

  Evidence

  • Xhttps://x.com/snopfamilyapp/status/2118189699802054831
    Show source

    The tech is working as expected, and 100% of the protocol revenue will be used to buy back $SNOP

  • on-chainTransfer events of 0x0f58e1a3754dfc352ffae8e962c729ede06a8c5e to burn addresses + balanceOf(0x…dEaD)
  • webhttps://snopfamily.app/docs
    Show source

    The curve and the pool each charge 1% on trades. 30% of that goes to the protocol. The rest goes to the token's creator, unless the creator turned on buybacks, in which case half of it buys the token back.

  • webhttps://snopfamily.app/token
    Show source

    Nothing has been promised about supply, price or airdrops, so don't trust anyone who says otherwise.

  Confirmed by: facts, grok-4.7

• HighProject site says SNOP is not its token, yet X promotes this contractclaims-mismatchAI

  The project's own token page says Snop has not issued a protocol token and that any token named SNOP is unofficial until an address is published on that page. The X account bio and launch post present 0x0f58…8c5e as the SNOP contract. Buyers of this contract are not holding an asset the site recognizes as the project's token. The LarpCheck bot made the same allegation; the page fetch confirms it.

  Evidence

  • webhttps://snopfamily.app/token
    Show source

    There is no SNOP token yet. Since anyone can launch on Snop, someone could make a token and call it SNOP. It wouldn't be ours. Until an official address is published on this page, treat any token using the name as unofficial.

  • Xhttps://x.com/snopfamilyapp/status/2118179267775287373
    Show source

    Introducing SNOP, a reverse-engineered version of PONS... CA: 0x0f58e1a3754dfc352ffae8e962c729ede06a8c5e

  • Xhttps://x.com/Larpcheckbot/status/2118405251082428749
    Show source

    Project's site disowns this coin... Snop's own site says there is no SNOP token and calls tokens using the name unofficial, yet the account promotes this contract as its CA.

  Confirmed by: grok-4.7, gpt-5.6-sol

• MediumPons factory owner controls graduation and rescue of curve fundsliquidityAI

  All trading money (about 1.06 ETH real quote) and about 61.8% of supply sit in the bonding curve. Only the Pons V2 factory can call graduate(), and graduate() sends all reserves to a recipient the factory chooses. The curve does enforce that graduate() only works once the sellable allocation is sold out. The factory owner 0x263e…19Dd has three relevant powers. It can call rescueSweptGraduation (sends tokens and ETH, 7-day GRADUATION_RESCUE_DELAY) and forceSweptGraduation. It can also replace the graduationExecutor and the launchDeployer with no bound. The factory source was omitted, so we cannot confirm where rescued or migrated reserves can be sent. If misused, the owner could redirect graduation liquidity instead of seeding the Uniswap v4 pool. This is a launchpad-wide trust assumption, not something the SNOP creator controls. The curve's own rescueFees() only pays already-accrued fees to the fixed protocol recipient and the creator, never the trading reserves.

  Evidence

  • codePonsV2BondingCurve.sol:L598-L638
    Show source

    function graduate(address recipient) external onlyFactory returns (uint256 quoteOut, uint256 tokenOut) {
            if (graduated) revert AlreadyGraduated();
            if (recipient == address(0)) revert ZeroAddress();
            if (!readyToGraduate()) revert NotReadyToGraduate();
    
            // Halt trading before the sweep, not after. The sweep pays the escrow,
            // and a quote asset with a transfer callback can re-enter buy() or
            // sell() from inside that payment. This function is deliberately not
            // nonReentrant so it stays callable from within buy()'s own guarded
            // scope, so the flag is the only thing closing that window. Reentering
            // while it was still false repopulated the fee buckets after they had
            // been zeroed, leaving balances with no quote behind them once the
            // reserve was handed over, and no way to ever sweep them.
            //
            // Safe to set here: readyToGraduate() is already evaluated above, and

  • codePonsV2BondingCurve.sol:L847-L848
    Show source

    * Mirrors PonsV2MemeHook.rescuePoolFees for the post-graduation pool and
         * PonsV2LaunchFactory.rescueSweptGraduation for the reserves in between.

  • on-chainPonsV2LaunchFactory fn rescueSweptGraduation(address,address) [owner] @PonsV2LaunchFactory.sol:L1254-L1286 — sends tokens out, sends ETH
  • on-chainPonsV2LaunchFactory param graduationExecutor = 0xC7819B64A1dAECD7eC19856d026cb14EfBd89046 (settable by setGraduationExecutor [owner]); owner = 0x263ed295dAFaE1d9AAdD6E56c4B6F9f38eE019Dd; GRADUATION_RESCUE_DELAY = 604800
  • codePonsV2BondingCurve.sol:L850-L871
    Show source

    function rescueFees() external onlyFactory returns (uint256 protocolAmount, uint256 creatorAmount) {
            uint256 pending = quoteFeeBalance;
            uint256 tax = creatorTaxBalance;
            if (pending == 0 && tax == 0) revert ZeroAmount();
    
            protocolAmount = (pending * protocolFeeShareBps) / BASIS_POINTS;
            creatorAmount = pending - protocolAmount + tax;
    
            quoteFeeBalance = 0;
            // Symmetrical with the sweep. This pays the creator their whole
            // bucket, earmark included, so leaving the earmark behind would let a
            // settled claim survive into the next accrual and divert fees the
            // creator has not earned yet into the vest.
            buybackQuoteBalance = 0;
            creatorTaxBalance = 0;

  Confirmed by: claude-opus-5.5 · Disputed by: gpt-5.6-sol

• LowSnipers took 9% at launch and sold; one cluster still holds about 5%holdersAI

  Two wallets funded by 0x2cff…2680 hold about 4.97% together, including the largest non-infrastructure holder, 0xac34…7da9 (4.16%). Four unidentified contracts among the top holders hold about 8.5% combined. Launch snipers bought about 9.19% of supply, and a 4-wallet same-funder bundle bought 2.62%. Both groups now hold 0%, so they are no longer a dump risk. With only 60 holders and the top 10 at about 23.6%, a few sellers can move the price on a thin curve.

  Evidence

  • on-chainclusters: funder 0x2cff890f0378a11913b6129b2e97417a2c302680 wallets 0xac34d4065a83870e2ee54fc73a44ff775df27da9, 0x1ed7dc44b0dff98779eb6964ba0556127c0dca23 pctSupplyHeldNow 4.9665
  • on-chainsnipers.pctSupplyBought = 9.1946, pctSupplyHeldNow = 0; bundle block 106412725 commonFunder 0x53091256ebd2d8aa37b45536a5fd864ca764f32f pctSupply 2.6193
  • on-chainholdersCount = 60; top10Pct = 23.6161

  Confirmed by: claude-opus-5.5, gpt-5.6-sol

• LowNot graduated yet; tiny side v4 pool has unlocked LPliquidityAI

  The curve has not graduated, so the official Pons migration to Uniswap v4 has not happened. Separately, a v4 pool holds about $2 of liquidity, with positions held by four ordinary wallets and 0% locked or burned. That pool is too small to trade, and its LP can be pulled at any time. Real liquidity (about $2,349) is on the bonding curve.

  Evidence

  • on-chainliquidity uniswap-v4 pool 0xed3ea09af57c8147723d8a2184d6708c76ebba0062901ca5f8c4a4820bb343c9 liquidityUsd=2 lpBurnedPct=0 lpLockedPct=0
  • on-chainlaunchpad.graduated = false; pons-v2-bonding-curve liquidityUsd 2349
  • webhttps://snopfamily.app/launchpad
    Show source

    Launch and trade tokens on Robinhood Chain. Fixed supply, locked liquidity, and a curve that opens the moment you sign.

  • on-chainLP token balances of pool 0xed3ea09af57c8147723d8a2184d6708c76ebba0062901ca5f8c4a4820bb343c9
    Show source

    lpBurnedPct: 0, lpLockedPct: 0, lpHeldByDeployerPct: 0

  • on-chainUniswap v4 position liquidity holders of pool 0xed3ea09af57c8147723d8a2184d6708c76ebba0062901ca5f8c4a4820bb343c9
    Show source

    0x1af0a8f2516044ed01d595cdeb3a69e2470d654c [other: wallet (unlocked)] 28.2986%

  • on-chainPonsV2BondingCurve.graduated = false
    Show source

    graduated: false

  Confirmed by: claude-opus-5.5, gpt-5.6-sol

• LowFactory can redirect creator fees and toggle buyback for SNOPfeesAI

  Through the factory, two settings can change on this curve. First, the creator fee recipient (currently the deployer 0x50Dd…c6EA) can be changed. The factory has a 3-day CREATOR_FEE_RECIPIENT_TIMELOCK constant and an owner cancel function. Second, buyback-and-lock can be switched on or off. Buyback is currently disabled, so no fees are used to buy SNOP back, and FACTS show 0 buyback burns. Neither setting can change trade fees or touch holder balances. They only decide who receives the 2% creator tax and the creator share of the 1% fee.

  Evidence

  • codePonsV2BondingCurve.sol:L343-L363
    Show source

    function setCreatorFeeRecipient(address newRecipient) external onlyFactory {
            if (newRecipient == address(0)) revert ZeroAddress();
            emit CreatorFeeRecipientUpdated(deployer, newRecipient);
            deployer = newRecipient;
        }
    
        /**
         * @notice Enables or disables this launch's buyback-and-lock fee route.
         * The factory authorizes both the current creator recipient and protocol
         * owner before forwarding the setting here.
         * @dev Applies to fees charged from here on, not to fees already pending.
         * Each trade earmarks its buyback slice as it is charged, so a toggle
         * cannot reach back and reroute value that accrued under the opposite
         * setting. Without that, a disable landing before a sweep would divert a
         * buyback the creator had already earned into their own payout, and an

  • on-chaincurve param buybackEnabled = false; deployer = 0x50Dd640FF465f1eA4F49d7206bDEbBF0b6E5c6EA; factory CREATOR_FEE_RECIPIENT_TIMELOCK = 259200
  • on-chaintoken.burns.buybackBurns = 0

  Confirmed by: claude-opus-5.5, gpt-5.6-sol

• LowWebsite runs its own admin-controlled launchpad with an unverified curvewebsiteAI

  snopfamily.app runs its own launchpad, separate from Pons. Its LaunchFactory (0xCd3B…36fF) is owned by 0x9cA5…9244. That owner can change the fee policy and launch fee without a bound and call rescue(address). The site's MemeHook takes swap fees at whatever hookFeeBps is set when a pool is registered, with no cap visible in the hook. Trades on the site route through an unverified curve contract with sweepFees and rescueTo functions. None of this controls SNOP, which trades on the Pons V2 curve. It is a trust consideration for anyone using the project's website to trade or launch tokens.

  Evidence

  • on-chainLaunchFactory 0xCd3B7a9675998Cab18DbEFb44b2ce27A8a6236fF owner=0x9cA5936AE88C2F40b3C7b5577b5d621762649244; fn setFeePolicy [owner] risk=high; fn rescue(address) [owner] risk=medium
  • codeMemeHook.sol:L78-L84
    Show source

    function registerPool(PoolKey calldata key, address token, uint16 hookFeeBps, uint16 creatorTaxBps) external {
            if (msg.sender != factory.modules().executor) revert NotAuthorized();
            bytes32 id = PoolId.unwrap(key.toId());
            _pools[id] = PoolInfo(key, token, hookFeeBps, creatorTaxBps, true);
            poolIdOf[token] = id;
            emit PoolRegistered(id, token);
        }

  • on-chainsite-mention 0xBD75718184D9BA562Bb57dA6B783Ee35d1cc4800 verified=false; fn rescueTo(address) [unknown (unverified)]

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

Positive signals (4)

• PositiveOngoing token burns verified on-chain: 1.5% of supply burnedburnDeterministic

  1.5% of the supply ever minted is burned, in 14 burn transfer(s), last 2026-11-06. Burned by: the deployer 0x50dd…c6ea (1.5%, 14 burns). Burned tokens are gone for good, which reduces the supply over time.

  Evidence

  • on-chainTransfer events to 0x0 / 0x…dEaD and balanceOf(burn addresses) of 0x0f58e1a3754dfc352ffae8e962c729ede06a8c5e

  Confirmed by: facts

• PositiveToken is a fixed-supply template with no owner powersownershipAI

  SNOP is the standard PonsV2LauncherToken: a plain OpenZeppelin ERC-20 with a voluntary burn. The whole supply is minted once, in the constructor, to the bonding curve. There is no owner, no mint after deployment, no fee, no blacklist, no pause and no transfer hook. The token does not use _update overrides. deployer, launchFactory and curve are immutable reference data and give no control over balances. Holders can always transfer their tokens. burnFrom only works with an allowance the holder granted.

  Evidence

  • codePonsV2LauncherToken.sol:L21
    Show source

    contract PonsV2LauncherToken is ERC20, ERC20Burnable {

  • codePonsV2LauncherToken.sol:L59-L70
    Show source

    deployer = deployer_;
            // Passed explicitly rather than read from msg.sender: PonsV2LaunchFactory
            // deploys this token indirectly through PonsV2LaunchDeployer to keep its
            // own bytecode under EIP-170's size limit, so msg.sender at construction
            // time would otherwise resolve to that deployer helper, not the factory.
            launchFactory = launchFactory_;
            curve = curve_;
            logo = logo_;
            description = description_;
            _socials = socials_;
    
            _mint(curve_, supply_);

  • codeERC20Burnable.sol:L35-L38
    Show source

    function burnFrom(address account, uint256 value) public virtual {
            _spendAllowance(account, _msgSender(), value);
            _burn(account, value);
        }

  • staticslither 0.11.6: issues = [] ; privileges = []

  Confirmed by: claude-opus-5.5, gpt-5.6-sol

• PositiveBuy and sell work on the curve with fixed fees of about 3%feesAI

  A real buy and sell were simulated on the bonding curve, and both succeeded. A second wallet that received tokens by plain transfer could also sell, and a sell one hour later worked. The roughly 3% cost per trade is the curve's 1% protocol fee plus a 2% creator tax. Both rates are immutable for this launch, and the curve's constructor refuses any combination above 20%. Nobody can raise them for SNOP. The 99% anti-snipe tax only applied in the first 3 seconds after launch and is now 0.

  Evidence

  • forkcanBuy=true buyTaxPct=2.98 canSell=true sellTaxPct=3 transferTaxPct=0
    Show source

    second wallet (received via transfer) could sell

  • codePonsV2BondingCurve.sol:L109-L114
    Show source

    uint256 public immutable feeBps;
        // Creator-chosen at launch, capped by the protocol at launch time. Kept
        // entirely separate from feeBps: it is layered on top of the base trade
        // fee, not part of the protocol/buyback/creator split, and is paid to
        // the creator in full.
        uint256 public immutable creatorTaxBps;

  • codePonsV2BondingCurve.sol:L222
    Show source

    if (feeBps_ + creatorTaxBps_ > MAX_TOTAL_TRADE_FEE_BPS) revert InvalidFeePolicy();

  • on-chaincurve: graduated=false, feeBps=100, creatorTaxBps=200, snipeTaxNow=0bps over 3s

  Confirmed by: claude-opus-5.5, gpt-5.6-sol

• PositiveCreator wallet holds no SNOP and has only burned, never soldinsidersAI

  The creator wallet was declared at launch, which made it snipe-tax exempt. It now holds 0% of supply and has sold 0%. Across 14 transactions it sent about 1.47% of supply to burn. There is no creator bag that could be dumped on holders.

  Evidence

  • on-chainDeployer 0x50dd640ff465f1ea4f49d7206bdebbf0b6e5c6ea holds 0% now; deployerSoldPct = 0
  • on-chainburns.by: 0x50dd640ff465f1ea4f49d7206bdebbf0b6e5c6ea kind=deployer pct=1.4732 count=14

  Confirmed by: claude-opus-5.5, gpt-5.6-sol

Notes (3)

• InfoFlagged dApp sell test traded SNOPCAT and returned 98% of fundswebsiteAI

  The previous critical 'withdraw failed' result does not hold up. The dApp test ran on the project website's own launchpad and traded a different token, SNOPCAT (0xB980…F955), not SNOP. It used an unverified curve, 0xBD75…4800. The buy and the sell both succeeded. The approval was exact, not unlimited, and the sell returned 0.0098 ETH of 0.01 ETH (98.01%), consistent with normal curve fees. The 'failed' flag came from comparing against a docs sentence, not from a revert or lost funds.

  Evidence

  • forkdappTests Sell: approve ok, sell ok
    Show source

    returned 0.0098 ETH of 0.01 ETH deposited (98.01%)

  • forkdappTests Sell step approve
    Show source

    approvalAmount: exact 5858334.81 SNOPCAT

  • forkdappTests Buy: passed=true
    Show source

    Successfully bought SNOP CAT with 0.01 ETH.

  Confirmed by: claude-opus-5.5, grok-4.7, gpt-5.6-sol

• InfoSnipe-tax setters affect only future launches, not SNOPfeesAI

  The previous finding is still accurate but does not apply to SNOP. The Pons factory owner can set snipeTaxStartBps and snipeTaxSeconds with no bounds. However, each curve copies these values once, at initialize, and has no setter afterwards. SNOP's window was frozen at 99% decaying over 3 seconds and has already expired, so these setters cannot affect SNOP trading.

  Evidence

  • codePonsV2BondingCurve.sol:L282-L284
    Show source

    launchedAt = block.timestamp;
            snipeTaxStartBps = IPonsV2SnipeTax(factory).snipeTaxStartBps();
            snipeTaxSeconds = IPonsV2SnipeTax(factory).snipeTaxSeconds();

  • codePonsV2BondingCurve.sol:L319-L322
    Show source

    uint256 elapsed = block.timestamp - launchedAt;
            uint256 window = snipeTaxSeconds;
            if (elapsed >= window) return 0;
            return startBps >> ((elapsed * 14) / window);

  • on-chainPonsV2LaunchFactory setSnipeTaxStartBps / setSnipeTaxSeconds [owner], bounds unbounded

  Confirmed by: claude-opus-5.5, gpt-5.6-sol

• InfoX account and domain are one day old with no named teamsocialAI

  @snopfamilyapp was created 2026-11-04, the domain the next day, and the token was deployed minutes after the domain. Followers are 57 with small like counts, which fits a new account rather than bought reach. Posts describe SNOP as a community experiment inspired by Pons and explicitly say there is no promise of price recovery. No person is identified.

  Evidence

  • Xhttps://x.com/snopfamilyapp/status/2118179267775287373
    Show source

    There is no promise of PONS price recovery or financial returns. The market will decide. PONS was the inspiration. SNOP is the experiment.

  • webhttps://snopfamily.app/docs
    Show source

    Anyone can launch here, and Snop doesn't review tokens first. The contracts haven't had an external audit yet.

  Confirmed by: grok-4.7, claude-opus-5.5 · Disputed by: gpt-5.6-sol