How Manipulated Quotes Create Execution, UX, and Liability Risk in DeFi

Enso

• 7 min read
Share
How Manipulated Quotes Create Execution, UX, and Liability Risk in DeFi

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 an exhaustive coverage of the problem. They are concrete examples of a broader class of execution-integrity failures: liquidity that wins routing by exhibiting one behavior in simulation and another in 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.

This was primarily a bot trap. About 93% of the reverted attempts came from MEV and arbitrage bots; one cross-DEX arbitrage engine alone, running a fleet of roughly 2,525 burner wallets from a single funder, racked up 3,509 reverts after repeatedly simulating what looked like profitable Uniswap v4 → v3 routes which ultimately failed in real execution.

The damage was operational rather than finSancial: the pool kept winning route discovery, failing swaps, and consuming execution resources across routers, solvers, and trading systems. Even on a cheap-gas chain, 37,467 failed swaps is a serious execution-quality failure for any routing stack that left the pool eligible.

Case study 2: the Curve pool with an on/off switch

The Ethereum venue was a Curve USDC/USDT pool wired to a manipulated rate oracle. Under conditions associated with simulation (tx.origin == 0 or tx.gasprice == 0 ) the oracle returned a discounted rate that made the pool look more competitive during quote discovery. In real transactions the discount was removed, producing a worse output than shown.

The setup was also more sophisticated than a single rogue contract. The oracle wrapped real Chainlink feeds (USDC/USD and USDT/USD) and only distorted their output under simulation context, so casual inspection saw legitimate price data.

And the pool wasn't alone: the same operator, running EIP-7702 smart-EOAs delegating to a shared implementation, deployed 18 oracle contracts feeding at least six identical pools, one variant alone added another 3,527 reverts beyond the figures analyzed here. An industrialized campaign, not an experiment.

The pool caused two kinds of harm. The visible kind: 37,425 reverted transactions where users and routers paid gas for swaps that should never have been presented as credible. The invisible kind: 129,070 swaps that succeeded but returned less than quoted, arguably worse, because the interface shows a completed swap and the user may never realize execution fell short of the route they accepted.

Both venues stopped exhibiting active toxic behavior after exposure. While this does not prove intent by itself, the timing is consistent with operator-controlled behavior rather than an accidental pricing anomaly.

Post-discovery status

At the time of review, both venues had stopped exhibiting active toxic behavior after exposure. The Polygon hook has been inactive since May 15, 2026. The Curve pool is currently dormant, with discountBps reading 0.

That does not mean the risk has been removed. The Curve pool was designed as a switch, not a permanently toxic pool. Its discountBps setting was toggled 26 times across 48 observed windows, with discount values of 15, 23, 48, and 50 bps. Across the observed period, it was toxic for roughly 423 of 718 hours, or about 59% of the time.

This is important because it defeats one-shot review. A pool can appear honest during a scan, quote normally for part of the day, and then be poisoned again hours later. A route that checked clean yesterday can become unsafe today.

This should not be interpreted as negligence by the routers or wallets that interacted with these pools. Their systems were operating on a standard technical assumption: that liquidity will behave consistently between simulation and execution. Toxic pools are specifically designed to violate that assumption, and intermittent activation makes them particularly difficult to detect through conventional reviews or isolated simulations.

Why this matters for major apps

The Curve pool also affected major user-facing interfaces.

MetaMask routed 6,625 swaps through the toxic Curve pool. Looking only at clean single-hop USDT→USDC swaps in the toxic direction, 4,420 swaps completed successfully, and 4,174 of those occurred while the pool’s discount was active. That subset alone represented approximately $5.88 million in USDC volume routed through the toxic pool.

This creates a difficult fee dynamic. On this flow, MetaMask charged its own swap fee while users were also exposed to manipulated quotes from the pool. Based on the observed pool output versus user-received amounts, MetaMask’s fee measured approximately 0.981%, compared with a stated rate of roughly 0.875%.

Across the $5.88 million toxic MetaMask flow, MetaMask’s fee accounted for approximately $51,460 to $57,698. The gross quote overstatement against users was approximately $29,071, while the attacker’s estimated realized amount was roughly $4,303.

For wallets, aggregators, and apps, execution integrity directly affects user outcomes, fee fairness, support burden, and trust.

The liability question

None of this is legal advice; exposure depends on jurisdiction, product structure, terms, and how quotes are presented. But toxic pools clearly create a product (and legal) risk category for any team that surfaces execution paths.

When an interface displays an expected output, users reasonably read it as a credible representation of what the transaction can deliver. If the route won selection because a pool manipulated the quote environment, teams face reimbursement pressure, support burden, eroded trust, scrutiny of their quote methodology, and, depending on jurisdiction, consumer-protection or disclosure risk.

The relevant question isn't whether the pool was malicious in isolation, but whether the product presenting the quote had reasonable safeguards against routes structurally incapable of delivering it.

The interface closest to the user carries the greatest reputational burden, but responsibility runs through the entire stack: liquidity venues, AMMs and hook frameworks, aggregators, meta-aggregators, wallet swap interfaces, solvers and fillers, and quote providers.

How Enso is addressing toxic pools

Toxic pools are not a one-off issue. Any routing system that depends on simulated quotes needs to assume that some liquidity will eventually try to exploit the gap between simulation and execution.

That is why Enso has extended its quoting and execution infrastructure with toxic pool detection.

The objective is to identify routes that look favorable during discovery but are unlikely to deliver the displayed output onchain, then prevent those routes from being surfaced to users, wallets, aggregators, and applications building on Enso.

This improves execution reliability, reduces unnecessary reverts, and gives teams a stronger methodology for validating the quotes they present to users.

For more on how Enso approaches quote validation and execution reliability, read the documentation: https://docs.enso.build/pages/quoter/overview

Sources