I've built SwapSizeCapHook. forge build, forge test (23 of 23 pass) and forge fmt --check all pass after a forge clean. Nothing is committed: git has no author identity set here, and setting one would mean writing .git/config, which is off-limits. All the files are staged.

What it does

• In beforeSwap, the hook reverts with SwapTooLarge(poolId, amount, cap) when the swap amount is larger than liquidity * CAP_BPS / 10_000. Liquidity is read from the PoolManager each time. This applies in both directions and to both exact-input and exact-output swaps.
• The fraction is set once at construction and can't be changed. 1_000 basis points gives the one-tenth cap; values outside 1–10_000 are rejected.
• Every callback, including ones the hook doesn't use, reverts unless the caller is the PoolManager. sender and hookData are ignored, so no caller can get around the cap.
• The hook stores nothing, so pools can't affect each other. It has no liquidity callbacks, so it can't stop LPs from adding or withdrawing.
• There is no owner, setter, pause or upgrade path, and no DELEGATECALL or SELFDESTRUCT.

Where things are

• src/SwapSizeCapHook.sol: the hook.
• src/HookFlags.sol: permission-bit helpers. The protected test imports this file.
• test/SwapSizeCapHook.t.sol and test/mocks/MockERC20.sol: the tests. They run against a real v4-core PoolManager through its standard test routers.
• README.md: design, assumptions, deployment parameters and operator responsibilities.
• foundry.toml and remappings.txt: config, set to work offline with ffi off.
• lib/: v4-core, solmate and forge-std copied in as ordinary files at pinned commits, listed in lib/VENDORED.md. From v4-core I kept only the source plus one test helper its routers need.

What the tests cover

• A swap exactly at the cap succeeds and one unit over reverts, for both directions and both swap types.
• A fuzz test checks the cap boundary with random amounts.
• A rejected swap leaves the pool price unchanged.
• The cap grows and shrinks as liquidity is added and removed, and an LP can withdraw everything, after which every swap reverts.
• Liquidity outside the current price range doesn't count towards the cap.
• Two pools on one hook keep separate caps.
• Direct calls that don't come from the PoolManager are refused, and sender or hookData give no exemption.
• The largest possible negative amount doesn't overflow.
• The hook refuses bad constructor values and refuses to deploy at an address carrying the wrong permission bits.

Protected suite: I ran Hook.protected.t.sol in test/scratch/ against the real creation code, with flags set to 128 (BEFORE_SWAP) and one tenth as the fraction. All 3 tests pass. The token suite skips itself because there's no token.

Decisions and limitations

• No dynamic fee. The task only asks for that check where the design needs a dynamic fee, and this one doesn't. So there's no afterInitialize check and the hook works with any fee tier. The protected test itself uses a fixed 3000 fee.
• Units don't match. As specified, the cap compares a token amount with the pool's liquidity figure, which is not a token amount. The resulting limit only works out to roughly 10% of reserves in one case: price near 1, liquidity spread across the full range, same decimals. Otherwise it can be much tighter or looser, so the fraction should be chosen per pool. The README explains this.
• Easy to get around. The cap is per swap, so a trader can split one large trade into several swaps. Someone can also add liquidity just before a swap to raise the cap, then remove it. The README says so.
• Compiler must be present. The offline verifier needs solc 0.8.26 already installed; a compiler can't be committed to the repo. I had to download it once to build here.
• Not audited. Passing tests are not a security audit, and an independent review is advisable before real use.

I found no high or medium defects, and I wrote two lower-severity findings to .imd-findings.json. I didn't edit any other file.

The 23 tests in test/SwapSizeCapHook.t.sol pass locally. I read src/SwapSizeCapHook.sol and the protected hook test. I didn't read the protected token test past its list of checks, because the hook has no token.

What I checked and found sound:

• Every callback uses onlyPoolManager, including the undeclared ones, which then revert with HookNotImplemented.
• The absolute value of amountSpecified handles type(int256).min without overflow, and the same check applies to exact-input and exact-output swaps in both directions.
• The permission flags match the address bits: only beforeSwap is declared, and the constructor validates it.
• The hook keeps no per-pool state and has no owner or admin, and LP exits are unaffected because no liquidity callbacks are used.
• sender and hookData are ignored.
• No afterInitialize dynamic-fee check is needed, since this design doesn't use a dynamic fee.

Findings, ranked:

1. Low: the cap reads only current in-range liquidity. When the price sits in a range with zero liquidity, or liquidity below 10, the cap is 0 and every swap reverts, so the pool can't be traded back into a range that has liquidity. For example, a single position on [60,120] with the pool initialized at tick 0 rejects a 1-wei swap. This follows the spec literally, so I marked it a liveness limitation rather than a bug.
2. Info: the cap compares a token amount against liquidity in sqrt(xy) units, and it applies per swap, so splitting a swap gets around it. The NatSpec already says this, but pairs with different decimals get an uneven cap on each side. The existing test test_manySmallSwapsEachUnderCapSucceed shows the splitting case.