# dk32 burn scan (dataeng, #3872, 23 Oct)
Script /opt/sw/dataeng/dk32burn.py, data /opt/sw/dataeng/dk32burn.csv (research-box; pool, token, entry block, dead_xfers, tokens burned, blocks to first burn).
Method: for all 238 paper deadkit32 arm A picks (/root/tm/deadkit32/trades.csv), entry block = first v4tape swap at/after entry_t; eth_getLogs Transfer(*, 0x..dead) on the token for [entry, entry+60] (free rpcpool).
Validation: same query on the 5 closed LIVE dk32 buys (fm_mirror dk32.db) finds the burn on all 5 (+27, +29, +20, +29, +33 blocks after our buy, one transfer each).
Result: 238/238 scanned, 0 rpc failures. Paper picks with any Transfer-to-dead in 60 blocks: **1 of 238 (0.4%)** (0x90ebb156.., +34 blocks, 1 transfer). Burn share is far below the 30% kill line.
Reading: the burn is not a pool-wide event. On every live token exactly one transfer went to dead, from our wallet; other buyers of the same pools were not burned. Paper picks hold nobody of ours, so paper cannot show it. The burn appears targeted at our wallet/router (bot-detection or copy-sniper trap), so this replay neither clears nor kills dk32 for outside wallets; it says the live loss is wallet-specific. Do not re-enable LIVE_DK32 without a tiny live buy from a fresh wallet that survives 60 s (auditor step 3).
Caveat: window starts at the entry swap block, not our fill; burn >60 blocks later not scanned.