Some liquidity in DeFi is engineered to lie. These pools, hooks, and pricing components return an attractive result during route discovery, then deliver materially worse execution once the transaction is submitted onchain. They exploit a structural gap: an eth_call simulation doesn't perfectly reproduce an executed transaction’s environment, and a contract that knows the difference can behave honestly for the quoter and dishonestly for the user.

In this report, we examine two toxic pools identified in production: a Uniswap v4 hook on Polygon (USDC/WETH) and a Curve pool on Ethereum (USDC/USDT).

They are not presented as exhaustive coverage of the problem. They are concrete examples of a broader class of execution-integrity failures: liquidity that wins routing by showing one behavior during simulation and another during execution.

Aggregators pick the route with the best displayed output, so these pools win selection over honest liquidity. Users receive less than shown, revert after paying gas, or stop trusting the product that surfaced the route.

The two cases at a glance:

The Curve pool is the more significant user-facing case, generating approximately $225,000 in overquotes. This shouldn't be conflated with theft: about $23,440 of the gross discrepancy was ordinary Curve fee economics, and the attacker's measured net extraction was $34,592.87. The headline number describes misrepresentation, not revenue.

The Polygon hook extracted almost nothing in dollar value. It worked more like a honeypot, presenting a route that looks profitable to automated systems, then failing the moment it attempts real execution.

What makes a pool toxic?

A toxic pool is any pool that conditionally changes pricing with a malicious hook, oracle, or AMM component based on execution context.

The playbook: return an attractive quote during routing, win selection against honest liquidity, change behavior once the swap executes, then extract as much as possible inside the user's slippage tolerance or force a failure. Nothing requires the pool to look obviously malicious, it only needs to quote slightly better than honest alternatives to win selection.

The underlying weakness: a contract can inspect EVM context that differs between a simulation and an executed transaction such as tx.gasprice, tx.origin, msg.sender, block.coinbase, block.basefee . Any of these can serve as a simulation detector, and both pools here used them directly.

These two cases should not be read as isolated bugs in two specific venues. They are examples of a broader execution-integrity problem: any system that routes based on simulated output can be targeted by liquidity that behaves differently in simulation than it does during execution.

Toxic pools win routing by behaving one way for the quoter and another for the user. That's unacceptable for our traders, who swap at size and depend on getting exactly what they're shown. Getty Hill, CEO, Oku Trade.

The attack surface is also expanding. Uniswap v4 hooks, custom AMM logic, external oracles, dynamic fee modules, proxy patterns, smart-account delegation, and other programmable components all increase the number of places where context-sensitive behavior can be introduced. That does not make hooks or custom pool logic inherently bad. They are useful primitives, and most builders use them legitimately.

The risk is that the same flexibility also gives malicious operators more room to design pools that appear normal during quote discovery, then change pricing, fees, or execution behavior once a real transaction is submitted. That makes this an ongoing routing problem, which needs continuous monitoring.

Case study 1: the Polygon honeypot

The Polygon venue was a USDC/WETH pool built on a Uniswap v4 hook with a fee gate hardcoded into its logic. The hook inspected tx.gasprice and applied a ~98.9% fee whenever gas price exceeded 100 gwei. It layered in additional simulation-detection signals (GASPRICE, ORIGIN, COINBASE, BASEFEE), and the attacker exempted their own operator address so the pool appeared functional during setup and testing.