Risks in Uniswap v4 hooks after fee switch governance deadlock

The fee switch expansion

The UNIfication proposal cleared 40 million votes to activate the Uniswap fee switch, which redirects a portion of trading fees to the protocol. Nearly 62 million votes supported the measure as of early Monday since voting opened on Dec. 20. This governance change expands the fee mechanism to v4 pools and seven additional networks such as Arbitrum, Base, BNB Chain, Polygon, OP Mainnet, and Robinhood Chain. Proposal 100, executed on July 27, 2026, moved the split on 0.30% pools to 0.25% for liquidity providers and 0.05% for the protocol. This expansion increased daily revenue from approximately $114,000 earlier in July 2026 to roughly $325,000 after the scope grew. The governance action also authorized a 100 million UNI burn from the treasury to reward holders. Uniswap gained approximately 25% since UNIfication voting started. It currently trades at $6.08, a recovery from a month-long decline. The token ranks 39th by market cap at $3.8 billion. The Foundation plans to create a Growth Budget and will distribute 20 million UNI to meet development goals. Base has overtaken Ethereum as the top fee-generating blockchain for Uniswap in 2026.

Malicious hook logic

Uniswap v4 hooks introduce substantial security risks because they grant external contracts authority over pool behavior. Analysis of 84,163 hooks across six chains by 0x found that only 19.4% were safe, while 54.2% were malicious and 26.4% were likely malicious. Malicious hooks spoof quotes to trick aggregators and wallets into routing trades to predatory pools. In some cases, users received 50% less than the amount quoted during execution. 0x observed these malicious hooks on the Base and BNB Chain networks, and they used different patterns to exploit traders. Only 741 votes opposed the UNIfication measure. This total accounted for about 0.001% of votes cast, while over 1.5 million voters abstained.

The ArrakisFinance team identified a bug in a dynamic fee hook during the EthCC Paris Hookathon where the beforeInitialize function allowed an attacker to override the poolKey variable. This flaw lets an attacker create a new pool and assign it to the same hook, which prevents legitimate liquidity providers from withdrawing their funds. Another error involves hooks that use a global array to track reserves instead of isolating state to a specific PoolId. If an attacker manipulates a low-liquidity side-pair, they can shift the global invariant and drain a high-value stablecoin pair. A researcher found that by dumping a large amount of a token into a secondary pool, they could shift the global invariant and manipulate the exchange rate and price impact of a completely unrelated high-value pool.

Risks of delegated authority

Hooks shift control from the core protocol to the pool lifecycle and give developers authority over fees, timing, accounting, and execution. You should realize that a hooked pool combines a pool with delegated authority. This authority enables the exploitation of donation mechanics through just-in-time liquidity. An attacker adds liquidity immediately before a donation, captures the reward, removes liquidity before the next block, and completes the cycle. This method allows the attacker to siphon funds without providing meaningful liquidity to the pool.

Another flaw involves hooks that rely on the amountSpecified parameter instead of the actual balanceDelta returned from a swap. A user might request a swap for 100 ETH to receive a 1% bonus based on that amount, even if the pool only contains 10 ETH of actual liquidity at the time of settlement. This allows users to extract more value than the pool contains. Do malicious developers continue to find ways to mask these logic errors behind complex hook architectures? Users must prioritize auditing delta-based rewards to ensure long-term stability.