Rugs

How the night's three rugs and the earlier two could have been refused before the buy, what is live now, and the ceiling sweep.

Worker: analysis-rugs. Brief: analysis-2026-09-06/BRIEF-rugs.md. Written 2026-09-06 07:46 Beirut. All times UTC unless marked +03.

TLDR

1. The deployer deny list Thomas asked for would not have worked. ZEP, PEZZED and PEZ were deployed by three different fresh EOAs (0x7d1bcd…, 0x62443b…, 0x30a3a6…), each a direct contract-creation, each with 7 to 8 lifetime transactions. Banning ZEP's deployer at 03:25 +03 would have stopped nothing at 04:23 or 05:06.
2. The signalling wallet was the common thread, and we already had its rap sheet. data/watchtower/smartmoney.json carried frankdegods: entries 39, rugs 6 (15.4%) with lastTs 2026-09-06T00:00:22Z, twenty-five minutes before the ZEP signal. research/smartmoney/FOLLOW-LIST.json graded it verdict: "watch". Nothing in executor/follower.mjs filterSignal() reads either field. That is the single cheapest fix on the table: zero RPC calls, one config key.
3. Four independent pre-buy tells each catch all three of the night's rugs with zero false positives across 36 controls on the debrief tape: pool quote asset is WETH not native ETH; liq/mcap >= 0.85 at signal time at any age; pre-entry sells/buys under 0.30; token bytecode is a hand-written 8.7 KB ERC20 with owner + maxTx instead of the 3248 / 181 / 44 byte launchpad shapes. Scorecard in finding 3.
4. These were honeypots, not only LP pulls. At 01:35 on PEZZED and 02:13 on PEZ the follower fired a real clip_target at about +60% and the sell reverted TransferHelper: TRANSFER_FROM_FAILED, once explicitly "Blocked: cannot sell" (data/executor/follower.log). The LP drain came after. No exit rule can beat a contract that refuses to sell, so the money is won or lost at the pre-buy gate.
5. The existing rugRatio guard already worked, it was just scoped too narrowly. It refused PEZZEL (0.93 at 10 min) and PENZ (0.94 at 9 min) that same night. ZEP (0.895 at 12 min), PEZZED (0.862 at 14 min) and PEZ (0.873 at 16 min) slipped through only because underAgeMin: 10 switches the guard off past ten minutes.
6. The in-position layer cannot save a hard pull, it can only stop the lying. ZEP's pool went dead about 7 minutes after our fill and we marked it at +18% off dexscreener for 2 h 20 m. A PoolManager liquidity watch buys truth and a fast write-off, not money.
7. Sample honesty: five rugs total (ZEP, PEZZED, PEZ, SEPE, CYBERDOG), three of them one family from one wallet in three hours. Every "zero false positives" below is against 36 controls on one tape. These are strong candidates, not laws.

1. Deployer genealogy

Method: Blockscout api/v2 and api are both Cloudflare-challenged from this box right now (HTTP 403, verified twice on both endpoints at 07:36 and 07:38 +03), so the address-history route in the brief was unavailable. Instead each token's first Transfer from the zero address was located with eth_getLogs on the public RPC and the minting transaction's from and to read back. Note for anyone reusing this: the Transfer topic on Robinhood Chain is 0xddf252ad1be2c89b69c2b068fc378daa952ba7f163c4a11628f55a4df523b3ef, not the canonical …b68c….

Source: analysis-2026-09-06/data/rugs/mints-out.txt, deployer-nonces.txt.

Reads:

• Three rugs, three deployers, zero overlap. A deny list keyed on the deployer has no predictive value inside a night. It has value only across nights, and only if we can enumerate a deployer's earlier launches, which needs an indexer we do not currently have.
• Raw contract creation is the family signature. The three frankdegods-family tokens were deployed straight from an EOA (to: null). Every control checked went through a factory. That fires on 3/3 of the family and 0/5 controls checked, but the sample of controls with resolved mints is only five, so treat it as a candidate, not a scored tell.
• The funding source question is unanswered. The public RPC has no archive state (eth_getTransactionCount at a historical block returns metadata is not found), and Blockscout is blocked, so "who funded these three burners" could not be established. This is the one item in the brief I could not deliver. It goes in needs Thomas below.
• The signalling wallet 0x696d… is not an EOA in the plain sense. eth_getCode returns 0xef0100e6cae83bde06e4c305530e199d7217f42808555b, an EIP-7702 delegation designator pointing at 0xe6cae83b…. frankdegods trades through a delegated smart account, which is consistent with an automated launch-and-buy loop rather than a human clicking.
• The wallet history was on disk. data/watchtower/smartmoney.json wallet row for frankdegods at lastTs 2026-09-06T00:00:22.438Z: entries 39, rugs 6, rank 49, pnl7d 880184. The rug count is computed in watchtower/smartmoney.mjs:183 as entries that either rugged or printed minPct <= -80. It is refreshed continuously and it is the same number the debriefs quote. The three lots of the night are not in that 6, so 15.4% was the prior rate.

Rug rate over the whole tracked cohort, from the same file (analysis-2026-09-06/data/rugs/smartmoney-rugs.txt, wallets with 5+ entries):

A maxWalletRugRate gate at 0.15 refuses frankdegods, seralberttrades, fr3ak, Rowdy, loganlim_x, Binkieee, elliotrades and about fifteen more. On this tape that costs hoodrat (+65%) and RF (+194%, Wide set, not live money) and saves the three rugs plus AJC, PETOI, Uranus, MADETEST, MUPPETS, Culio. On live Gold v2 dollars it is clearly positive; on paper Wide it is not.

2. Pre-buy tells, scored

Every tell below was computed from what was on disk at or before our entry timestamp: data/watchtower/feed.jsonl fields at signal time, and debriefs/<call>/swaps.jsonl truncated at metrics.json entryTs. 41 debriefed calls, 5 of them rugs. Full table: analysis-2026-09-06/data/rugs/tell-scorecard.txt.

The three that all four tells catch are ZEP, PEZZED and PEZ. None of the four catches SEPE or CYBERDOG, which were 181-byte launchpad clones on native-ETH pools with ordinary two-sided flow. SEPE has its own tell and it is already shipped (liq/mcap 1.599 at 3 minutes).

2a. Pre-entry sell flow is the sharpest number on the tape

The gap is 7x, not marginal. Thomas's note ("163 buys / 4 sells in h1 on PEZ") generalises: on a real launch roughly as many wallets sell as buy in the first minutes; on this family almost nobody sold, because almost nobody could. A threshold anywhere between 0.25 and 0.60 separates them cleanly on this tape. 0.30 with a 30-swap minimum is the conservative pick.

Second-order signal in the same numbers: the rugs are thin. 74 to 129 pre-entry swaps against 900 to 14,000 on the controls. Absolute swap count alone is not clean enough to use (Launch had 23, TERROR 8, SNOO 75, all honest), but combined with the sell ratio it is the same fingerprint.

2b. Liquidity to market cap, freed from the ten-minute window

The guard exists (executor/follower.json filters.rugRatio: { maxLiqToMcap: 0.8, underAgeMin: 10 }) and it worked. From data/watchtower/feed.jsonl:

The whole family sits in a band, 0.86 to 0.94, and the best control on the tape sits at 0.793. Raising underAgeMin from 10 to 60 (i.e. applying the ratio across the follower's entire 2 to 60 minute age window) and holding maxLiqToMcap at 0.80 refuses all five family tokens and nothing else in the feed rows I checked. The nearest control, BUSINESS at 0.793, survives by 0.007, which is uncomfortably tight, so 0.85 is the safer number and still catches all five.

2c. Quote asset and contract shape

Every token on the debrief tape resolves to one of three bytecode shapes (analysis-2026-09-06/data/rugs/bytecode-tells.txt):

And the quote asset: 16 of the 41 pools quote in native ETH, 22 in assorted quote tokens (USDG, PONS, SLV, ETH-wrappers and others), and exactly three quote in WETH 0x0bd7d308f8e1639fab988df18a8011f41eacad73: ZEP, PEZZED, PEZ. The WETH quote is also why the sell path had no route at all on the night, since the v4 sell leg assumed native-ETH pools until the 05:29 UNWRAP_WETH work. Two problems with one root.

Honest caveat on both: these three tokens came from one operator on one night. "WETH-quoted" and "8.7 KB owner contract" may be that operator's habits rather than a rug law. They are cheap enough to run as soft signals (log and alert) before they become hard refusals.

2d. Tells I could not test

• LP position ownership and locks. Uniswap v4 positions live in the PositionManager keyed by a salt; resolving "who holds the liquidity for pool X" needs either an indexer or a subgraph. Not reachable with Blockscout down. Untested.
• Deployer share of supply, deployer share of first-minute buys, unique buyers, one-funder clusters. All need per-swap sender addresses. debriefs/*/swaps.jsonl records blk, idx, tx, tok, q, px, buy, qRes, ts, pct, usd and no sender, so none of these could be computed from the tape. This is a concrete gap in what we record, see build.
• Hooks. The rugs' pool keys were not resolvable from what is on disk. Note from the night: HOVER was a hooked pool with a dynamic fee and was a false control, so hooks by themselves are not a rug tell.

3. What the follower actually did

From data/executor/follower.log and data/executor/follower-fills.jsonl.

Four things fall out.

1. The clip_target reverts are the story. On PEZZED at 01:35 and PEZ at 02:13 the ladder did exactly the right thing, fired a 50% clip at about +60%, and the token refused: TransferHelper: TRANSFER_FROM_FAILED, and once at 01:37 the unambiguous "Blocked: cannot sell". Sells worked earlier (12 sells in ZEP's pre-entry tape, 9 in PEZZED's), so this is a delayed honeypot: the owner flips a flag once enough buyers are in. That also means a pre-buy sell simulation would have passed at signal time and would not have saved these three. Worth building anyway for the static-honeypot case, but do not sell it as the fix for this family.
2. ZEP's 90-minute time stop was never late. The open question in memory/2026-09-06.md ("why 04:55 and not 01:55") is a timezone artifact: the buy was 00:25:57 UTC = 03:25 +03, and the stop fired at 01:55 UTC = 04:55 +03, exactly 90 minutes later. No ladder bug. Closing that question.
3. The marking was the real damage. From 00:33 the follower logged ZEP: no aggregator route to mark …, marking off the dexscreener mid $0.000001094 until one comes back and kept the lot at +18% for 2 h 20 m. The stop loss could never trigger because the mark never went down. The 05:29 v4PoolDrained fix addresses exactly this and would have cut ZEP's dead hold from 140 minutes to about 1 minute.
4. A liquidity-drop watch would have told the truth, not saved the money. The quote reserve on all three pools never fell in the swap tape: ZEP qRes ends at 26.647, which is also its maximum; PEZZED ends at its maximum 34.603; PEZ at 41.499 (analysis-2026-09-06/data/rugs/preentry-tells.txt). An LP burn is not a swap, so it is invisible to the swap feed by construction, and by the time v4PoolLiquidityById reads zero there is nothing to sell into. A "liquidity below 50% of entry" watch is worth building for the gradual drain case and for honest marking, but on this family it arrives after the door is shut. Only the pre-buy gate saves money here.

Recommendations

Ship now (config only, reversible)

1. filters.rugRatio.underAgeMin: 10 -> 60 and maxLiqToMcap: 0.8 -> 0.85 in executor/follower.json (mirror in watchtower/rules-v2.json Gold v2, the two must move together per fixes-2026-09-05/FIELDS.md). Refuses ZEP, PEZZED, PEZ, PEZZEL, PENZ, SEPE. Refuses nothing else in the feed rows checked. Cost: zero RPC, zero latency, the field is already on every feed row. This is the highest value single line in the report.
2. Extend filters.handlesDeny beyond frankdegods with the wallets whose prior rug rate is at or above 0.15 and that have signalled us: seralberttrades, fr3ak, Rowdy, loganlim_x, Binkieee. On this tape that gives up hoodrat (+$43.23 realised across two clips and a trail) and blocks AJC (-$26.40), PETOI, Uranus, MADETEST, MUPPETS and Culio. Net positive on live dollars, but it is a static list and it will go stale, so treat it as a bridge to item 4 below.
3. Leave burnedWalletHours: 24 alone. It is correct and it was shipped at 05:29. Note only that it is a post-loss rule: it cannot fire until one lot has already been written off, and on the night it would have fired only after ZEP's write-off at 02:54, by which point PEZZED and PEZ were already bought. It is a floor, not a fix.

Build (code, with the test that proves it)

4. walletRugRate filter in executor/follower.mjs. New check inside filterSignal() (executor/follower.mjs:203), placed next to the existing handlesDeny block at line 253. Reads the wallet row out of data/watchtower/smartmoney.json (already on disk, already refreshed by the watchtower, no new feed), computes rugs / entries, refuses when entries >= cfg.filters.minWalletEntriesForRugRate (default 8) and the rate is at or above cfg.filters.maxWalletRugRate (default 0.15). Refusal string: wallet <handle> has rugged 6 of 39 tracked entries (15%), over the 15% ceiling. Test: executor/test-follower.mjs, new group asserting (a) frankdegods at 6/39 is refused, (b) picadura at 0/7 passes, (c) a wallet with 3 entries and 1 rug passes because it is under the entries floor, (d) a missing smartmoney row passes rather than blocking the book. This is the check that would have refused all three lots at 00:25, 01:23 and 02:06 with no on-chain call and no added latency.
5. sellFlowSkip filter, same function. Refuse when the pre-entry tape has at least 30 swaps and fewer than 0.30 sells per buy. The counts are not on the feed row today; the collector that writes data/watchtower/feed.jsonl already walks the pool's swaps to compute runH1Pct, so add preBuys and preSells there and read them in filterSignal(). Test: executor/test-follower.mjs fixture rows for PEZ (70/4, refused), ZEP (117/12, refused), MILADY (505/380, passes), Launch (12/11 on 23 swaps, passes because under the swap floor).
6. Record the swap sender. Add the sender/origin address to each row of debriefs/*/swaps.jsonl and to whatever the collector persists. Without it, deployer-share-of-buys, unique-buyer counts and one-funder clusters, three of the tells the brief asked for, are permanently uncomputable. This is the single biggest data gap in the rug work.
7. Pre-buy quote-asset and bytecode probe, log-only first. In executor/routes.mjs, v4PoolKey() (line 259) already resolves the pool's counter currency before every buy, so flagging "counter is WETH, not native" is free. Add one eth_getCode on the token (about 40 ms, one Alchemy call) and flag owner()+maxTxAmount() selectors and code length over 8000 bytes. Ship these as alerts, not refusals, for a week, then score them. n=3 does not earn a hard gate. Test: executor/test-univ4.mjs, and note the group-2 CYBERDOG fixture is stale (delisted) and needs replacing regardless.
8. Liquidity-drop watch in the mark loop. executor/follower.mjs mark step 3 already calls v4PoolDrained when the simulate fails. Extend it to a ratio: record entryLiquidity from routes.mjs v4PoolLiquidityById(poolId) at fill time, and on every mark cycle exit at market when live liquidity is under 50% of it. Test: executor/test-follower.mjs with a stubbed v4PoolLiquidityById returning entry, 0.6x (hold), 0.4x (exit), 0 (write-off). Be honest about what it buys: on ZEP, PEZZED and PEZ it buys a truthful mark and a 1-minute write-off instead of a 2 h 20 m fiction. It does not buy dollars back.
9. Automatic deny-list feeding. On every liquidity_pulled close, append the signalling wallet and the token's deployer EOA (resolvable with the same mint-log lookup used here, two RPC calls) to a data/executor/rug-wallets.json file that filterSignal() reads. Deployer entries will rarely fire twice, per finding 1, but they cost nothing and they are the only way a genuine repeat deployer ever gets caught.

Needs Thomas

10. An indexer with address history. Blockscout is Cloudflare-blocked from this box on both /api and /api/v2, and the public RPC serves no archive state. Without one of a Blockscout API key, an Alchemy tier with getAssetTransfers, or another Robinhood Chain indexer, we cannot answer "how many tokens has this EOA launched before" or "who funded this burner", which is the literal wording of the brief. This is also the execution lane's problem, so decide it once.
11. Accept the cost of the wallet gate. A 0.15 rug-rate ceiling refuses roughly a quarter of the tracked cohort, including fr3ak, which produced hoodrat. Confirm you want that trade before item 4 goes live rather than log-only.

Open questions

• Are the three burner deployers funded from one wallet? Unanswerable here (item 10). If they are, a funder deny list beats a deployer one and would have caught PEZZED and PEZ after ZEP.
• What flipped the sell block, and when? "Blocked: cannot sell" appears exactly once in the log, at 01:37 on PEZZED, while TRANSFER_FROM_FAILED appears 114 times. Reading the ZEP/PEZ contract source (verified or decompiled) would tell us whether the switch is an owner call, a block-height trigger, or a buy-count trigger, and therefore whether any pre-buy simulation could ever have seen it coming.
• Is the WETH-quote correlation real or is it one operator's habit? Three tokens, one deployer family, one night. Needs a week of log-only scoring.
• LIQLORACLE at liq/mcap 0.754 was the night's biggest winner (+551% paper, +$128.86 realised live) and sits 0.05 below the proposed 0.80 line and 0.10 below the safer 0.85. That is the false-positive risk in the highest-value recommendation in this report, and it is worth watching that number specifically over the next fifty calls.
• CYBERDOG and SEPE are caught by none of the new tells. Two rugs, launchpad clones, ordinary flow. We do not currently have a pre-buy story for that shape beyond the liq/mcap ratio that already catches SEPE.

Sources

• data/executor/follower-fills.jsonl (fields side, reason: liquidity_pulled, ts, pnlUsd), data/executor/follower.log, data/executor/follower-state.json
• data/watchtower/feed.jsonl (fields liqToMcap, ageMin, liquidityUsd, mcap, runH1Pct, otherCohortWallets10m, verdicts, live.state), data/watchtower/smartmoney.json (wallet rows: entries, rugs, rank, lastTs), data/watchtower/state.json
• debriefs/{ZEP,PEZZED,PEZ,SEPE,CYBERDOG,LIQLORACLE,hoodrat,BODKIN,ETHOSIS,AJC,MADETEST,MUPPETS,BUSINESS,...}-2026-09-0*/{metrics.json,swaps.jsonl,REPORT.md} (41 calls)
• research/smartmoney/FOLLOW-LIST.json (93 wallets, verdict, wash), watchtower/smartmoney.mjs:183 (rug definition), watchtower/callers.mjs:248
• executor/follower.json, executor/follower.mjs (filterSignal 203, rugRatioSkip 192, burnedWallet 1003), executor/routes.mjs (v4PoolKey 259, v4PoolLiquidityById 397, v4PoolDrained 403), watchtower/watchtower.mjs (PONS 56, pollPons 485)
• memory/2026-09-06.md 05:29 block
• On-chain, this session: public RPC eth_getLogs / eth_getTransactionByHash / eth_getTransactionCount / eth_getBalance, Alchemy eth_call / eth_getCode. Working files under analysis-2026-09-06/data/rugs/: feed-cases.txt, metrics-summary.txt, preentry-tells.txt, tell-scorecard.txt, bytecode-tells.txt, honeypot-strings.txt, mints-out.txt, deployer-nonces.txt, smartmoney-rugs.txt, wallet-verdicts.txt, plus the scripts genealogy.mjs and mints.mjs.

Brief: analysis-2026-09-06/BRIEF-tuning.md. Script: sweep.mjs (rerunnable, node stdlib only, imports filterSignal / rugRatioSkip / liqToMcap / walletRugRateSkip from executor/follower.mjs). Full grid: sweep.json (1044 rug-gate points + 6 age points). Disk-only replay, no RPC.

Tape: data/watchtower/feed.jsonl, 1422 rows / 330 tokens, 2026-09-04T22:17Z to 2026-09-06T07:31Z.

0. Headline

1. Method and universe

Pool. "Rows Gold v2 would otherwise have taken" is built by running the live filterSignal with the three gates this sweep moves (maxAgeMin, rugRatio, maxWalletRugRate) switched off, and every gate it does not move left on: band in {under 250k, 250k to 1M}, minAgeMin 2, liquidity 25k-400k, maxMcapUsd with the 2h / 3M fresh exemption, minBuyUsd 100 (measured receipts only), maxOtherCohortWallets 1, maxRunH1Pct 500. entry.cooldownMinPerToken 120 is applied in time order so a token cannot be counted eight times. handlesDeny is emptied for the replay, because the static frankdegods entry is exactly the thing the wallet rule is meant to replace. Two Gold v2 gates are not reconstructible from disk and are not applied: entry.maxChasePct (needs the live exec quote at signal time) and universe.maxSignalAgeSec (a liveness check, satisfied by construction when the row was written).

Rug tokens in the pool: SEPE, ZEP, PEZZEL, PEZZED, PEZ, PENZ. Runner tokens: AJC, BODKIN, BUSINESS, CLANKSEN, Culio, ETHOSIS, LIQLORACLE, MADETEST, MUPPETS, PETOI, PasDePanique, RF, ROBBING, hoodrat.

No-outcome rows. 13 of 41 pool tokens (17 of 60 pool rows) have no book, no debrief and no fill, so no label. They are counted in every "rows refused" column and excluded from every rate. On the whole feed the figure is 228 of 330 tokens, which is why every rate below is quoted against the pool, not the feed.

Money. Credited once per token, on its first refused row. paperG2 is the Gold v2 book close (pnlUsd summed over closes); paperAny falls back to the widest v2 book for tokens that predate the Gold v2 set (created 2026-09-05T07:42Z), so it mixes sets and is the weaker column; live sums follower-fills.jsonl sell and writeoff pnlUsd. Sign convention throughout: negative = refusing that row saved money, positive = refusing forwent money.

2. The decisive rows

Every rug and every near-line runner in the pool, with the two numbers the gates read:

Reading the table: the rug-ratio gate has a clean window of 0.793 to 0.862 and an age window whose binding rug is PEZ at 16 min. Everything else in the grid is noise around those two numbers.

The PEZ hole. At 02:16:54Z the LP had topped the pool up, so PEZ came back at liqToMcap 0.681, ten minutes after the 02:06 signal, from @AvgJoesCrypto (7 entries, 1 rug, 0.143) and @RugDalio (no rug row in smartmoney.json at all, so no rate to test). 0.681 is under every maxLiqToMcap in the grid and both wallets are under every maxWalletRugRate. In the replay that row is always taken, so takenLabels.rug is 1 at all 1044 grid points. Live this did not happen, because the 02:06 buy set the per-token cooldown; in the replay the 02:06 row is refused, which re-opens 02:16. That is the honest shape of the risk: the ceiling gates buy a first-signal veto, not immunity, and a rug that reloads its pool walks back in through the front door.

3. Pareto front

Settings that refuse a row of all 6 rug tokens, ordered by runners lost then Gold v2 paper forgone. 772 of the 1044 grid points refuse all 6. To keep every number exact, the table is pinned at underAgeMin 60, the shipped value (20, 30 and 45 give the same runner and money columns; only the unknown-token counts move by one). At 60, 157 of the 174 points refuse all 6 and collapse to 35 outcome classes; the front and the notable classes below it are:

Class 1 is the tip: it is the only class that refuses every rug token without touching a single runner. Class 7 is the money-best point on live and on Gold v2 paper. The shipped config sits at class 23, eight runners deep into the front, buying nothing over class 1 in rug coverage and taking only 22 of the pool's 41 tokens.

Reference points side by side:

Every row of this table still takes PEZ once, on its 02:16Z re-signal. See section 2.

4. Recommendation

filters.rugRatio.underAgeMin           60      (keep as shipped)
filters.rugRatio.maxLiqToMcap          0.82    (from 0.85)
filters.maxWalletRugRate               0.18    (from 0.15)
filters.minWalletEntriesForRugRate     10      (from 8)
filters.maxAgeMin                      60      (keep)

The age half of the rug-ratio gate is the lever that actually catches rugs and it is free: underAgeMin 10 catches 3 of 6, 15 catches 5 of 6, and 20 catches all 6, after which 30, 45 and 60 are byte-identical because no runner in the pool has a liqToMcap above 0.793 at any age. Keeping the shipped 60 buys 44 minutes of margin over PEZ at 16 min for nothing, so keep it. The ratio half is a dead zone: 0.80, 0.82 and 0.85 produce exactly the same refusals, the same runners and the same dollars, so the choice is pure margin geometry, and 0.82 is the only value that centres the one clean separation the tape gives us. Nearest miss below the line is BUSINESS at 0.793 (peak 77%, +8.61 Gold v2 paper), 3.3% under 0.82; nearest miss above is PEZZED at 0.862 (-50.00 live), 5.1% over. Shipped 0.85 leaves PEZZED only 1.4% of headroom, and 0.80 leaves BUSINESS only 0.9%; with 6 rugs and 14 runners neither tail is estimated well enough to justify sitting on either edge. Going to 0.78 starts costing BUSINESS, and 0.75 costs LIQLORACLE, the tape's single best name at 0.754 (+275.67 paper, +128.86 live), which is a $128 mistake to avoid a $50 one. The wallet gate is the one place the shipped numbers are wrong: at minWalletEntries 8 a 0.15 rate is 1.2 rugs, which is indistinguishable from a clean wallet, and it costs 8 of the 14 runners for zero additional rug refusals. Moving it to 0.18 at 10 entries blocks exactly one wallet with pool rows (@seralberttrades, 3 of 3 pool tokens lost money) and hands back @fr3ak, whose pool contained hoodrat, the day's only live winner besides LIQLORACLE. Note that handlesDeny: ["frankdegods"] stays in the live config and is doing the frankdegods work regardless; at 0.18 his 0.154 rate no longer trips the dynamic rule, but all six of his rug signals are already refused by the ratio gate at 0.82/60.

If the priority is belt-and-braces over money, take 0.15@15 instead (class 2): it keeps the dynamic frankdegods block alive without the static deny list, costs only RF, and matches the money of the ratio-only setting exactly. It fails on hoodrat's cohort only because 15 entries is a high bar for a 40-wallet follow list.

5. Sensitivity, one threshold at a time

underAgeMin (ratio 0.80, wallet gate off). The whole rug story is here.

maxLiqToMcap (under 60, wallet gate off). Flat from 0.80 to 0.85, falls off a cliff at both ends.

At 0.90 the gate loses ZEP (0.895), PEZ (0.873) and PEZZED (0.862) and only holds SEPE, PEZZEL, PENZ.

maxWalletRugRate and minWalletEntries (under 20, ratio 0.80; the wallet-gate column is that gate's own attribution, on top of the ratio gate's constant 6 rugs / 0 runners).

The gate never adds a rug refusal once underAgeMin >= 20, because the ratio gate fires first on every rug row. minWalletEntries moves the answer far more than the rate does: 0.15 costs 8 runners at 8 entries, 7 at 10 and 1 at 15, with the rate held fixed.

maxAgeMin, one-dimensional, current Gold v2 filters otherwise (under 10, ratio 0.80, wallet gate off), against the no-age-ceiling pool of 671 rows / 153 tokens. Columns are that gate's own attribution.

The age ceiling is flat on Gold v2 between 45 and 120. Tightening 60 to 15 would have refused 20 extra rows worth -91.36 paper and -126.16 live, so on this tape it would have saved money, but it does so by refusing three more peak-60 names (AJC, CLANKSEN, PETOI) whose realised pnl was negative anyway. That is the positions lane's problem, not the entry gate's: do not move maxAgeMin on this evidence. The paperAny column is large only because it mixes non-Gold books over 123 tokens and should not be read as Gold v2 money.

6. The wallet gate at the recommended threshold

Every wallet blocked at maxWalletRugRate 0.18, minWalletEntriesForRugRate 10, with what it gave the pool. Rates are from data/watchtower/smartmoney.json as of 2026-09-06T07:33Z.

@seralberttrades is the only blocked wallet that touched the pool, and all three of its tokens lost money: the "2 runners lost" line in the Pareto table is +26.40 live and +31.30 paper in hand.

Wallets that clear 0.18@10 but would be blocked by the shipped 0.15@8, with what blocking them costs:

@AvgJoesCrypto is the case that should make anyone nervous about tightening this gate further: the wallet that handed us the tape's best name at +128.86 live also handed us two of the six rugs, at a 0.143 rate that no setting in the grid catches.

7. Caveats

Built 06/09/2026 22:00:01 Beirut. Source files under projects/crypto-2026-09/analysis-2026-09-06/.