PonsV2LauncherToken $byte

Risks (9)

• HighClaim contradicted: When paid scans return, part of every fee is burned on-chain.claims-mismatchDeterministic

  The project claims ongoing burns, but only a single burn were seen (0.0% of supply, last 2026-11-04).

  Evidence

  • webhttps://bytejury.xyz/
    Show source

    When paid scans return, they cost $BYTE. Part of every fee is burned on-chain, the rest funds the treasury.

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

  Confirmed by: facts

• HighCreator-declared wallets bought 27% of supply at launchinsidersDeterministic

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

  Evidence

  • on-chaininsiders: 4 wallets, fundedBy declared by creator at launch (snipe-tax exempt on curve; creator 0x984d8b62278f053948b6d43cb666dcf8be980b8f), bought at launch 26.98%, pctSupplyHeldNow 1.0787
  • on-chaintoken.insiders: declared by creator at launch (snipe-tax exempt on curve)
    Show source

    0x984d8b62278f053948b6d43cb666dcf8be980b8f, 0x38d532b0786a4cdfaeab82e02542703fa522992f, 0xbc29d907391ce3b3756d2b660da0d5f02a2db90a, 0xc4fd66d44bddba69b3c1b863971bf59ff7959ee7 — pctSupplyHeldNow 1.0787

  • on-chaintoken.bundles block 106239596
    Show source

    0xbc29d907391ce3b3756d2b660da0d5f02a2db90a, 0xc4fd66d44bddba69b3c1b863971bf59ff7959ee7 pctSupply 26.9813

  • on-chaintoken.clusters funder 0xa5df4d576a72ddbbb4296614aaf58ed6696ebe61
    Show source

    0xc4fd66d44bddba69b3c1b863971bf59ff7959ee7, 0x1caee5d40875ec30a1533ef4a02b756472a465cb, 0x6086e82bdcd43efceae37b165fb003055fb38bd0, 0x287ed6b2d63a4b783a3800b5290ef4041349f3fa, 0x496e393e421ae2fa69387ab7bafe2f68c0866e0a pctSupplyHeldNow 0

  • on-chainScanPayments owner = treasury = 0x38d532B0786A4CDfAEaB82e02542703fa522992f

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

• HighLaunch sniped: 41 wallets took 92.4% of supply in 10 secondssnipersDeterministic

  The launch was captured: 41 wallets bought 92.4% 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 12.6% of supply, so current dump pressure from them is moderate — most of it was already sold, i.e. they exited on later buyers.

  Evidence

  • on-chainsnipers: windowBlocks=100, wallets=41, pctSupplyBought=92.412, pctSupplyHeldNow=12.5695
  • on-chaintoken.snipers
    Show source

    pctSupplyBought 92.412, pctSupplyHeldNow 12.5695

  • on-chainliquidity pons-v2-bonding-curve 0x7B2ab0476F4B93a263C07E904b7E283fcF0dcA59 liquidityUsd 7643

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

• HighX promised 100% fee burn, but site says half goes to treasuryclaims-mismatchAI

  The official X account told holders that Pro Audits paid in $BYTE would burn 100% of the tokens used for payment. The project's own site and docs say each ScanPayments fee is split: part (security page: half) is burned and the rest goes to the treasury. Anyone buying $BYTE for a full-burn utility is relying on a claim the project itself contradicts. Who receives the treasury share is not identified here.

  Evidence

  • Xhttps://x.com/bytejury/status/2118311961054052361
    Show source

    Pro Audits will be paid in $BYTE, with 100% of the tokens used for payments being burned.

  • webhttps://bytejury.xyz/
    Show source

    Each scan fee is split on-chain by the ScanPayments contract between a burn and the treasury.

  • webhttps://bytejury.xyz/security
    Show source

    Calls requestScan(chain, address) on ScanPayments. Half the payment is burned, half goes to the treasury.

  • webhttps://bytejury.xyz/docs
    Show source

    The contract splits each payment on-chain: {burn} is burned (via burn() or sent to the dead address) and the rest goes to the treasury.

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

• MediumPayment-contract owner can drop byte or cut the burn shareclaims-mismatchAI

  The token's use case is paying for scans in ScanPayments, half of which is burned (burnBps = 5000). The ScanPayments owner, creator-declared wallet 0x38d532B0…, has several unchecked powers: - setUtilityToken can switch payment to any other token at any time, ending demand for byte. - setBurnBps can lower the burn share to 0%, sending everything to the treasury, which is the owner itself. - Operators can pause the contract, and only the owner can unpause it. There is no timelock on any of these.

  Evidence

  • codeScanPayments.sol:L383-L389
    Show source

    /// @notice Switch the utility token. Only the new token is accepted afterwards.
        function setUtilityToken(address newToken) external onlyOwner {
            if (newToken == address(0)) revert ZeroAddress();
            if (newToken.code.length == 0) revert NotAContract();
            emit UtilityTokenChanged(utilityToken, newToken);
            utilityToken = newToken;
        }

  • codeScanPayments.sol:L397-L402
    Show source

    /// @notice Burned share in bps; `newBps + extraBps` must not exceed 10000.
        function setBurnBps(uint16 newBps) external onlyOwner {
            if (uint256(newBps) + extraBps > BPS) revert InvalidBps();
            emit BurnBpsChanged(burnBps, newBps);
            burnBps = newBps;
        }

  • on-chainScanPayments params
    Show source

    burnBps = 5000 (50%) ... treasury = 0x38d532B0786A4CDfAEaB82e02542703fa522992f ... utilityToken = 0xA4E331eD89Db2fAe193C6C4216dD99adED105471

  • codeScanPayments.sol:L476-L479
    Show source

    /// @notice Emergency stop of every user / oracle entry point. Operators can pause; only the owner can unpause.
        function pause() external onlyOperator {
            _pause();
        }

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

• MediumUnverified bonding curve holds all liquidity and has fee-sweep functionsotherAI

  Every trade today runs through the curve at 0x7B2a…cA59. Its source code is not verified. Its function list includes sweepFees, rescueFees, setCreatorFeeRecipient, setBuybackEnabled, exemptFromSnipeTax, initialize and graduate. Who may call these, and whether any of them can touch trader reserves rather than only fees, cannot be checked. The simulation shows normal buys and sells today.

  Evidence

  • on-chainlaunchpad.relatedContracts bonding curve 0x7B2ab0476F4B93a263C07E904b7E283fcF0dcA59 verified=false
  • staticcurve function table
    Show source

    fn sweepFees(uint256) [unknown (unverified)] ... fn rescueFees() [unknown (unverified)] ... fn graduate(address) [unknown (unverified)]

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

• LowPons factory owner can change snipe-tax settings and rescue fundsfeesAI

  The factory owner is 0x263e…19Dd. That address can: - set snipeTaxStartBps (currently 9900 = 99%) and snipeTaxSeconds (currently 3) with no upper limit; - raise the creator-tax ceiling, but only up to 10% (1000 bps); - call rescueCurveFees; - call rescueSweptGraduation, which can send tokens and ETH out, subject to a 7-day GRADUATION_RESCUE_DELAY; - swap the graduation executor and the launch deployer. The curve keeps its own snipe-tax values, so the factory settings likely apply only to new launches. That cannot be confirmed because the curve and factory sources are not available. These are platform-wide powers, not specific to this token.

  Evidence

  • on-chainPonsV2LaunchFactory param snipeTaxStartBps
    Show source

    snipeTaxStartBps = 9900 (99%) (settable by setSnipeTaxStartBps(uint256) [owner], bounds unbounded (no require in setter))

  • on-chainPonsV2LaunchFactory param maxCreatorTaxBps
    Show source

    bounds bps <= MAX_CREATOR_TAX_CEILING_BPS=1000

  • staticPonsV2LaunchFactory.sol:L1254-L1286
    Show source

    rescueSweptGraduation(address,address) [owner] risk=medium — sends tokens out, sends ETH

  • on-chainPonsV2LaunchFactory GRADUATION_RESCUE_DELAY = 604800

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

• LowScan price can be raised without limit; risky with large approvalsotherAI

  ScanPayments is the project's pay-per-scan contract, and byte is its payment token. requestScan pulls the current quote with no maximum-price limit. An operator can change scanPrice at any time with no upper bound. If a user has given ScanPayments a large or unlimited approval, the operator could raise the price just before the user's scan. The user would then pay up to the full allowance, split between a burn and the treasury 0x38d532B0…. The code itself advises approving exactly the quote. The token has no permit function, so requestScanWithPermit relies on an existing allowance.

  Evidence

  • codeScanPayments.sol:L266-L274
    Show source

    /// @notice Pay for a scan of `target` on `chain` (CAIP-2). Approve exactly `quote(msg.sender, chain, target)` first.
        function requestScan(string calldata chain, string calldata target)
            external
            nonReentrant
            whenNotPaused
            returns (uint256 scanId)
        {
            return _paidScan(msg.sender, chain, target, type(uint256).max);
        }

  • codeScanPayments.sol:L440-L444
    Show source

    function setScanPrice(uint256 newPrice) external onlyOperator {
            if (newPrice == 0) revert InvalidAmount();
            emit ScanPriceChanged(scanPrice, newPrice);
            scanPrice = newPrice;
        }

  • codeScanPayments.sol:L645-L650
    Show source

    function _tryPermit(address owner_, uint256 value, PermitSig memory p) private {
            address token = utilityToken;
            if (token == address(0)) revert TokenNotSet();
            // A failed permit is ignored: either the allowance already exists (e.g. front-run permit) or transferFrom fails.
            try IERC20Permit(token).permit(owner_, address(this), value, p.deadline, p.v, p.r, p.s) {} catch {}
        }

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

• LowTwo near-empty unofficial Uniswap v4 pools exist before graduationliquidityAI

  The token has not graduated. Its real liquidity, about $7.6k, sits in the bonding curve. Two Uniswap v4 pools exist alongside it, with about $1 and $0 of liquidity. Their LP positions are held by unrelated addresses and are not locked. Trading in these pools risks extreme slippage or mispricing. They are not the official Pons graduation pool.

  Evidence

  • on-chainliquidity uniswap-v4 0x1b735a0f73436ff53e51d92212709034ad89cba34aa2adabd400bfec691633c0
    Show source

    liquidityUsd 1, lpLockedPct 0

  • on-chainliquidity uniswap-v4 0xb1126e7c69e4ec8c381c6e42908f1e18dcd5ee75b2954e593fad66bec870bbc4
    Show source

    liquidityUsd 0, lpLockedPct 0

  • on-chainlaunchpad.graduated = false

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

Positive signals (3)

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

  PonsV2LauncherToken is plain OpenZeppelin ERC20 plus ERC20Burnable. It has no owner, no mint after deployment, no fees, no blacklist, no pause and no upgrade path. The whole supply was minted once, to the bonding curve, in the constructor. The stored deployer address is only reference data and gives no control. Holders can burn only their own tokens, or tokens they have been approved to spend. Slither reported no issues.

  Evidence

  • codePonsV2LauncherToken.sol:L21
    Show source

    contract PonsV2LauncherToken is ERC20, ERC20Burnable {

  • codePonsV2LauncherToken.sol:L70
    Show source

    _mint(curve_, supply_);

  • codeERC20Burnable.sol:L35-L38
    Show source

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

  • on-chaincontract.privileges = [] ; isProxy = false
  • staticslither 0.11.6: issues = []

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

• PositiveBuy and sell both work on the curve at about 2.5% feeshoneypotAI

  A fork simulation bought and sold through the Pons V2 bonding curve. Both trades succeeded. A second wallet that received tokens by transfer could also sell, and selling still worked one hour later. The cost was about 2.49% on the buy and 2.5% on the sell. This matches the curve fees: a 1% protocol fee plus a 1.5% creator tax. Plain wallet-to-wallet transfers have no tax. The launch snipe tax has already decayed to 0.

  Evidence

  • forksimulation: canBuy=true buyTaxPct=2.49 canSell=true sellTaxPct=2.5 transferTaxPct=0
  • forksimulation note
    Show source

    curve fees: feeBps=100, creatorTaxBps=150

  • forksimulation note
    Show source

    second wallet (received via transfer) could sell

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

• PositiveProject contracts are published as open source on GitHubwebsiteAI

  The team points holders at public Solidity for payments, holder credits and the audit registries, and tells people not to trust the marketing and to read the code. That is a transparency step, not proof the code is safe.

  Evidence

  • Xhttps://x.com/bytejury/status/2118288463439253563
    Show source

    We audit other people's code, so ours is public. Every BYTEJURY contract is open source

  • webhttps://github.com/bytejury-exe
    Show source

    BYTEJURY smart contracts: pay-per-audit payments with on-chain burn, holder credits, ERC-7512 audit registry and ERC-8004 validation.

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

Notes (1)

• LowDomain, X account and token all created within about two dayswebsiteAI

  The website domain was created on 2026-11-03 and the token was deployed on 2026-11-04. The project has almost no track record. No deployer history is available.

  Evidence

  • webhttps://bytejury.xyz/
  • on-chaincontract.deployedAt = 2026-11-04T22:11:10.000Z; deployerHistory = []
  • Xhttps://x.com/bytejury/status/2118311961054052361
    Show source

    We’re taking a big step toward making Robinhood Chain safer for everyone.

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