Done. src/Hook.sol is the only file changed.

What it does

The hook takes a fixed basis-point cut of whatever the swapper pays in, in both directions (currency0 when zero-for-one, currency1 when one-for-zero), and keeps it as ERC-6909 claims on itself — the underlying stays in the PoolManager, so nothing is moved out of the pool's own balances.

Which callback charges it depends on the swap type, because v4 only lets a hook move the specified side from beforeSwap and the unspecified side from afterSwap:

• Exact input (src/Hook.sol:116) — input is the specified currency, so the fee comes off the offered amount in beforeSwap; the swapper's debt is unchanged and the pool swaps the remainder.
• Exact output (src/Hook.sol:139) — input is the unspecified currency and its size is only known afterwards, so afterSwap charges the fee on what the pool actually took, on top of the swap cost.

Permissions are the four swap flags only, so initialization, liquidity and donations never reach the hook.

Verification

forge build is clean (no warnings from src/). forge test: 20 passed, 0 failed — the 8 existing tests in test/Hook.t.sol plus 12 I wrote in test/scratch/, covering fee-from-input in both directions for exact input and exact output, hook accrual vs. pool balances, add/remove liquidity and donate taking no fee, empty-pool swaps, and a control pool with no hook that returns an identical output for the post-fee amount — i.e. the curve itself is untouched.

Two things worth your call

The rate is a constant assigned to an immutable, not a constructor argument. BaseHookTest.deployHook passes abi.encode(manager), and the README says to keep constructor(IPoolManager); a second parameter would make every existing test revert at setUp, and the override that would fix it lives in test/, outside my allowed paths. So feeBips is set once at construction (100 bips = 1%) and is immutable after — but changing the rate means editing the constant. If you want it injected, BaseHookTest.hookConstructorArgs() needs the matching override.

Exact-input swaps against a pool with no liquidity in that direction still pay the fee (exact output charges nothing there, since the pool took no input). This is structural, not an oversight: the specified side of a swap is fixed before the pool runs, so the only figure available to charge is the amount offered, and a hook has no way to credit the specified currency back afterwards. Charging the input on exact input requires beforeSwap; the alternative — charging in afterSwap — can only reach the output currency. It's documented in the contract header.

I also left out any way to redeem the accrued claims: that needs an owner and an access-control design the task didn't ask for, and the vendored BaseHookFee treats accrual and payout as separate concerns too.