For an exact-output sell (TEST in, IMD out, amountSpecified > 0), beforeSwap grosses the requested IMD output up by fee = requested * 0.75% / 99.25% and adds it to the signed amountSpecified to build the internal quote. Checked int256 addition overflows whenever amountSpecified > type(int256).max - fee, which means any amountSpecified above about type(int256).max / 1.00756.

PoolManager itself accepts such a swap: with a sqrtPriceLimitX96 it partially fills to the limit, and integrators use this pattern to mean "sell until price X". With this hook attached, the panic is wrapped by Hooks.callHook and the whole swap reverts. This breaks the brief's guarantee that the hook never reverts a real swap.

The exact-input-buy path is not affected, because _abs and the subtraction requested - fee stay in range for type(int256).min.

Fix: cap the grossed-up amount before converting it, e.g. compute it in uint256 and clamp it to type(int256).max (the quote then partial-fills at the price limit as before). Another option is to skip the gross-up when requested + fee would exceed int256.max, since such a request can only ever partial-fill.

The brief says nobody can change the fee flow. The hook itself has no admin, but the fee is always paid in IMD, and IMD (0x5F7Bb59365ce557C26dbcAa4EE9d39A4b95B7127) on Robinhood Chain is an owned LayerZero OFT. Its owner is 0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7, read on-chain at block ~94,404,141, and its bytecode exposes setBlocked(address,bool), blocked(address), enableTransfers()/transfersEnabled() and setV4Config(address,address,bool).

If that owner blocks SIMD_VAULT or COMPENSATION_VAULT, every take() to that vault reverts. _pay then mints an ERC-6909 claim, and redeemFees() keeps failing for as long as the block stays. The fees are not lost and cannot be redirected, since the claims stay with the hook for the fixed recipients, but their delivery can be held off indefinitely by a party outside the hook. The deferral fallback handles this correctly.

The point is that this trust assumption belongs in the README and the launch notes next to "no owner, no admin". Today both vaults return blocked = false, transfersEnabled() = true and poolManager() = 0.

beforeSwap grosses up an exact-output sell by adding the hook fee to the requested IMD output with checked int256 arithmetic. For requested >= ~0.9925 * 2^255 (fee/(D-fee) = 13,500,000/1,786,500,000 = 0.7557%, so requested + fee > 2^255 - 1) the addition panics with arithmetic overflow (Panic 0x11), which PoolManager wraps in Wrap__FailedHookCall, and the whole swap reverts.

The same request on a hookless pool is a legal v4 'take as much IMD as the price limit allows' exact-output swap: the pool loops until the limit and settles only the filled part. The symmetric buy boundary (amountSpecified = type(int256).min) is handled by _abs and tested (test_minimumSignedBuyBudgetChargesOnlyItsPartialFill), but the sell side has no equivalent guard, so the 'never reverts a real swap' guarantee is broken for max-request exact-output sells.

Boundary x precision seam: the overflow only appears at the top of the input domain and only in the IMD-specified sell branch; afterSwap-based modes are unaffected. No funds are at risk; a router that uses int256.max as a 'max' sentinel for an exact-output sell cannot trade through this pool.

Fix: compute the gross-up in uint256 and clamp it (e.g. to type(int128).max, already the largest delta v4 can return), or treat an overflowing request as a full-liquidity request.

The hook pays its fee with PoolManager.take inside beforeSwap/afterSwap, which moves IMD out of the manager while the swapper's unlock is still open. v4's settle() credits balanceOf(manager) - reservesOf(sync). A router that follows the pay-first pattern (sync(IMD), transfer input, then swap, then settle) therefore gets credited input - fee instead of input: the fee the hook took in between is subtracted from what the router is deemed to have paid.

The router's IMD delta ends at -fee, and the unlock reverts with CurrencyNotSettled (0x5212cba1). The identical router call succeeds on a hookless pool with the same key and liquidity. Boundary (external call) seam: _pay assumes a successful take is observationally neutral for the swapper; it is not for any caller whose sync precedes the swap.

Uniswap's own periphery routers settle after the swap and are unaffected, but the README's claim that the hook 'has no intentional restriction on valid swaps' and that fee delivery is 'handled by the claim fallback' does not cover this case, and nothing in the repository documents the ordering requirement.

Fix options: always mint the ERC-6909 claim during the swap and deliver only through redeemFees (the brief's 'sent to the SIMD Vault' is then satisfied by the permissionless redemption), or document that integrators must settle after swap. No funds are lost either way; the trade simply cannot execute through such a router.

The hook's safety argument ('never reverts a real swap', fee always lands in IMD) rests on IMD being a plain ERC-20. Read live at block 94,406,433 (chain id 4663), 0x5F7Bb59365ce557C26dbcAa4EE9d39A4b95B7127 is a LayerZero OFT whose runtime exposes setBlocked(address,bool), blocked(address), transfersEnabled(), enableTransfers(), setV4Config(address,address,bool) and poolManager(), owned by 0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7.

Today transfersEnabled() is true, poolManager() is zero and neither 0xbBa92992309C61E1c483ab630d0530F2C9edEDE7 nor 0x9f4419712cc22f615e393cC846b927BE3d7D802c is blocked, so the fork suite (run live, 50/50 pass) is representative now.

The hook already tolerates a blocked recipient (take fails, claim is minted, redeemFees retries), so that case is covered; what the code and README do not state is that IMD's owner can (a) block a vault, after which that vault's share accrues as a claim in the hook with no path but waiting for the unblock, and (b) via setBlocked on the PoolManager or setV4Config, stop IMD moving to or from the manager, which halts every swap in the pool independent of the hook.

No unprivileged amplifier exists, so this is a trust note for the author and deployer, not a defect to fix in the hook. The fork tests also use a freshly deployed PoolManager rather than the chain's real manager, so no test exercises IMD against whatever setV4Config may later gate.

The hook's whole value flow is denominated in the hard-coded IMD token.

On Robinhood Chain (chain id 4663) that address is not a plain ERC-20: it is a LayerZero OFT ('BridgedFP') with an owner (owner() = 0x047F606fD5b2BaA5f5C6c4aB8958E45CB6B054B7) and the privileged entry points setBlocked(address,bool), enableTransfers()/transfersEnabled(), and setV4Config(address poolManager,address,bool)/poolManager() (selectors extracted from the deployed runtime code; poolManager() is currently the zero address, transfersEnabled() is true, no address is blocked).

I exercised those powers on a fork of live state against the hook: (a) setBlocked(SIMD_VAULT,true) makes every PoolManager.take to the vault revert, so each swap's 0.75% is minted as an ERC-6909 claim (pendingVault grows, FeeDeferred) and redeemFees() cannot deliver it until the IMD owner unblocks the vault; the swap itself still succeeds, so the hook's deferral path behaves as designed.

(b) setBlocked(poolManager,true) or setV4Config(poolManager, , true) makes every IMD transfer to or from the PoolManager revert with 'BridgedFP: blocked' / 'BridgedFP: v4 transfer not approved', so every buy and sell on the TEST/IMD pool reverts at the trader's settlement or take, and any already-deferred fee can never be redeemed while the setting stands.

None of this is a bug in the hook's own code: its onlyPoolManager/onlyFactory guards hold, the fee math is symmetric across all four swap modes, and a failed take degrades to a claim rather than a revert.

It is a trust gap in the assurances around it: README.md and the manifest notes say 'nobody can change it' and that the fee 'is never swapped for ETH' and 'lands in the vault in IMD', the hook's NatSpec says 'IMD must be a standard, non-rebasing ERC-20', and the Robinhood fork suite deploys a fresh PoolManager, so IMD's v4-mode restriction (which keys on the configured poolManager) is never exercised against the real manager the factory will use.

The IMD owner, a third party to this launch, can therefore pause the pool, hold the vaults' fees as unredeemable claims, or require an approval the hook does not know how to obtain, and a reader of the deliverables is told the opposite. The author should state this dependency in the README/notes, and the launch rehearsal must trade through the real Robinhood PoolManager with IMD's live configuration (including the case where poolManager() is set) before the pool opens.

Merged from audit_flow. The hook charges only in beforeSwap/afterSwap and enables no liquidity callback, so anyone may mint an out-of-range position in the TEST/IMD pool.

An IMD-only position just above the current price is a resting buy order: every TEST seller that pushes the price through it converts the position's IMD into TEST at the range price, and the position owner then withdraws TEST having paid neither the 50%-to-0.75% anti-sniper levy (nothing reaches the CompensationVault) nor the standing 0.75% (nothing reaches the SIMD Vault); the mirror TEST-only position lets a holder sell to buyers without the 0.75% on sells.

The counterparty swapper still pays its own fee, so this is not a loss of existing funds; it is a gap between the brief's intent (every acquisition in the first 30 minutes pays the levy) and what a swap-only fee can enforce.

Recalibrated to low rather than the specialist's medium: the brief defines the fee on swaps and asks for no liquidity gating, the bypass needs willing sellers inside the window and carries range-order execution risk, and it is a property of every swap-fee hook rather than a defect in this code.

The author should either accept and document it, or (if the levy must cover LP-side acquisition) add beforeAddLiquidity gating for out-of-range deposits during the window while still letting the factory's zero-change fee collection through.

Merged from audit_economics and audit_math (same root cause). For an exact-output sell (TEST in, IMD out, amountSpecified > 0) beforeSwap grosses the request up by fee = requested * rate / (FEE_DENOMINATOR - rate) and adds it with checked int256 arithmetic. Whenever requested > type(int256).max - fee (about 0.9925 * 2^255 at the standing rate) the addition panics with 0x11.

PoolManager wraps the panic in WrappedError(hook, 0x575e24b4, Panic(0x11), 0xa9e35b2f) and the whole swap reverts, while the identical request on a hookless pool is a legal v4 'take as much IMD as the price limit allows' exact-output swap that partially fills. This breaks the brief's 'never reverts a real swap' guarantee for routers that use int256.max as an exact-output sentinel; no funds are at risk.

The buy-side boundary (type(int256).min) is handled by _abs and tested; the sell side has no equivalent guard.

Fix: compute the gross-up in uint256 and clamp the quoted amount (e.g. to type(int128).max or type(int256).max) before converting.

From audit_math; reproduced. _pay moves the fee out of the PoolManager with take() inside beforeSwap/afterSwap, while the swapper's unlock is still open. v4's settle() credits balanceOf(manager) - reserves recorded at sync(). A router following the pay-first pattern (sync(IMD), transfer input, swap, settle) is therefore credited input - fee instead of input, finishes the callback with an IMD delta of -fee, and PoolManager.unlock reverts with CurrencyNotSettled.

The same router call succeeds on a hookless pool. Uniswap's own V4Router/Universal Router settle after the swap and are unaffected, so the impact is integrator compatibility, not loss; but README.md says the hook has 'no intentional restriction on valid swaps' and nothing documents the ordering requirement.

Fix options: mint the ERC-6909 claim during the swap and deliver only through redeemFees (the brief's 'sent to the SIMD Vault' is met by the permissionless redemption), or document that integrators must settle after the swap.

Merged from audit_flow, audit_economics and audit_permissions (same root cause, three reports). The hook has no admin, but every fee is paid in IMD at 0x5F7Bb59365ce557C26dbcAa4EE9d39A4b95B7127, which on Robinhood Chain (chain id 4663) is an owned LayerZero OFT exposing setBlocked(address,bool), blocked(address), transfersEnabled()/enableTransfers() and setV4Config(address,address,bool)/poolManager().

Its owner can (a) block either vault, after which each swap's share is minted as an ERC-6909 claim (pendingVault/pendingCompensation grow, FeeDeferred) and redeemFees() cannot deliver it until unblocked, which the hook's deferral path handles correctly; and (b) block the PoolManager or set a v4 config that refuses it, which halts every buy and sell on the TEST/IMD pool independently of the hook.

No unprivileged amplifier exists and nothing can redirect the fee, so this is not a defect in the hook. It is a trust dependency the README and launch notes should state next to 'no owner, no admin', and the launch rehearsal should trade through the real Robinhood PoolManager with IMD's live configuration (the fork suite deploys a fresh manager, so IMD's poolManager()-keyed gate is never exercised).