_normalMode() declares fallback whenever block.number - lastBurnBlock > 50400, and lastBurnBlock starts at the deployment block (line 196). Burning is impossible until totalFees exceeds 1.64 ETH plus MIN_BURN, i.e. until about 82.1 ETH of fee-bearing volume; if that takes more than ~7 days (likely for a launch pool) the hook is in fallback when the first burn becomes possible even though POOL4 is healthy.

Fallback allows only the plain key, so burnIMD(true, ...) reverts Pool4Unavailable (line 389) and the only exit is a successful plain-pool burn. If the ETH/IMD 10000/200 hookless pool is not initialised on mainnet, burnIMD(false, ...) and pokeAnchor() revert PoolNotInitialized (line 601) and the post-cap fees sit as claims until a third party creates that pool - and the party with the strongest incentive to create it is the attacker of finding 1.

The same lock-out recurs after any week-long lull in which burnable stays under MIN_BURN. The brief states the rule literally and REVIEW.md item 11 accepts it, so this is a design observation with a liveness impact and no direct loss: it needs a decision, e.g. not counting the deployment block as a 'burn', or letting a healthy POOL4 reading re-open normal mode without a plain-pool burn.

Economics x asymmetry (paired-formula check from the Economic Security and Invariant guides). The brief says the hook keeps 2% of every trade on the ETH side. Three of the four swap modes do: exact-in buy charges 2% of the ETH paid in, and the two afterSwap modes charge 2% of the pool's gross ETH delta (line 323).

The exact-out sell mode is the odd one out: beforeSwap (line 300) and afterSwap (line 320) compute fee = amountSpecified * 200 / 10000 where amountSpecified is the NET ETH the seller asked for, and the pool is made to pay out amountSpecified + fee. The fee is therefore 2% of the net, which is 200/10200 = 1.9608% of the gross ETH the pool actually paid. The same token sale routed as exact-in pays 2.0000% of gross.

A seller who always submits sells as exact-out (any router lets them) keeps 0.039% of gross that the ledger should have collected, so totalFees reaches CREATOR_CAP later and the post-cap burn budget grows slower than the brief's 2% promises. Loss is bounded (0.04% of sell volume) and non-compounding, hence low.

Minimal fix preserving the spec'd PartialFill form (raw delta == amountSpecified + fee): for the exact-out sell branch compute fee = amountSpecified * SELL_FEE_BPS / (BPS - SELL_FEE_BPS) (i.e. * 200 / 9800), so that fee is exactly 2% of amountSpecified + fee; keep the exact-in buy as is (its base is already the gross input).

Design limitation, reported for the record (Economic Security: sandwich every price-dependent operation; the brief mandates this anchor behaviour so it is not a defect). In fallback mode (POOL4 closed, not answering, or no successful burn in 50400 blocks) the reference is the hook's own anchor, which anyone can step by up to 200 ticks toward the plain pool's current spot once per block via pokeAnchor().

The plain pool (ETH/IMD 1%, spacing 200, no hook) is permissionless, so an actor holding its price k2% away from fair for k blocks and poking each block moves the anchor k200 ticks. Once the anchor sits at the manipulated price, the 96%-of-quote(anchor) floor and the 150-tick guard are both relative to the manipulated level, so a burn can overpay by the full manipulation, up to the whole 0.01 ETH fallback batch, every 5 blocks.

At today's mainnet depth (plain pool active liquidity 0x1bf6b3b3113b6518e98 ~ 8.26e21, ~411 ETH of virtual ETH at tick 60002, 1.1% round-trip fees) moving the price 2% costs ~0.09 ETH in fees per block, far more than the 0.0002-0.01 ETH extractable per burn, so it is unprofitable now; it becomes marginal only if the plain pool thins to well under ~1 ETH of depth.

Normal mode does not have this exposure beyond the brief's intended 4% (0.002 ETH on a 0.05 ETH batch) because POOL4.refTick() is maintained by the CappedBurnHook and only follows the previous block's close.

Dependency failure that permanently blocks a claim (Economic Security: break dependencies). Already documented in README 'Who holds the medallion', so this is a recorded trust assumption, not a new defect.

Verified on mainnet today (2026-10-01): Nouns ownerOf(447) = 0xb1a32FC9F9D8b2cf86C068Cae13108809547ef71, which is neither CREATOR nor the deployer. retire() is the only path that releases CREATOR_CAP, and it requires transferFrom(owner, DEAD, 447) to succeed, i.e. that holder (or whoever holds it later) must approve(hook, 447) or setApprovalForAll.

If they never do, or if the token is ever burned (ownerOf reverts -> MedallionUnavailable), the first 1.64 ETH of fees is unreachable by anyone: burnable() excludes creatorEntitlement(), so burns cannot touch it either. The hook keeps working for everything above the cap. No code change is consistent with the brief; the author should make sure the requester understands the payment is at the medallion holder's discretion.

Flow gap (execution x first principles), literal to the brief and documented in README 'The stale rule is literal', so recorded as an operational note rather than a defect. lastBurnBlock starts at the deployment block and only a successful burn refreshes it.

Reaching the cap needs 82 ETH of fee-bearing volume, which for most launches takes longer than 50400 blocks (~7 days), so when burnable() first exceeds MIN_BURN the hook is already in fallback: burnIMD(true) reverts Pool4Unavailable even with POOL4 healthy, and the only way out is one successful burnIMD(false) of 0.01 ETH on the plain pool against the anchor seeded at deployment.

If IMD has appreciated since deployment the anchor sits above spot by more than 150 ticks and the burn reverts PriceOffReference until pokeAnchor() has been called once per block for ceil(gap/200) blocks.

Today the plain pool is initialized with active liquidity ~8.26e21 (verified on mainnet), so the exit exists; if that pool were ever drained below what a 0.01 ETH buy needs to clear the 96% floor, the hook could not return to normal mode and no POOL4 burns would ever happen until someone re-seeds the plain pool.

Periphery x first principles note from checking the token behaviour the burn flow assumes. Sourcify holds an exact match for mainnet 0xD34a...63B7: contract BridgedFP is OFT (LayerZero oft-evm) with updateName/updateSymbol onlyOwner and the standard OFT _credit path by which the endpoint mints on inbound bridge messages. symbol() currently returns 'IMD' and decimals 18, matching the brief.

Relevant to this hook: the token has plain OpenZeppelin ERC-20 transfer semantics, no fee on transfer and no blocklist, so poolManager.take(IMD, DEAD, amountOut) delivers exactly amountOut and imdBurned is exact (the Invariant guide's assumed-vs-received check holds).

What the hook cannot guarantee is the first-principles meaning of 'burn': tokens sent to 0xdEaD are removed from circulation on mainnet but the bridged supply can be re-minted on this chain by the bridge, and the token's metadata can be changed by its owner. No change is possible inside the brief (the address is a required constant); flagged so the README's 'buys $IMD and sends it to the dead address' is read with that context.

Seam: access x asymmetry. _stepAnchor() moves the anchor at most once per block and returns the stored anchor unchanged for every later caller in the block (line 582). In fallback mode burnIMD() takes its reference from that same call (line 405), so whoever pokes first decides the reference every burn in the block is judged against, while the burn's spot is read live.

A griefer who sees a burnIMD() transaction sells IMD into the plain pool to lift the spot >= 200 ticks, calls pokeAnchor() (anchor +200), and buys back; the spot is where it was but the burn now sees spot < anchor - 150 and reverts. Repeating this each block, at the cost of the 1% LP round trip (zero when the griefer is the pool's LP) and gas, keeps every fallback burn reverting and the post-cap fees unspent.

No funds are lost and the honest burn succeeds in any block the griefer skips, hence low.

Fix: do not let a same-block poke pre-empt the burn's own observation (compute the burn's reference from the anchor as it stood at the start of the block, or let burnIMD() step from the stored anchor regardless of anchorBlock), and refuse pokes while the manager is unlocked.