snipeBps() is 4000 in the block the launch pool is initialized and falls to 0 over 60 s. _quote adds it to every buy on a charged pool regardless of who the swap's sender is.

The hook exempts its deployer (launcher, the IMD launch factory) from the JIT penalty but not from the snipe tax, so if the factory performs a seed buy of LING with the payer's IMD inside the launch transaction (the same block as afterInitialize), 41.25% of that IMD (1.25% holder fee + 40% snipe) is minted as holder claims to the hook instead of buying LING.

At that moment no Swarmling NFT exists, so the amount is queued and paid to whoever holds NFTs the next UTC day; it is not lost to the system, but it is not the payer's LING either. If the factory does not swap inside the launch transaction, this has no effect on the launch and is only the designed sniper deterrent. The adapter should confirm which it is.

Nothing to change in src if no seed buy is made.

The token mints one Swarmling per 300,000 LING received by any address without code (and 7702 wallets) and only switches the receiver to skipNFT when a single transfer would mint more than 800. Measured on this tree: a 100,000,000 LING transfer to a fresh EOA (333 NFTs) costs 4,130,937 gas; 240,000,000 LING (800 NFTs) costs 9,541,938 gas; 240,300,000 LING (801, auto-skip) costs 114,329 gas.

Creation of the token with its mirror is about 4.3M and of the hook about 4.6M (creation code 22,432 and 23,469 bytes).

The manifest asks for poolBps 9000 so that no allocation reaches an EOA, but the remaining 10% follows the launch policy's split: if any of it is transferred to an address without code inside the launch transaction, the transaction grows by the figures above (a 10% EOA treasury adds 4.13M, bringing the launch to roughly 14M against the 16,777,216 EIP-7825 cap and whatever gasCeilingWei the policy sets).

Contract recipients (lock, treasury contract, PoolManager, factory) skip NFTs and are unaffected. No change to src requested; the adapter should check the policy's recipients.

The CREATE2 address depends on keccak256(creationCode ++ abi.encode(manager, token)). test/HookSalt.t.sol bounds the search for four (deployer, manager) combinations, all with the probe token 0x70ce.

For any other token address the number of salts until the low 14 bits are all set is a fresh geometric draw with mean 16,384 (P(> 57,357) is about 3%), so the tuning holds for the floor only if the floor really substitutes 0x70ce for the token, as the test assumes; a floor that deploys the real token first and mines against its address gets no benefit from BUILD_TAG and could hit the same MemoryOOG as launch 1954. The deployer's own off-chain salt mining is unaffected.

The constant itself is behaviour-free (a public constant getter; validated by all 240 tests).

Informational: nothing in src to change; the adapter should confirm the floor's probe addresses against the test's constants (0xfac7, 0x900c, 0x70ce, factory 0x12C63b58..., manager 0x0000...8A90).

Commit 69b2407 moved AddressData.balance to the low 96 bits of its slot and gave totalSupply its own slot so forge-std deal can set LING.

The reorder is behaviour-neutral (no assembly reads the struct by offset: grep of sload/sstore in DN404.sol shows only the Uint32Map/Bitmap helpers, and all 240 tests pass), but the balance slot is still packed: bits 96..127 hold ownedLength, 128..159 addressAlias, 160..167 flags (skipNFT, initialized), 168..255 aux. forge-std 1.17's stdstore masks packed fields, so deal(ling, holder, x) on this tree only writes the balance (test_dealWritesLingBalanceAndSupply).

A verifier that writes the full slot (older forge-std, or vm.store on the located slot) on an address that already owns NFTs would zero ownedLength and flags, after which that address's NFT count and skipNFT state disagree with its balance. Informational for the verifier and the adapter; nothing to change in src or lib (lib is read-only for this launch).

The launch rules list anything configured after deployment as a medium finding for the adapter to remove. Here the hook is a router by the requester's specification: SwarmlingsCouncil (verified on chain at 0x4d0b3507D80f678d9e658Fd5482Ca6a96636A032 with owner() == DEV 0x92cEf4823119f3332A85A39023eEbA01a06890c4) may set at most 8 slices totalling at most 375 bps on top of the fixed 125 bps holder floor, at most 8 modules, and may hand over or freeze the council.

The bounds are constants; the code paths were reviewed: no slice or module can block a sell or a liquidity removal (observers are gas-capped raw calls with no return-data copy; guard reverts are bubbled only on buys, adds and donates), a quoter's answer is clamped before it is added, sinks spend only their own ERC-6909 claims, setSlices rejects the hook and the token as sinks.

There is no proxy, initializer, DELEGATECALL, CALLCODE or SELFDESTRUCT in src or the vendored DN404, no mint after construction, no pause, freeze, blacklist or seizure. Recorded as informational because the assignment and the audit report accept this design (C-3 / C-4 accepted); no change requested.