launchedAt is set in afterInitialize, and snipeBps() returns 4000 while block.timestamp == launchedAt. If IMD's launch factory performs a seed buy in the same transaction that initializes the pool, that buy pays 40% + 1.25% of its IMD to the hook's holder claims instead of to the pool, and if the factory's seed buy enforces a minimum output derived from the opening price, the launch transaction reverts.

No holder exists at that moment (factory, PoolManager and the 10% remainder recipient are contracts with skipNFT), so the money is queued for the first NFT holders. This is the requested behaviour (task: 'a 60-second launch snipe tax on buys falling from 40% to 0') and is covered by test_snipeTaxDecaysOverTheFirstMinute; it is reported so the adapter checks that the factory does not swap inside the launch transaction with a slippage floor.

Every holder fee (1.25%) and snipe tax taken before the first wallet holds 300,000 LING is handed to the token and queued. _advance sends time with nfts == 0 back to the queue, so the whole pre-holder pot is paid during the next epoch to the NFTs that exist then, per second held. A single first buyer who holds one NFT alone for the day receives it all.

This is the designed day-by-day ledger (test_feesWithNoHoldersWaitForTheFirstNft) and cannot break the launch; it is noted because it concentrates the launch-window tax on the earliest holders rather than losing it.

With poolBps 9000 the factory keeps 10% of the supply out of the pool. If any part of that remainder is transferred to an EOA (or an EIP-7702 wallet) in the launch transaction, DN404 mints one NFT per 300,000 LING right there: 100,000,000 LING is 333 NFTs, about 4.0M gas at the measured 12.1k per NFT, on top of about 4.3M (token + mirror creation) and 4.6M (hook creation), close to 13M of the 16,777,216 EIP-7825 cap before the factory's own work.

The 800-NFT auto-skip does not trigger at 333. docs/OPERATIONS.md step 4 records the same number and the manifest states nothing goes to the requester; the adapter should confirm the remainder's recipient is a contract (skipNFT by default) or budget the gas.

When the reward currency is the specified side, the fee is charged in beforeSwap on the full specified amount, and afterSwap refuses a swap whose pool delta does not equal amountSpecified + fee, i.e. a swap that hit sqrtPriceLimitX96 or ran out of liquidity. That is correct accounting (otherwise the fee would be charged on IMD never swapped), and the alternative paths (exact-out buys, exact-in sells) never revert.

But it means the hook, not a module, can refuse an exact-out sell: a seller who asks for a fixed IMD amount with a price limit the pool reaches reverts instead of receiving a partial fill. Routers that use MIN/MAX limits are unaffected, and a full-range launch position never runs dry for exact-in. Documented by test_partialFillRevertsWhenFeeWasTakenUpFront; informational for this launch.

setSlices, setModules, disableModule and setCouncil are configured after deployment by COUNCIL (0x4d0b3507...A032, owner 0x92cEf482...90c4, verified live) with no delay.

Within the fixed limits the council can at any time: raise the fee on every IMD/LING swap from 1.25% to 5.00% (sum of slices <= 375 bps, plus quoter extras clamped so total <= 500 bps), route the 3.75% to any sink contract it names, and attach guard modules that revert any buy, liquidity addition or donation (never a sell, a removal or a swap at depth > 0).

The holders' 125 bps, the hand-over path, the snipe tax and the sell/removal guarantees are constants and were re-verified in code. This is the trust model the requester chose and the audit records as accepted (C-3, C-4), so no change is requested; it is listed because the reference asks that configuration outside a constructor be named.

launcher = msg.sender of the hook constructor; the exemption compares it with the PoolManager's msg.sender for the position.

If IMD's factory deploys the hook through an intermediate CREATE2 deployer contract, or adds/collects the launch position through Uniswap's PositionManager, owner != launcher and the factory's zero-liquidity collects inside 10 blocks of the launch block forfeit part of their IMD fees to holders (10/10 in the launch block, falling to 1/10 in block +9, 0 from block +10).

Principal is never touched and no call reverts. test/Launcher.t.sol asserts the direct pattern (factory deploys the hook and calls the PoolManager itself), which is what the verifier described; the adapter should confirm it against the real factory.

A wallet whose balance would mint more than 800 NFTs beyond what it holds is switched to skipNFT and gets no NFTs (the requested behaviour). To mint later it must call setSkipNFT(false) and transfer to itself, but the self-transfer path recomputes mint from the whole balance, so a wallet holding 1,000 units and 0 NFTs is auto-skipped again. It must first move at least 200 units to another wallet (or mint there) so the gap is <= 800.

Not launch-breaking; the site's 'enable NFTs for contract wallets' flow should explain this to whales.

Verified against the live registry at 0xA000027A...0000 (eth_call from an unregistered collection address at block 26203918): validateTransfer(owner, owner, to, 1) returns; validateTransfer(randomOperator, owner, to, 1) reverts StrictAuthorizedTransferSecurityRegistry__UnauthorizedTransfer.

Seaport authorizes itself transiently before calling transferFrom, so OpenSea sales work; other marketplaces or custody contracts that call mirror.transferFrom as an approved operator fail unless OpenSea's registry authorizes them. Transferring 300,000 LING moves the NFT regardless, so holders are never locked out, and the ERC-2981 fee is only enforced on the mirror path. Audit L-4 and test/fork/Validator.t.sol already record this; informational.

Swarmlings does not override _givePermit2DefaultInfiniteAllowance (lib/dn404/src/DN404.sol returns true), so 0x000000000022D473030F116dDEE9F6B43aC78BA3 may transferFrom any holder without an approve unless the holder sets an explicit allowance for it. This is DN404's documented default and what the Universal Router relies on, and the audit records it as a trust assumption (E-5).

Listed so the frontend's 'buy on Uniswap' link does not add a redundant approve step and users are not surprised.

The 1.25% is a property of pools whose PoolKey names this hook. Anyone can initialize LING/IMD or LING/ETH pools on the PoolManager with hooks = address(0) and trade fee-free; this is inherent to Uniswap v4 and to the design ('1.25% hook fee in IMD to holders on every LING / IMD pool using the hook'), and liquidity depth at launch sits in the hooked pool. Informational.