Quantum Pepe (QPEPE) security report
Quantum Pepe was AI-scanned from verified Solidity source and GoPlus evidence. No permanent honeypot, mint, proxy, blacklist, pause, or transfer-tax path was identified. Material findings include a front-runnable clone initializer, an unrestricted creator launch-block position, privileged factory configuration, and reward notifications that do not verify received funds.
The verified source does not show a permanent honeypot, owner mint function, blacklist, upgrade proxy, or configurable transfer tax. Material risks remain: an uninitialized clone can be claimed by the first caller, the creator can bypass launch buy and holding limits in the launch block, and reward notifications are not collateralized or balance-verified.
Trust score: 58/100. Source verified: Yes. Chain: ethereum. Contract: 0xe9ac549be395f50602cb1a45410af173152f484e.
This report was last modified on 2026-09-28 and contains 4 material findings.
high finding: Unprotected clone initializer can be front-run
Each fresh clone accepts initialization from any caller. The first caller becomes factory, receives the entire fixed supply through _mint(msg.sender, TOTAL_SUPPLY), and gains exclusive control over setMarket and enableHolderFees. If the intended factory does not initialize atomically, an attacker can initialize the clone first and control its initial supply and market configuration.
Evidence: initialize() is external with no factory or deployer check and only verifies factory == address(0). It then sets factory = msg.sender and mints TOTAL_SUPPLY to msg.sender. setMarket() and enableHolderFees() are restricted to this stored factory address.
Recommendation: Initialize clones within the deployment transaction or use a factory-only initialization authority, deterministic deployment flow, and an explicit initialization parameter or immutable factory reference that cannot be replaced by the first external caller.
high finding: Creator can bypass launch caps and acquire an unrestricted opening position
The creator is exempted from the launch-block buy and holding restrictions. A transfer from market to creator during _launchBlock sets creatorOpening to true, bypassing currentBuyCap() and the MAX_HOLD check. The creator can therefore acquire a large position immediately and later sell it into the market, creating a material centralized dump and launch-integrity risk.
Evidence: In _update(), creatorOpening is true when block.number == _launchBlock && to == creator. The buy-cap revert is skipped for creatorOpening, and the hold-cap check also skips it. The launch-block buy path otherwise restricts non-creators with CreatorOnlyBlock().
Recommendation: Apply the same buy and holding limits to the creator, or use a separately disclosed and permanently bounded allocation that cannot be acquired directly from the pool during the launch window.
medium finding: Reward notifications can create claims without verifying received funds
notifyReward() trusts its amount argument and does not verify native msg.value or the reward-token balance increase. For native rewards, a caller authorized as factory or rewardSource can notify an amount larger than the ETH actually held. For ERC-20 rewards, the contract assumes the source transferred the stated amount. This can create unbacked unclaimed balances and cause claim() to revert or remain unavailable when the contract lacks sufficient funds.
Evidence: notifyReward(uint256 amount) is payable but never checks msg.value against amount when rewardToken is address(0). For ERC-20 rewards it only updates accRewardPerToken and performs no balance-delta or transferFrom verification. claim() later sends amount using a native call or safeTransfer, which can fail if the contract is underfunded.
Recommendation: Require native msg.value == amount, or derive the credited amount from the balance increase. For ERC-20 rewards, pull funds with safeTransferFrom or verify an exact pre/post balance delta before updating the accumulator. Add insolvency and recovery handling for failed reward transfers.
medium finding: Factory retains powerful one-time market and reward configuration authority
Although GoPlus reports no owner, proxy, minting, blacklist, or pause signal, the contract retains privileged factory calls. The factory can choose an arbitrary market address once and can choose the reward token and reward source once. A compromised or malicious factory can redirect market-sensitive transfer restrictions or configure a reward system that cannot pay holders.
Evidence: setMarket() accepts any nonzero address and is callable only by factory. enableHolderFees() accepts arbitrary rewardToken_ and rewardSource_ and is also callable only by factory. These permissions are not represented as standard ownership, so owner-related GoPlus signals do not eliminate the factory trust assumption.
Recommendation: Use a verifiable canonical factory, publish the expected factory and configuration addresses, validate the market against the intended deployment, and constrain rewardToken and rewardSource to audited contracts before enabling holder fees.