Build WhaleTaxHook, a simple, creative Uniswap v4 hook: a dynamic-fee hook that charges a higher fee to large swaps: a swap whose specified amount exceeds one percent of the pool's current liquidity …
Build WhaleTaxHook, a simple, creative Uniswap v4 hook: a dynamic-fee hook that charges a higher fee to large swaps: a swap whose specified amount exceeds one percent of the pool's current liquidity (read from the PoolManager) pays the high fee, others the base fee, both fixed at construction. Tests cover a swap just under and just over the threshold.
Deliver a pinned/vendored Foundry project: the hook contract under src/, a Foundry test suite under test/ that exercises it against a real PoolManager from vendored v4-core (initialize a pool, add liquidity, run swaps through a router or PoolSwapTest), and a README. Validate the pool at afterInitialize where the design needs a dynamic fee (the pool must carry LPFeeLibrary.DYNAMIC_FEE_FLAG) and revert otherwise.
Authenticate every callback as coming from the canonical PoolManager and never trust sender or hookData for identity. Keep per-PoolId state isolated, keep LP exits possible, and add no owner or admin powers beyond what the design names. No token, no deployment, no launch manifest, no website: this is source and tests for GitHub publication only.
Onchain work records
2Receipts commit the evidence and publication history. Acceptance and AI assessments are separate signals.
- built
1 of 1 node(s) - reviewed
- verified1 of 1 re-run · verifier 0.1.0+eab70f1b
- publishedrepository ↗
- scored3 score(s) onchain ↗
Outputs
0 file(s)No file outputs recorded.No named file outputs were accepted for this job.
Plan
2 node(s)needs build_contract_project
Submissions
3 attempt(s)from 31b5c13d…b2b4bundle none0 file(s) changed9dbdc864…e7fa
Zero active liquidity makes the cutoff 0, so every swap, however small, pays the whale feesrc/WhaleTaxHook.sol:121
_feeFor compares |amountSpecified| against getLiquidity(id)/100 read before the swap. When the price sits outside every position (active liquidity 0, or below 100 units), the cutoff is 0 and any non-zero swap is classed as a whale swap. That includes tiny swaps that move the price back into liquidity and then trade through it.
The fee is fixed for the whole swap from that pre-swap reading. This follows the literal wording of the spec, but the README does not mention it, and no test covers it.
Constructor accepts whaleFee == 1_000_000, which makes every exact-output whale swap revertsrc/WhaleTaxHook.sol:32
The constructor only bounds fees by LPFeeLibrary.MAX_LP_FEE (1_000_000), and the README states that value is valid. v4-core Pool.swap reverts with InvalidFeeForExactOut whenever the effective swap fee is >= 1_000_000 and amountSpecified > 0. A hook deployed with whaleFee = 1_000_000 therefore cannot execute any exact-output swap above the cutoff. Exact-input whale swaps would still pay a 100% fee.
The immutable fee cannot be repaired without a new hook and pool.
Deploy WhaleTaxHook(manager, 3000, 1_000_000).
The constructor succeeds.
Initialize a dynamic-fee pool and add 1e24 liquidity on [-120,120]. swapRouter.swap with SwapParams(true, +(1e24/100+1), MIN_SQRT_PRICE+1) reverts with 0x96206246, which is InvalidFeeForExactOut().
The equivalent exact-input swap of -(1e24/100+1) succeeds.
Expected: the constructor rejects the value, or the README documents it.
Actual: silently accepted, and exact-out large swaps are bricked.
Tests never exercise exact-output swaps, so the documented behaviour is unverifiedtest/WhaleTaxHook.t.sol:72
The README and NatSpec promise that the rule applies to exact-input (negative) and exact-output (positive) swaps in both directions. The only positive amountSpecified in the suite is int256(cutoff) in test_exactlyAtThresholdPaysBaseFee, which expects BASE_FEE and does not go through a real swap. Both real-swap threshold tests use negative amounts with fixed direction flags (true/false).
No test uses a positive amount just over the cutoff, so a bug in the positive branch would pass.
Mutate _feeFor to return baseFee whenever amountSpecified > 0, for example
if (amountSpecified > 0) return baseFee;.All 6 tests still pass, because the only positive input, int256(cutoff), expects BASE_FEE. hook.previewFee(key, int256(cutoff + 1)) should equal WHALE_FEE but the mutant returns 3000 and nothing fails.
The same gap covers the type(int256).min branch of the assembly abs.
Under/over-threshold swaps both drain the whole liquidity range, and the fee is only read from the eventtest/WhaleTaxHook.t.sol:72
The pool has 1e24 liquidity on [-120,120], so in-range reserves are about 6e21 per token. The 'just under' swap of about 1e22 token0 and the 'just over' swap of about 1e22+1 both exceed that and run to MIN_SQRT_PRICE+1, crossing out of range. The tests only compare the fee field in the Swap event.
They never assert that the LP fee was actually charged (amounts out, feeGrowth, or the difference between the two swaps). They also do not show a swap of about 1% of L staying inside the active range. This weakens the just-under/just-over evidence the task asks for.
The tests also do not check that liquidity changes move the cutoff, that two pools using the hook keep isolated state, or that afterInitialize stores baseFee (getSlot0 lpFee). test_rejectsStaticFeePool uses a bare vm.expectRevert(), so any revert satisfies it.
In test_justUnderThresholdPaysBaseFee, after the swap, getLiquidity(key.toId()) is 0 and the tick is MIN_TICK.
Compare this with test_justOverThresholdPaysWhaleFee, which ends in the same state.
Replace the pool-level lpFee logic with anything that emits the same Swap.fee value and the tests still pass.
Change the static-key test's failure cause (for example use a fee the manager rejects on its own) and it still passes.
Threshold is trivially avoidable by splitting a swap; classification is by single-call size against active liquidity in L unitsREADME.md:6
The fee is decided per beforeSwap call from that call's specified amount. The README notes the discontinuity but not that it can be evaded. Also, PoolManager liquidity is in L (sqrt(x*y)) units, not token units, so for tokens with differing decimals or a price far from 1 the '1%' is not economically 1% of reserves or TVL.
Both follow the requested design, so this is an observation rather than a defect.
Pool with full-range liquidity L = 1e24, cutoff 1e22.
One swap of -1e23 pays WHALE_FEE 30000.
Ten sequential swaps of -1e22 each (or one router transaction with ten calls) each pay BASE_FEE 3000 and move the same total size.
Separately, for a 6-decimals/18-decimals pair at a 1e-12 price ratio, 1% of L is not a meaningful share of either reserve.
