PonsV2LauncherToken $MERY

Risks (7)

• HighClaim contradicted: There is no fee redistribution, no buyback, no burn tax, and no revenue share on the token.claims-mismatchDeterministic

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

  Evidence

  • webhttps://www.meryalraven.sbs/
    Show source

    No fee is redistributed: there is no buyback, no burn tax and no revenue share.

  • on-chainTransfer events of 0x134e52ed8ee01cbb1fb714098b606c57366369fd to burn addresses + balanceOf(0x…dEaD)

  Confirmed by: facts

• HighDApp requests an unlimited token approval to a contract we did not reviewotherDeterministic

  During the "Deposit NVDA" flow the dApp asks for an unlimited token approval in favour of an unknown spender, which is not among the contracts we analysed. Prefer approving only the exact amount.

  Evidence

  • forkdApp test "Deposit NVDA" on a local fork (https://www.meryalraven.sbs/borrow)
    Show source

    wallet no balance change; 1 tx (approve ok); 1 refused by wallet simulation. No successful transaction was made for this goal (fail). | driver: fail — Deposit NVDA failed because the wallet balance is 0.0000 NVDA, causing the contract deposit call to revert (insufficient NVDA balance).

  • forkapprove(address,uint256) → 0xd0601ce157db5bdc3162bbac2a2c8af5320d9eec (spender=0x6a3F…82A8 (vault (MeryalMorphoVault)), value=MAX_UINT256 (unlimited))
  • forkdappTests 'Deposit NVDA' step approve + deposit
    Show source

    Deposit NVDA failed because the wallet balance is 0.0000 NVDA

  • forkdappTests 'Withdraw collateral'
    Show source

    there is no collateral deposited (collateral 0.0000 NVDA, 0 open positions)

  • codeMeryalMorphoVault.sol:L97-L116
    Show source

    function deposit(uint256 amount) external {
            if (amount == 0) revert ZeroAmount();
            stock.transferFrom(msg.sender, address(this), amount);
            morpho.supplyCollateral(params(), amount, address(this), "");
            positions[msg.sender].collateral += amount;
            totalCollateral += amount;
            emit Deposited(msg.sender, amount);
        }
    
        function withdrawCollateral(uint256 amount) external {
            morpho.accrueInterest(params());
            Position storage p = positions[msg.sender];
            if (amount > p.collateral) revert TooMuch();
            p.collateral -= amount;
            totalCollateral -= amount;

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

• MediumCreator-declared wallets bought 18% of supply at launchinsidersDeterministic

  3 wallet(s) linked to the team (declared by the creator at launch, exempt from the snipe tax) bought 18% of the supply in the first blocks — an insider allocation that real buyers did not get. They now hold 0%, so current dump pressure from them is low; most of it has already been sold.

  Evidence

  • on-chaininsiders: 3 wallets, fundedBy declared by creator at launch (snipe-tax exempt on curve; creator 0x1f941ba7008641625c1581d5d82068881cbf5620), bought at launch 18%, pctSupplyHeldNow 0
  • on-chaintoken.insiders[0]
    Show source

    declared by creator at launch (snipe-tax exempt on curve; creator 0x1f941ba7008641625c1581d5d82068881cbf5620)

  • on-chaintoken.bundles block 105169208: wallets 0x8e0f0ae246da72b4d2d017b78960e62577c0713c, 0x00a57512207b3339630918f021c469290d732f68, pctSupply 17.9999
  • on-chainDeployer 0x1f941ba7008641625c1581d5d82068881cbf5620 holds 0% now

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

• MediumLaunch sniped: 24 wallets took 46.8% of supply in 10 secondssnipersDeterministic

  The launch was captured: 24 wallets bought 46.8% of the supply within 10 seconds. A small, fast group set the early price and could sell into everyone who bought later — bad for launch fairness and a strong insider/bot signal. They now hold 0% of supply, so current dump pressure from them is low — most of it was already sold, i.e. they exited on later buyers.

  Evidence

  • on-chainsnipers: windowBlocks=100, wallets=24, pctSupplyBought=46.8245, pctSupplyHeldNow=0
  • on-chaintoken.snipers: pctSupplyBought=46.8245, pctSupplyHeldNow=0
  • on-chaintoken.bundles block 105169216: 4 wallets, pctSupply 8.3997

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

• MediumPrivacy pool trusts an operator-run ZK setup and a single governorotherAI

  The project's USDG privacy pool (MeryalPoolZK) releases withdrawals against Groth16 proofs. According to the site, the trusted setup was run by the operator, and a public ceremony has not yet happened. Whoever holds that setup's secret could in principle forge withdrawal proofs and drain the pool. In addition, governor 0x5AF1…f456, which is also the screener, can set depositors, hand over control, and refuse deposits. The pool source was omitted, so the extent of these powers is not fully verified. This risk applies to dApp users, not to MERY holders directly.

  Evidence

  • forkdappTests 'Withdraw collateral' expected
    Show source

    Withdrawals, credit activations and sealed positions are Groth16 proofs; the setup was run by the operator until a public ceremony replaces it.

  • on-chainMeryalPoolZK 0x4FFCAD6ad465D2695e51c300E50288a4887035ba governor = screener = 0x5AF1FBD7d96c049220849e930F6c7dB308d5f456
  • webhttps://www.meryalraven.sbs/
    Show source

    Live beta, not audited. Withdrawals, credit activations and sealed positions are Groth16 proofs; the setup was run by the operator until a public ceremony replaces it.

  • Xhttps://x.com/Meryal_Raven/status/2118277138893713468
    Show source

    Next is the public part: a setup ceremony anyone can contribute to, and keeper seats for outside operators who bond $MERY and take a share of the key.

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

• MediumUnanswered claim that one funder sniped MERY and farmed Pons launchesdeployer-historyAI

  A third party says wallet 0x4bFA…c344 funded both the MERY token deployer and the contracts deployer, bought 12.1M MERY soon after launch and sold 10.3M, funded about 39 fresh Pons deployers (UNAL, COLT, DARKCOMP, ARCTIC, PV4, CLOUDY, FUTUR and others) that received about 40 ETH of creator fees, and funded 0x8e0f…713c which bought 10% of MERY in the creation block and dumped it in seconds. The same post says the 2-of-3 multisig and the three keepers were all funded by that source. The team has not answered in the posts reviewed. Our facts list no prior tokens for the named deployer 0x1f94…5620, so this is an allegation about a funder, not something those facts confirm. If true, insiders already sold into holders and the same operator may have fee-farmed other Pons tokens.

  Evidence

  • Xhttps://x.com/anakintrading94/status/2118286729257898419
    Show source

    Wallet 0x4bFAe3CE8F037A8313fAE8530C5Ca7917f5ac344 funded both the $MERY token deployer and the contracts deployer... It bought 12.1M MERY 13 min after launch and has sold 10.3M since... funded ~39 fresh deployers that launched tokens on Pons (UNAL, COLT, DARKCOMP, ARCTIC, PV4, CLOUDY x3, FUTUR x3…) and got ~40 ETH of creator fees... 0x8e0f0ae246da72b4d2d017b78960e62577c0713c... bought 10% of MERY in the creation block and dumped it within 5 seconds.

  • Xhttps://x.com/Angelordevilhuh/status/2118288577071337584
    Show source

    great findings....not touching $mery until they clear this

  • on-chaindeployerHistory=[] for deployer 0x1f941Ba7008641625C1581d5d82068881Cbf5620
    Show source

    deployerHistory: []

  Confirmed by: grok-4.7, claude-opus-5.5

• LowX account is days old and no team member is namedsocialAI

  @Meryal_Raven was created 2026-10-28, the same day the domain was registered, about six days before the token deploy on 2026-11-03. It has 182 followers, follows nobody, and is verified. Posts are product updates, not a long history. No person is named or shown with proof, so "who runs this" cannot be checked from the social presence. A new quiet account is not itself a rug, but there is no track record to fall back on if the funder allegation is true.

  Evidence

  • Xhttps://x.com/Meryal_Raven/status/2118171945556439421
    Show source

    Meryal breaks the thread between the position and the spending, with a proof instead of a promise. CA 0x134e52ed8Ee01Cbb1FB714098B606C57366369Fd

  • webhttps://www.meryalraven.sbs/

  Confirmed by: grok-4.7

Positive signals (4)

• PositiveToken is a standard Pons template with no owner powersownershipAI

  MERY is the standard PonsV2LauncherToken: OpenZeppelin ERC20 plus ERC20Burnable. The full fixed supply is minted once, to the bonding curve, in the constructor. There is no owner, no further minting, no fee, blacklist, pause or transfer hook. The stored deployer is labelled as attribution data only and gives no special rights. Burning only works on your own balance, or on a balance you were given an allowance for. Static analysis (slither) reported no issues.

  Evidence

  • codePonsV2LauncherToken.sol:L44-L71
    Show source

    constructor(
            string memory name_,
            string memory symbol_,
            string memory logo_,
            string memory description_,
            Socials memory socials_,
            address deployer_,
            address curve_,
            address launchFactory_,
            uint256 supply_
        ) ERC20(name_, symbol_) {
            if (deployer_ == address(0) || curve_ == address(0) || launchFactory_ == address(0)) {
                revert ZeroAddress();
            }

  • codePonsV2LauncherToken.sol:L7-L20
    Show source

    /**
     * @title PonsV2LauncherToken
     * @notice Fixed-supply ERC-20 deployed by PonsV2LaunchFactory for a v2 launch.
     * The entire supply mints directly to the token's bonding curve instead of a
     * Uniswap position. Anyone, the deployer included, may buy any amount from
     * the curve at any time; the curve's own price impact and its reserved pool
     * allocation are the only limits on a large buy. `deployer` is carried here
     * as immutable reference data for off-chain attribution only, and confers no
     * privileges over the token.
     * `ERC20Burnable` lets any holder voluntarily burn their own balance; the
     * protocol's buyback mechanism does not use it, bought-back tokens are
     * locked into `PonsV2BuybackVault` for a five-year vest instead of being
     * burned.
     */

  • codeERC20.sol:L176-L204
    Show source

    function _update(address from, address to, uint256 value) internal virtual {
            if (from == address(0)) {
                // Overflow check required: The rest of the code assumes that totalSupply never overflows
                _totalSupply += value;
            } else {
                uint256 fromBalance = _balances[from];
                if (fromBalance < value) {
                    revert ERC20InsufficientBalance(from, fromBalance, value);
                }
                unchecked {
                    // Overflow not possible: value <= fromBalance <= totalSupply.
                    _balances[from] = fromBalance - value;
                }
            }

  • staticslither 0.11.6: issues = []

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

• PositiveBuy, sell and transfer-then-sell all work with 0% token taxhoneypotAI

  On a fork of the graduated Uniswap v4 pool, the simulated buy, sell, sell from a second wallet that received tokens by transfer, and sell after one hour all succeeded. Amounts matched the quotes exactly. No token-level tax was found. Nothing in the token code or the hook can block sells.

  Evidence

  • forksimulation: canBuy=true, canSell=true, buyTaxPct=0, sellTaxPct=0, transferTaxPct=0
    Show source

    second wallet (received via transfer) could sell

  • forksimulation notes
    Show source

    sell after +1h: ok

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

• PositiveGraduated pool liquidity is fully held by the Pons LP lockerliquidityAI

  The main MERY/ETH v4 pool (about $23.5k liquidity) shows 100% of its LP locked. None of it is held by the deployer. The Pons locker also holds 8.16% of the token supply. The locker's own source was not provided, so the unlock terms could not be read. The locker owner can call setFactory.

  Evidence

  • on-chainliquidity pool 0x67c876c6b3bda4c1f72106d559f8d2a22c72e178d2b901d8ad19f691f50a2dff: lpLockedPct=100, lpHeldByDeployerPct=0
  • on-chaintopHolders: 0x267444D099b10fB5Ed7c3Cc7B7c767AdcA574952 (LP locker) 8.1632%

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

• PositiveTeam openly states beta, unaudited and no fee sharingwebsiteAI

  The site and posts do not promise an audit, a buyback, a burn tax, or a revenue share. They say keepers bond the token, no trading fee is redistributed, and people should use small amounts. That matches across the homepage, the token page, and the launch posts.

  Evidence

  • webhttps://www.meryalraven.sbs/token
    Show source

    No trading fee is redistributed: no buyback, no burn tax, no revenue share.

  • Xhttps://x.com/Meryal_Raven/status/2118141243435958406
    Show source

    Unaudited beta, small amounts.

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

Notes (6)

• LowEach pool swap pays ~3% to the launchpad and creator, fixed at launchfeesAI

  After graduation, trades go through a Uniswap v4 pool that uses PonsV2MemeHook. In afterSwap, the hook takes hookFeeBps plus creatorTaxBps of the swap's other leg. Its afterSwapReturnDelta permission lets it take this amount directly. For this launch that is 1% + 2%. These rates are copied into the pool's LaunchInfo when the pool is registered, and afterSwap reads only that copy. If the hook owner later changes the global hookFeeBps (capped at 10%), this pool's fee does not change. The sum is also capped at 20% at registration. The fees are split as follows: 30% of the 1% goes to the protocol recipient, the rest goes to the creator (with an optional buyback leg), and the 2% tax goes entirely to the creator. This is normal launchpad economics, not a trap.

  Evidence

  • codePonsV2MemeHook.sol:L444-L485
    Show source

    function _afterSwap(address, PoolKey calldata key, SwapParams calldata params, BalanceDelta delta, bytes calldata)
            internal
            override
            returns (bytes4, int128)
        {
            // The conversion and buyback legs swap against this same pool, but
            // they are never taxed here: v4-core skips a pool's hooks when the
            // hook itself is the caller (Hooks.afterSwap). Were that not so, the
            // skim would come out of the buyback before it reached the vault.
            PoolId poolId = key.toId();
            LaunchInfo memory info = launches[poolId];
            if (!info.registered) return (IHooks.afterSwap.selector, 0);
            if (info.hookFeeBps == 0 && info.creatorTaxBps == 0) return (IHooks.afterSwap.selector, 0);
    
            bool specifiedIsCurrency0 = (params.amountSpecified < 0) == params.zeroForOne;

  • codePonsV2MemeHook.sol:L342-L378
    Show source

    if (
                policy.protocolFeeRecipient == address(0) || policy.protocolFeeShareBps > MAX_PROTOCOL_FEE_SHARE_BPS
                    || policy.buybackBurnBps > BASIS_POINTS || policy.hookFeeBps > MAX_HOOK_FEE_BPS
                    || policy.maxInternalPriceImpactBps == 0 || policy.maxInternalPriceImpactBps >= BASIS_POINTS
            ) {
                revert InvalidBps();
            }
            // The curve bounds the same sum in its own constructor rather than
            // inheriting it from the factory. A pool taking more than the whole
            // unspecified leg would flip the swapper's output delta negative.
            if (uint256(creatorTaxBps) + policy.hookFeeBps > MAX_TOTAL_TRADE_FEE_BPS) revert InvalidBps();
    
            // The factory builds the key correctly today, but these two facts are
            // what every later fee credit and swap direction is derived from. A
            // memecoin that is neither currency would silently designate the wrong

  • codePonsV2MemeHook.sol:L251-L256
    Show source

    function setHookFeeBps(uint256 bps) external onlyOwner {
            if (bps > MAX_HOOK_FEE_BPS) revert InvalidBps();
            hookFeeBps = bps;
            emit HookFeeBpsUpdated(bps);
        }

  • on-chainlaunchpad.fees
    Show source

    protocol fee 1%; creator tax 2%

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

• LowPons owner sets fee policy for future launches only, not MERY'sownershipAI

  Address 0x263e…19Dd owns the hook, factory, buyback vault and locker. Ownership cannot be renounced. Its hook powers are: - set global fee parameters (protocol share ≤50%, hook fee ≤10%, buyback share ≤100%, price-impact limit between 0 and 100%); - change the protocol fee recipient; - replace the feeSweepOperator; - run rescuePoolFees. The global parameters only apply to pools registered later. rescuePoolFees pays the regular protocol/creator split, not the owner. The sweep operator chooses minimum outputs when fees are converted, so a careless or malicious operator could lose part of the fees. That affects creator and protocol fees, not holders' tokens. None of these powers can block MERY transfers or swaps.

  Evidence

  • codePonsV2MemeHook.sol:L235-L278
    Show source

    function renounceOwnership() public pure override {
            revert OwnershipCannotBeRenounced();
        }
    
        function setProtocolFeeShareBps(uint256 bps) external onlyOwner {
            if (bps > MAX_PROTOCOL_FEE_SHARE_BPS) revert InvalidBps();
            protocolFeeShareBps = bps;
            emit ProtocolFeeShareUpdated(bps);
        }
    
        function setBuybackBurnBps(uint256 bps) external onlyOwner {
            if (bps > BASIS_POINTS) revert InvalidBps();
            buybackBurnBps = bps;
            emit BuybackBurnBpsUpdated(bps);
        }

  • codePonsV2MemeHook.sol:L555-L603
    Show source

    function rescuePoolFees(PoolId poolId)
            external
            onlyOwner
            nonReentrant
            returns (uint256 protocolAmount, uint256 creatorAmount)
        {
            LaunchInfo memory info = launches[poolId];
            if (!info.registered) revert UnknownPool();
            address quoteToken = info.quoteToken;
    
            if (quoteToken != address(0)) {
                (protocolAmount, creatorAmount) = _rescueCurrency(poolId, info, quoteToken);
            }
            (uint256 memecoinProtocol, uint256 memecoinCreator) = _rescueCurrency(poolId, info, info.memecoin);
            if (protocolAmount == 0 && creatorAmount == 0 && memecoinProtocol == 0 && memecoinCreator == 0) {

  • codePonsV2MemeHook.sol:L184-L201
    Show source

    function getHookPermissions() public pure override returns (Hooks.Permissions memory) {
            return Hooks.Permissions({
                beforeInitialize: true,
                afterInitialize: false,
                beforeAddLiquidity: false,
                afterAddLiquidity: false,
                beforeRemoveLiquidity: false,
                afterRemoveLiquidity: false,
                beforeSwap: false,
                afterSwap: true,
                beforeDonate: false,
                afterDonate: false,
                beforeSwapReturnDelta: false,
                afterSwapReturnDelta: true,
                afterAddLiquidityReturnDelta: false,

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

• LowWebsite domain was registered about one week before the scanwebsiteAI

  meryalraven.sbs was registered on 2026-10-28, six days before the token launched. The first Wayback snapshot is from 2026-11-05. A very new site gives little track record.

  Evidence

  • on-chainsite.domainCreatedAt = 2026-10-28T18:25:28.000Z

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

• LowSite calls the token MERYAL while the contract symbol is MERYclaims-mismatchAI

  The contract symbol is MERY. The website title and token page call the same contract $MERYAL / MERYAL, while posts mix $MERY and Meryal. The posted contract address matches 0x134e…69Fd, so this is a naming mismatch, not a different token.

  Evidence

  • on-chainsymbol=MERY target=0x134e52ed8ee01cbb1fb714098b606c57366369fd
    Show source

    name: PonsV2LauncherToken, symbol: MERY

  • webhttps://www.meryalraven.sbs/token
    Show source

    $MERYAL Keepers and relayers bond $MERY to run Meryal

  Confirmed by: grok-4.7 · Disputed by: gpt-5.6-sol

• InfoOne-time burn: 0.18% of supply sent to a burn addressburnDeterministic

  0.18% of the supply ever minted is burned, in 1 burn transfer(s), last 2026-11-03. Burned by: the deployer 0x1f94…5620 (0.18%, 1 burn). This happened once, around launch; there is no sign of a continuing burn mechanism.

  Evidence

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

  Confirmed by: facts

• InfoCurrent holders are spread out; largest wallet holds about 3.1%holdersAI

  There are 251 holders. Excluding the PoolManager (17.59%) and the LP locker (8.16%), no wallet holds more than about 3.1%. Several of the top holders are contracts whose role is unidentified.

  Evidence

  • on-chainTop holders (excl. pools/curve/burn/infra/launchpad)
    Show source

    0x0e49931340da953c28a59b3c5cb734922c109484 [contract] 3.0969%, 0x67e5ecef151a2b1c6972042b73934e1975dce1b8 3.0727%

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