Asymmetry between the two branches of beforeSwap/afterSwap. When ETH is the specified currency (exact ETH in buy, exact ETH out sell), fee = 1% of |amountSpecified|, which is the user's gross budget (buy) or net receipt (sell), not the ETH the pool traded (|amountSpecified| - fee on buys, |amountSpecified| + fee on sells). When ETH is unspecified (afterSwap line 172, fee = _fee(_abs(int256(delta.amount0())));), the fee is 1% of the pool's executed ETH.

The brief says fees are computed on the amount actually traded. So for an identical pool trade, exact-input buys pay 1.0101% of traded ETH and exact-ETH-output sells pay 0.990%, while the other two modes pay exactly 1%. Any trader can pick the cheaper mode: sells via exact ETH output underpay the recipient by about 1 bp of volume, and buys via exact ETH input overcharge users by about 1 bp.

Low impact, but it breaks the stated fee basis and the two branches are not symmetric.

Fix: for ETH-specified swaps, charge fee = mulDiv(|amountSpecified|, 100, 10_100) on exact-ETH-input (so fee is 1% of the traded remainder), and fee = mulDiv(|amountSpecified|, 100, 9_900) on exact-ETH-output, or the equivalent; then update the expected check at line 166 to match.

Numerical-gap seam (boundary x invariant). The brief's invariant is one fee: 1.0% of the ETH side, computed on the amount actually traded. The hook uses two different bases depending on which currency the router specifies.

When ETH is specified (buy with exact ETH input, sell with exact ETH output) the fee is mulDiv(|amountSpecified|, 100, 10000), i.e. 1% of the trader-side ETH figure (gross budget on a buy, net proceeds on a sell), while the AMM actually trades amountSpecified +/- fee. When IMD is specified the fee is 1% of delta.amount0(), the ETH the AMM actually traded.

Consequences, measured on a 1000-ether-liquidity 0.3% pool at price 1:1 (test/scratch probe): a buy paying gross 1.014053170522578748 ETH receives 1.000000000000000000 IMD with fee 0.010040130401213650 ETH in exact-IMD-output mode, but only 0.999900099990010000 IMD with fee 0.010140531705225787 ETH in exact-ETH-input mode: same gross ETH, 100,401,304,012,137 wei more fee and 99,900,009,990,000 wei less IMD.

On the sell side an exact-IMD-input of 1 IMD yields net 0.986046911229504184 ETH with fee 0.009960069810399032, whereas requesting that same net ETH as exact output charges fee 0.009860469112295041 and costs only 0.999899900309979939 IMD. So the exact-ETH-input fee is 1/99 = 1.0101% of the ETH the AMM traded, the exact-ETH-output fee is 1/101 = 0.990% of the ETH the AMM supplied, and only the two token-specified modes pay exactly 1.00% of traded ETH.

The README documents the gross/net convention, so this is a documented design choice with a ~1%-of-fee magnitude, not a loss-of-funds bug; it is reported because it contradicts the literal requirement 'computed on the amount actually traded' and makes the effective rate depend on router mode.

Fix preserving design: in beforeSwap for exact ETH input compute fee so that fee == 1% of (A - fee), i.e. fee = mulDiv(A, 100, 10100); for exact ETH output fee = mulDiv(A, 100, 9900) so fee == 1% of (A + fee); keep afterSwap's expected = amountSpecified + fee check unchanged.

Boundary input not covered by _validateKey: key.fee == LPFeeLibrary.DYNAMIC_FEE_FLAG (0x800000). v4's Hooks.isValidHookAddress allows a dynamic-fee pool on any hook with flags, and PoolManager.initialize stores lpFee = 0 for it. Only the hook may later call updateDynamicLPFee or return an override from beforeSwap; LilyGuard does neither (it returns lpFeeOverride 0 without the override flag), so the pool runs with a 0 LP fee forever while the hook's 1% fee still applies.

Since initialization is permissionless and all state is per PoolId, this does not hurt the creator's own pool, but a creator or storefront that picks the dynamic flag by mistake gets a pool that pays LPs nothing.

Verified: initializing (ETH, IMD, 0x800000, 60, hook) at 2^96 succeeds, getSlot0 reports lpFee 0, a 1 ETH exact-input buy returns 989020869339354039 IMD (no LP fee) with the hook fee charged. Optional hardening consistent with the design: revert in beforeInitialize when key.fee.isDynamicFee().

_validateKey checks currency0, currency1 and hooks but not key.fee. v4 accepts the sentinel fee 0x800000 (LPFeeLibrary.DYNAMIC_FEE_FLAG) for any pool whose hook address has at least one flag, and PoolManager.initialize stores lpFee = 0 for it (getInitialLPFee). LilyGuard implements no dynamic-fee logic: beforeSwap returns lpFeeOverride 0 without the override bit, and nothing ever calls updateDynamicLPFee.

Because initialization is permissionless (any sender, any fee tier), an ETH/IMD pool keyed with the dynamic flag is registered by the hook, gets its own PoolId, pause state and fee claims, and then executes every swap with a zero LP fee while still charging the 1% hook fee.

LPs who provide to that pool (for example because a storefront or integrator lists it as the hook's pool) earn nothing, and the pool is not distinguishable from a static-fee pool through the hook's own views (token/paused/pendingFees). The brief leaves the LP tier to the creator, so this is a missing guard rather than a loss path; the fix is to reject key.fee.isDynamicFee() in _validateKey (or implement the dynamic fee).

Verified with a scratch test: initialize(PoolKey(ETH, IMD, 0x800000, 60, hook), 2**96) succeeds, getSlot0 returns lpFee == 0, and a 1 ETH exact-input buy on it returns more IMD (989020869339354039) than the same buy on the 3000-fee pool (986056732423396135) while still paying the 0.01 ETH hook fee.

The brief says the fee is 1.0% of the ETH side and is computed on the amount actually traded. For the two token-specified modes afterSwap uses the executed AMM delta (fee = E/100, exactly 1% of the pool leg).

For the two ETH-specified modes beforeSwap and afterSwap use |amountSpecified| instead: an exact-input buy of A pays fee A/100 while the AMM only trades A - A/100, i.e. 1.0101% of the ETH actually traded; an exact-output sell of A pays A/100 while the AMM supplies A + A/100, i.e. 0.990% of the ETH actually traded.

The same ETH leg through the pool is therefore charged three different rates depending on which side the router specifies, which lets a router pick the cheaper mode for sells (exact-ETH-output) and makes the recipient's income depend on routing rather than on volume.

The README documents this convention, so it is a deviation from the brief's wording rather than a loss; the fix is to base the specified-ETH fee on the executed delta (fee = |delta.amount0()| * 100 / 10_000 of the AMM leg, i.e. charge mulDiv(A, 100, 10_100) on exact input and mulDiv(A, 100, 9_900) on exact output, or document the chosen basis as accepted).

The search is correct (CREATE2 preimage 0xff ++ deployer ++ salt ++ keccak(initcode), 85 bytes; the shl(248, 0xff) / shl(96, address()) operands are in the right Yul order, so the aderyn incorrect-shift-order lead is a false positive) and the salt is the first match from zero, but it is unbounded by design and the number of candidates is 2^14 on average.

Measured by deploying the exact launch init code (manager 0x8366..., owner and recipient 0x5Bff...) through a CREATE2 factory at five factory salts: hook salts 55178 / 5980 / 4247 / 36480 / 51201 cost 8,395,946 / 2,196,998 / 1,978,640 / 6,039,998 / 7,894,844 gas for the whole deployer constructor including the hook creation.

The deployment service checks the simulated cost against gasCeilingWei, so a launch whose factory address and salt happen to need >55k candidates (about 3%) is refused or runs out of gas rather than losing funds; the salt depends only on the deployer's address and the constructor arguments, so the simulation is exact. Not a defect against the brief, which mandates the increment-from-zero search; recorded so the gas ceiling is set with this distribution in mind.

Area: Flow Gap (execution x first principles) and Invariant (interface guarantee). _validateKey only checks the two currencies and the hook address; it does not reject key.fee == 0x800000 (LPFeeLibrary.DYNAMIC_FEE_FLAG). v4 initializes a dynamic-fee pool with lpFee = 0 (PoolManager.initialize -> getInitialLPFee) and expects the hook to call updateDynamicLPFee or return an override fee from beforeSwap.

LilyGuard never calls updateDynamicLPFee and beforeSwap always returns lpFeeOverride = 0 (line 146), which has no OVERRIDE_FEE_FLAG, so the stored 0 fee is used on every swap forever. Every ETH/IMD pool opened on this hook with the dynamic flag therefore pays liquidity providers nothing while the hook still takes its 1% ETH fee and the README promises the pool's 'chosen valid v4 fee' is honoured untouched.

The brief says the hook does 'exactly the following, and nothing else' and that the creator initializes with a valid fee; a fee tier the hook can never service is not a valid configuration for this hook, and the hook is the only party able to refuse it at initialization.

Impact is bounded to the LPs of a pool whose creator (or anyone, since initialization is permissionless and the ID is public) opens it with that flag; a creator who then seeds liquidity under that ID earns no swap fees.

Fix: in _validateKey (or beforeInitialize) add || key.fee.isDynamicFee() to the revert condition (LPFeeLibrary), so only static-fee ETH/IMD pools register.

Area: Economic Security / Invariant (path divergence: two routes to the same AMM execution produce different fees). The brief says 'Fees are computed on the amount actually traded'. For an exact-ETH-input buy the hook computes the fee on params.amountSpecified (line 145 in beforeSwap, again at line 163 in afterSwap), returns it as the specified beforeSwap delta, and the AMM then trades amountSpecified minus fee.

So the fee is 1% of (traded + fee) = 1.0101% of the ETH the pool actually traded. For an exact-IMD-output buy that makes the pool trade the same gross ETH, afterSwap computes the fee on delta.amount0() (line 172), i.e. exactly 1% of the traded ETH. Symmetrically, an exact-ETH-output sell is charged 1% of the net output while an exact-IMD-input sell is charged 1% of the gross AMM output.

Two swap modes that produce byte-identical AMM executions (same raw Swap event amounts, same IMD out, same price impact) therefore charge different hook fees, so '1.0% of the ETH side' is not one number and the exact-ETH mode overcharges relative to the brief's 'amount actually traded' by fee/100.

Loss per trader is 1 basis point of the trade (0.0001 ETH per 1 ETH), does not compound, and is documented in the README table, so this is a specification deviation rather than an exploit; a router can already pick the cheaper mode.

Fix: for ETH-specified swaps compute the fee on the amount the AMM will actually trade, e.g. fee = mulDiv(A, 100, 10100) for exact input (so traded = A - fee and fee == 1% of traded, rounding down) and fee = mulDiv(A, 100, 10000) is already 1% of the net output for exact output if net is the intended base; or state in the brief that the base is the trader-side amount and leave the code.

Merged from audit_flow, write_foundry_tests, audit_permissions, audit_economics and audit_math (same root cause). beforeSwap (line 145) and afterSwap (line 163) compute the fee on |params.amountSpecified| whenever ETH is the specified currency.

The positive beforeSwap specified delta then changes the ETH leg the AMM executes: an exact-ETH-input buy of A pays fee A/100 while the pool trades A - A/100 (fee = 1.0101% of the executed ETH), and an exact-ETH-output sell of A pays A/100 while the pool supplies A + A/100 (0.990%). The two token-specified modes (line 172) use delta.amount0(), i.e. exactly 1% of the ETH the AMM traded.

The brief states one rate, '1.0% of the ETH side', 'computed on the amount actually traded'; the hook produces three effective rates depending on which side the router specifies, so a router can pick the cheaper mode on sells (exact ETH output) and an exact-ETH-input buyer pays about 1 bp of volume more than a buyer requesting the identical IMD output.

The README documents the trader-side convention, and the discrepancy is bounded to 1% of the fee and never compounds, so this is a specification deviation rather than a loss path: low. Fix preserving the design: for exact ETH input use fee = mulDiv(A, 100, 10_100) (so fee == 1% of A - fee), for exact ETH output fee = mulDiv(A, 100, 9_900) (so fee == 1% of A + fee); the afterSwap expected = amountSpecified + fee check stays valid.

Merged from audit_flow, audit_economics and audit_math. _validateKey checks currency0, currency1 and hooks but not key.fee. Hooks.isValidHookAddress allows fee == 0x800000 (LPFeeLibrary.DYNAMIC_FEE_FLAG) on any hook with flags, and PoolManager.initialize stores lpFee = 0 for it (getInitialLPFee). LilyGuard never calls updateDynamicLPFee and beforeSwap returns lpFeeOverride 0 without the OVERRIDE_FEE_FLAG (line 146), so the stored 0 is used on every swap forever.

Because initialization is permissionless and the key is public, anyone can register (ETH, IMD, 0x800000, spacing, hook) under this hook; it gets its own PoolId, pause state and fee claims, is indistinguishable through the hook's views from a static-fee pool, and LPs who provide to it earn nothing while the hook still takes 1% of the ETH side. A creator choosing a dynamic tier because the hook looks like a fee hook gets a pool the hook can never service.

Bounded to LPs of a pool opened with that flag, and the creator can equally choose a static 0 fee, so low.

Fix: revert in _validateKey when key.fee.isDynamicFee() (LPFeeLibrary), or implement the dynamic fee.

From audit_flow, re-measured. The search is correct: the 85-byte CREATE2 preimage (0xff ++ address(this) ++ salt ++ keccak(initcode ++ args)) is laid out correctly, shl(248, 0xff) / shl(96, address()) have the operands in Yul order (the aderyn incorrect-shift-order lead is a false positive), and the salt is the first match from zero as the brief mandates.

Fourteen address bits must match, so the expected number of candidates is 16384 and the tail is geometric: about 3% of deployer addresses need more than 55k candidates (over 7M gas) and about 0.2% need more than 100k (over 13M).

The deployer's address, and therefore the salt and the gas, are fixed by the factory address and the launch number, so the deployer service's simulation against gasCeilingWei is exact; a launch that lands in the tail is refused or runs out of gas rather than losing funds. Not a defect against the brief, which requires the increment-from-zero search; recorded so the gas ceiling is set with this distribution in mind.

Initcode is 8,320 bytes and LilyGuard's runtime 6,629 bytes, well inside the 49,152 / 24,576 limits.