afterInitialize binds the first IMD/LING pool it sees at fee 12500 whatever its tickSpacing or initializer. If a third party could initialize PoolKey(IMD, LING, 12500, tickSpacing 1, hook) between hook deployment and the factory's initialize, the launch pool (tickSpacing 60) would not be the bound pool: modules, sinks, _launchKey and the snipe window would belong to the stranger's pool, although the holder fee would still be charged on both (_isCharged checks the pair only).

This cannot happen on IMD: the verified LaunchFactory.launch() deploys the hook by CREATE2 and calls poolManager.initialize in the same transaction, and before the hook has code the PoolManager's beforeInitialize call fails the selector check. The 2026-10-10 audit records this as accepted; no change is requested. Noted so the adapter does not split deployment and initialization into separate transactions.

When IMD is the specified currency the holder fee is taken in beforeSwap on the full specified amount, so afterSwap refuses a swap whose pool delta is smaller than amountSpecified + fee (a price limit reached, or the pool's LING exhausted). The trade reverts rather than being charged on an amount that was never swapped. This is deliberate and commented, and it is not a module blocking a sell; it is intrinsic and applies to exact-out sells too.

Routers that use the MIN/MAX sqrt price limits only hit it when liquidity runs out.

Informational: expected behaviour for traders and integrators, not a launch blocker.

SwarmlingsMirror.transferFrom (and both safeTransferFrom overloads, which route through it) consult the fixed StrictAuthorizedTransferSecurityRegistry at 0xA000027A9B2802E1ddf7000061001e5c005A0000. Its verified source shows that for a collection with no configuration the policy is: a transfer where operator == from passes, otherwise the operator must be on list 0 (OpenSea's default operator list) or be the transiently authorized operator.

So a holder can move their own Swarmling, Seaport sales work, but a marketplace or custodian not on OpenSea's list cannot move an approved NFT until DEV, as the collection editor, changes the policy. LING transfers always move the NFTs regardless. The 2026-10-10 audit documents this (L-4) and test/fork/Validator.t.sol asserts exactly this behaviour on a mainnet fork.

Not a launch blocker; recorded for the site built afterwards.

SwarmlingsHook's runtime is 22,072 bytes (forge build --sizes), so its code deposit alone is about 4.41M gas at 200 gas per byte. A scratch Foundry deployment of the hook by CREATE2 with constructor arguments (manager, token) measured 4,482,988 gas, and pool initialize through beforeInitialize/afterInitialize 184,183 gas.

Adding the token with its mirror (about 3.8M per the docs), the MerkleDistributor, the LING transfers, the seed and the registry write, the whole LaunchFactory.launch() transaction is on the order of 11 to 12M gas, under the 16,777,216 cap IMD's preflight enforces. Informational for the deployer's gasCeilingWei check; the figure in the docs is stale, the hook has grown since it was written.

test/HookSalt.t.sol asserts the search length for six (deployer, manager, token) triples using fixed probe addresses, and passes (under 1,000 salts from the factory probe and from forge's default test contract with the probe manager and token). The CREATE2 address depends on the init-code hash, which includes the constructor arguments, so for any other manager or token address the count is an independent draw with mean 16,384.

In the scratch run above (forge test contract as deployer, a fresh PoolManager and a freshly deployed Swarmlings) the first 0x3FFF salt was number 13,889. This does not affect the mainnet launch: LaunchFactory takes hookSalt as a parameter mined off chain, and predictHook() lets the deployer check it before sending. It only matters if the protected floor mines with addresses other than the probes the test encodes.