# Prior art: simulation-aware contracts, bait pools and poisoned quotes

Research cut-off: 2026-09-05. This is a source survey, not a claim that the list is
exhaustive. Confidence is marked as **Verified** when the primary source is checkable,
**Likely** when the account is independently reported but the underlying artifact is not
fully public, and **Uncertain** when the item is an adjacent pattern rather than a
documented instance of the exact attack.

## Questions investigated

- Have contracts used execution-context checks to show a safe quote to `eth_call`, `estimateGas`, or MEV simulation while taxing or reverting real execution?
- Have pools, tokens, or routers deliberately won pathfinding with a better quote and then delivered worse execution?
- What did Uniswap v4’s design, audits, and incidents say about hooks that alter fees or swap accounting?
- Which defenses now test the real transaction context, simulate complete routes, or reject untrusted liquidity?

## Executive finding

[FINDING] The broad pattern is old. Ethereum honeypots and “trapdoor” tokens predate v4,
and Salmonella demonstrated in March 2021 that a token could be attractive to a sandwich
bot while making its exit economically toxic. ([Salmonella source](https://github.com/Defi-Cartel/salmonella),
[Flashbots report](https://medium.com/flashbots/flashbots-transparency-report-march-2021-d3930b4b98a9),
[trapdoor-token study](https://arxiv.org/abs/2309.04700))

[FINDING] The closest confirmed match is now public: Enso’s report dated 16 July 2026
describes a Polygon Uniswap v4 hook that applied about a 98.9% fee above a gas-price
threshold, plus an Ethereum Curve pool that gave simulation-associated calls a discounted
rate and real transactions a worse rate. ([Enso report](https://blog.enso.build/toxic-pools/),
[independent report](https://unchainedcrypto.com/some-defi-pools-are-rigged-to-fake-a-good-price-enso-finds/))

[FINDING] Therefore, “a gas-price-aware fee inside a v4 hook” is not a defensible
first-ever claim as of this cut-off. The Robinhood-chain cluster documented by this
project may still be a new instance, and the evidence for an operator-funded, sole-LP
deployment is a useful additional fact pattern, but neither is a global novelty claim.
([research notes](README.md), [article evidence](../post.md))

## 1. Simulation-aware and honeypot contracts

### Zero-gas honeypots: related, but not quote poisoning

[FINDING] **Verified; Ethereum; 3 April 2019 paper.** Cheng et al. studied ERC-20 theft
against exposed Ethereum JSON-RPC nodes and described “zero gas” transactions that could
only succeed under special miner conditions. This is relevant historical evidence that
`gasPrice == 0` can be a meaningful execution distinction, but it is not evidence that an
`eth_call` quote was deliberately made better than a real swap. ([paper and date](https://arxiv.org/abs/1904.01981))

[FINDING] **Verified; Ethereum; 2021–2023 research literature.** Uniswap scam-token
studies found large populations of tokens that allowed buying but blocked or restricted
selling, and detected them with transaction history, contract features, creator/colluder
relationships, and buy/sell simulation. Those are classic honeypots or trapdoors; the
papers do not establish that the contracts keyed their behavior specifically to
`eth_call`, `estimateGas`, or bundle simulation. ([Trade or Trick?](https://arxiv.org/abs/2109.00229),
[Trapdoor Tokens](https://arxiv.org/abs/2309.04700), [honeypot-trap study](https://arxiv.org/abs/2309.13501))

### Salmonella and poisoned sandwiching

[FINDING] **Verified; Ethereum; March 2021.** Salmonella was a deliberately toxic ERC-20
used against sandwich searchers: its public source makes the ordinary transfer path send
only 10% of the apparent amount to non-owner addresses while emitting a full-looking
`Transfer` event, so a bot could see a profitable buy and lose on the sell. ([source repository](https://github.com/Defi-Cartel/salmonella),
[Galaxy research summary](https://www.galaxy.com/insights/research/mev-how-flashboys-became-flashbots))

The relevant source-level entry point is:

```solidity
function _transfer(address sender, address recipient, uint256 amount) internal virtual
```

The contract then branches on the sender/recipient rather than treating the event amount
as proof of the balance change. ([Salmonella token source](https://github.com/Defi-Cartel/salmonella))

[FINDING] Flashbots’ March 2021 transparency report says a large Ethereum sandwich-bot
operator was hit by Salmonella and reports that the Salmonella trader walked away with
roughly 130 ETH; the Salmonella repository records the bait-pool and binary-search
strategy. This is bot poisoning, not a user aggregator being shown a false LP fee, but it
is the clearest early precedent for adversarially different behavior aimed at automated
simulation and execution. ([Flashbots report](https://medium.com/flashbots/flashbots-transparency-report-march-2021-d3930b4b98a9),
[Salmonella repository](https://github.com/Defi-Cartel/salmonella))

### Direct simulation-aware liquidity: Enso, July 2026

[FINDING] **Verified; Polygon and Ethereum; 16 July 2026.** Enso reports two production
venues that changed behavior between route discovery and submitted execution: a Polygon
USDC/WETH Uniswap v4 hook and an Ethereum USDC/USDT Curve pool. ([Enso report](https://blog.enso.build/toxic-pools/))

[FINDING] The Polygon hook inspected `tx.gasprice`, charged about 98.9% above 100 gwei,
and combined `GASPRICE`, `ORIGIN`, `COINBASE`, and `BASEFEE` signals; the operator address
was exempted. Enso attributes about 93% of reverted attempts to MEV and arbitrage bots and
reports 37,467 failed swaps. ([Enso Polygon case](https://blog.enso.build/toxic-pools/))

[FINDING] The Ethereum Curve case returned a discounted rate when simulation-associated
conditions included `tx.origin == 0` or `tx.gasprice == 0`, then removed the discount in
real transactions. Enso reports 129,070 successful swaps below the quoted result and
37,425 reverted transactions, with the switch toggled repeatedly rather than remaining
permanently active. ([Enso Curve case](https://blog.enso.build/toxic-pools/))

[FINDING] This is the first item in this survey that matches both sides of the current
article’s mechanism—simulation-context discrimination and permissionless liquidity that
wins route discovery. It is not merely a rumor: Enso provides the incident account and
links an underlying on-chain investigation, while Unchained independently reports the two
venues and date. ([Enso sources](https://blog.enso.build/toxic-pools/),
[Unchained report](https://unchainedcrypto.com/some-defi-pools-are-rigged-to-fake-a-good-price-enso-finds/))

### What the common fingerprints do, and what remains unproven

[FINDING] Solidity documents `tx.gasprice`, `tx.origin`, `msg.sender`, and `gasleft()` as
observable transaction or call-context values, and warns that off-chain evaluation does
not give `block.*` and `tx.*` a universally fixed meaning. That makes gas price, origin,
coinbase/base fee, caller identity, and gas remaining plausible discrimination inputs, not
proof that a particular token used them maliciously. ([Solidity globals](https://docs.soliditylang.org/en/latest/units-and-global-variables.html#block-and-transaction-properties))

[FINDING] Code-size/EOA checks are another known family of call-path heuristics: the
Consensys security guidance discusses `extcodesize` and `tx.origin == msg.sender` as
fragile ways to distinguish contracts from externally owned accounts. In the primary
sources reviewed here, I found no independently documented honeypot incident that uses
`gasleft()` or a code-size check specifically to hide a sell tax from a quoter; those
signals should be presented as an evidence gap, not as confirmed prior incidents.
([Consensys extcodesize guidance](https://github.com/ConsensysDiligence/smart-contract-best-practices/blob/master/docs/development-recommendations/solidity-specific/extcodesize-checks.md),
[Solidity globals](https://docs.soliditylang.org/en/latest/units-and-global-variables.html#block-and-transaction-properties))

[FINDING] I likewise found no primary post-mortem in this review that proves an older
token deliberately returned one result to `estimateGas` or to a private bundle simulator
and another to the mined transaction. The absence is a search limitation, not evidence
that such code does not exist; the Enso cases are the confirmed direct examples.
([eth_estimateGas specification](https://ethereum.github.io/execution-apis/api/methods/eth_estimateGas/),
[Enso report](https://blog.enso.build/toxic-pools/))

## 2. Aggregator and router quote poisoning

### The direct route-selection case

[FINDING] **Verified; Ethereum and Polygon; July 2026.** Enso explicitly describes
“toxic pools” that return an attractive simulated result, win route selection, and then
produce worse output or revert on-chain. The Curve pool affected user-facing routing,
while the Polygon v4 hook mostly acted as a honeypot for automated routes. ([Enso report](https://blog.enso.build/toxic-pools/))

[FINDING] The Ethereum Curve pool was not just a shallow pool or an ordinary fee-on-transfer
token: its oracle path was made to look legitimate, then its rate changed according to
simulation context. The route-poisoning mechanism therefore sits directly at the
aggregator/wallet quote boundary. ([Enso Curve case](https://blog.enso.build/toxic-pools/))

### Shallow liquidity: a routing failure, not a malicious quote

[FINDING] **Verified; Ethereum; 12 March 2026 transaction, 17 March 2026 analysis.** A
$50.4 million USDT conversion through Aave’s interface and CoW Protocol ended with about
$36,000 of AAVE after a solver routed through Uniswap v3 and then a SushiSwap WETH/AAVE
pool holding roughly $73,000–$75,000 of liquidity. ([Talos/Coin Metrics analysis](https://www.talos.com/insights/state-of-the-network-355))

[FINDING] Talos attributes the loss to extreme price impact and a CoW quote-verification
failure involving a stale gas ceiling, not to a pool that lied differently under
simulation. Aave’s post-mortem reportedly noted that the user accepted a 99.9% price-impact
warning. This is important adjacent prior art: low-liquidity route selection can be
catastrophic without being quote poisoning. ([Talos analysis](https://www.talos.com/insights/state-of-the-network-355))

### Fee-on-transfer mismatch: a known accounting class

[FINDING] Uniswap maintains an off-chain-oriented `FeeOnTransferDetector` that flash-borrows
a token, measures buy and sell balance changes, checks external transfers, and records
sell reverts. Its public entry point is:

```solidity
function validate(address token, address baseToken, uint256 amountToBorrow)
    public returns (TokenFees memory fotResult)
```

([Uniswap detector source](https://github.com/Uniswap/util-contracts/blob/main/src/FeeOnTransferDetector.sol))

[FINDING] The detector’s existence and 0x’s current buy/sell-tax documentation show that
fee-on-transfer behavior is a known source of inaccurate quotes and failed swaps, with 0x
documenting real-time simulation as its tax-detection method. Neither source is a
post-mortem proving that a named malicious pool intentionally poisoned an older aggregator.
([Uniswap detector](https://github.com/Uniswap/util-contracts/blob/main/src/FeeOnTransferDetector.sol),
[0x buy/sell tax support](https://docs.0x.org/evm/0x-swap-api/additional-topics/buy-sell-tax-support))

[FINDING] A 2024 Code4rena finding against THORChain’s aggregator-facing transfer path
shows the complementary failure mode: after a fee-on-transfer token transfer, the code
passed a pre-fee amount to an aggregator, causing reverts or possible accounting loss.
The recommended defense was to compare balances before and after the transfer. This is a
router integration bug, not evidence of a bait pool. ([finding](https://github.com/code-423n4/2024-06-thorchain-findings/issues/64),
[audit report](https://code4rena.com/reports/2024-06-thorchain))

### Reverse-MEV honeypots

[FINDING] **Verified; Ethereum; 20 June 2026 incident, 23 June 2026 report.** Blockaid
describes a counter-MEV honeypot in which fake WETH/USDC/USDT-like tokens and fake
Uniswap-v2-style pools lured JaredFromSubway’s MEV infrastructure into approvals and
subsequent asset sweeps. Blockaid says it flagged the attacker wallets and contracts
before the final drain. ([Blockaid incident report](https://blockaid.io/blog/the-predator-becomes-the-prey-how-a-counter-mev-honeypot-drained-75m-from-jaredfromsubway))

[FINDING] This is a modern descendant of Salmonella’s bot-targeting idea, but it is not
ordinary aggregator quote poisoning: the adversary targeted the bot’s token and pool
assumptions rather than making a retail route quote claim that differed only between
simulation and execution. ([Blockaid report](https://blockaid.io/blog/the-predator-becomes-the-prey-how-a-counter-mev-honeypot-drained-75m-from-jaredfromsubway),
[Salmonella source](https://github.com/Defi-Cartel/salmonella))

### Search boundary

[FINDING] I found no primary incident report, before Enso’s July 2026 publication, that
names 1inch, 0x, ParaSwap, Kyber, CoW, or Uniswap routing as being deliberately fooled by
a specific malicious low-liquidity or fee-on-transfer pool. The documented evidence is
stronger for adjacent failure classes—Salmonella-style bot bait, FoT accounting
mismatches, and the 2026 CoW shallow-liquidity loss—than for a historical named
aggregator-poisoning exploit. ([Enso report](https://blog.enso.build/toxic-pools/),
[0x tax documentation](https://docs.0x.org/evm/0x-swap-api/additional-topics/buy-sell-tax-support),
[Talos analysis](https://www.talos.com/insights/state-of-the-network-355))

## 3. Uniswap v4 hook risk literature

### The design makes fee manipulation possible by construction

[FINDING] **Verified; Uniswap v4 design and current documentation.** v4 hooks are external
contracts invoked around pool operations, and dynamic-fee pools can let a hook choose an
LP fee per swap. Uniswap’s dynamic-fee guidance explicitly lists gas-price-responsive fees
as a possible use case while warning that fee-setting logic needs security controls.
([hooks concept](https://developers.uniswap.org/docs/protocols/v4/concepts/hooks),
[dynamic fees](https://developers.uniswap.org/docs/protocols/v4/concepts/dynamic-fees),
[v4 whitepaper](https://app.uniswap.org/whitepaper-v4.pdf))

The interface signature that matters here is:

```solidity
function beforeSwap(
    address sender,
    PoolKey calldata key,
    SwapParams calldata params,
    bytes calldata hookData
) external returns (bytes4, BeforeSwapDelta, uint24);
```

The core library interprets the returned `uint24` as an optional LP-fee override when the
pool is dynamic and the override flag/value is valid. ([IHooks interface](https://github.com/Uniswap/v4-core/blob/main/src/interfaces/IHooks.sol),
[Hooks library](https://github.com/Uniswap/v4-core/blob/main/src/libraries/Hooks.sol))

[FINDING] That return path makes a misleading fee an ordinary protocol-level outcome,
not necessarily a hook-side token transfer: the PoolManager can account the override as
the pool’s LP fee. This is why static bytecode review and quote replay need to inspect both
hook return values and final pool accounting. ([Hooks library](https://github.com/Uniswap/v4-core/blob/main/src/libraries/Hooks.sol),
[v4 security framework](https://developers.uniswap.org/docs/protocols/v4/security))

### Audit literature

[FINDING] **Verified; audit published 24 February 2025.** OpenZeppelin’s audit of the
Uniswap Hooks Library treats override-fee bases, custom accounting, and custom-curve bases
as security-sensitive extension points. It records issues involving slippage checks,
unsafe casting, multi-pool state, and generic callback behavior. ([OpenZeppelin audit](https://www.openzeppelin.com/news/uniswap-hooks-library-milestone-1-audit))

[FINDING] The same audit describes a custom-accounting pattern intended to own all liquidity
through the hook. That means “operator as sole LP” is a documented v4 architecture and is
not, by itself, evidence of abuse; the suspicious combination is sole control plus
context-dependent quote/fee behavior plus route eligibility. ([OpenZeppelin audit](https://www.openzeppelin.com/news/uniswap-hooks-library-milestone-1-audit))

[FINDING] Uniswap’s security framework now calls out programmable fees, custom curves,
`BeforeSwapDelta`, non-standard tokens, multi-pool routing, and monitoring for fee spikes,
revert-rate changes, and expected-versus-actual deltas. This is framework-level risk
guidance, not a report of a specific gas-price bait hook. ([v4 security framework](https://developers.uniswap.org/docs/protocols/v4/security))

### Incidents that establish hook risk, but not this mechanism

[FINDING] **Verified; Ethereum and Unichain; September 2025 disclosure.** Bunni’s post-mortem
attributes an approximately $8.4 million Uniswap v4 exploit to rounding and liquidity
accounting in a custom hook path, including repeated tiny withdrawals and an extreme-price
swap. It was a custom-accounting/math exploit, not a simulation-aware fee override.
([Bunni post-mortem](https://blog.bunni.xyz/posts/exploit-post-mortem/))

[FINDING] **Verified; May 2025.** Cork’s post-mortem describes missing access control in a
Uniswap v4 hook’s `beforeSwap` path, allowing an attacker to spoof callback parameters via
the unlock/callback environment. It demonstrates hook composability and authorization
risk, but not quote-dependent LP-fee manipulation. ([Cork post-mortem](https://www.cork.tech/blog/post-mortem))

[FINDING] Enso is consequently the only confirmed incident in this survey that combines a
v4 hook, simulation-context detection, and a fee gate that changes real execution. Bunni
and Cork should be cited as neighboring hook incidents, not conflated with the bait-pool
mechanism. ([Enso report](https://blog.enso.build/toxic-pools/), [Bunni post-mortem](https://blog.bunni.xyz/posts/exploit-post-mortem/),
[Cork post-mortem](https://www.cork.tech/blog/post-mortem))

## 4. Defenses adopted or directly supported by existing tooling

### Simulate the actual transaction context

[FINDING] A quoter should pass the intended `from`, gas limit, and a realistic gas-price
field into its simulation rather than relying only on a call with omitted gas price. The
execution API defines `eth_call` as a message call and accepts transaction fields including
`from`, `gas`, and `gasPrice`; Solidity warns that off-chain `tx.*` values can otherwise be
implementation-defined. ([eth_call specification](https://ethereum.github.io/execution-apis/api/methods/eth_call/),
[Solidity globals](https://docs.soliditylang.org/en/latest/units-and-global-variables.html#block-and-transaction-properties))

[FINDING] This is a necessary check, not a complete defense: Enso’s examples used several
context signals, and an adversary can target caller, block, base-fee, or other simulation
differences. Replaying at zero gas price and at a realistic effective gas price is a useful
minimum differential test for the current article’s pattern. ([Enso report](https://blog.enso.build/toxic-pools/),
[eth_call specification](https://ethereum.github.io/execution-apis/api/methods/eth_call/))

### Use `eth_simulateV1`, but override its defaults deliberately

[FINDING] `eth_simulateV1` executes a sequence of calls on the state produced by earlier
calls and supports block and state overrides. This is materially closer to a complete
multi-step route than independently calling each pool. ([Execution API](https://ethereum.github.io/execution-apis/api/methods/eth_simulateV1/))

[FINDING] The API notes say simulation defaults can still be simulation-like: gas price is
zero unless supplied, and validation/base-fee behavior depends on the selected mode. A
defensive integration should set a realistic gas price or max-fee context, the intended
sender, gas limit, and relevant block fields, then compare the result with the ordinary
`eth_call` quote. ([eth_simulate notes](https://ethereum.github.io/execution-apis/docs/ethsimulatev1-notes/),
[Geth eth namespace](https://geth.ethereum.org/docs/interacting-with-geth/rpc/ns-eth))

[FINDING] Geth documents state overrides for balances, nonce, code, storage, and storage
diffs, and block overrides for fields such as timestamp, gas limit, fee recipient, and base
fee. These can test the real taker/filler account and controlled block context without
writing to the chain, but they do not guarantee that a malicious hook has no other hidden
branch. ([Geth RPC objects](https://geth.ethereum.org/docs/interacting-with-geth/rpc/objects))

### Trust but verify the route and the token

[FINDING] Uniswap’s Aggregator Quote API says the proposed route is simulated and returns an
error or `txFailureReason` when that simulation fails. This is an example of full-route
verification, but a successful simulation is not proof against a context-sensitive venue;
the route should still be replayed with realistic transaction fields and checked against
minimum output. ([Uniswap Aggregator Quote API](https://developers.uniswap.org/docs/api-reference/aggregator_quote),
[Enso report](https://blog.enso.build/toxic-pools/))

[FINDING] Uniswap’s `FeeOnTransferDetector` and router token validator use balance changes,
transferability, flash-borrowed swap paths, and revert behavior to classify non-standard
tokens; their own source warns that allowlists and missing V2 pairs can make a result
inconclusive. A quoter should therefore treat “not detected” as “not proven safe.”
([FeeOnTransferDetector](https://github.com/Uniswap/util-contracts/blob/main/src/FeeOnTransferDetector.sol),
[Uniswap token validator](https://github.com/Uniswap/swap-router-contracts/blob/main/contracts/interfaces/ITokenValidator.sol))

[FINDING] Honeypot.is is a concrete public scanner implementation of the same defensive
idea for tokens: its API reports simulated maximum buy/sell amounts, buy/sell/transfer tax,
and gas results, while documenting that some simulation fields are absent when the check
fails. This is a detector, not proof that the token ecosystem has no context-sensitive
branches. ([Honeypot.is API](https://docs.honeypot.is/ishoneypot))

[FINDING] 0x documents buy/sell-tax support based on real-time simulation, while UniswapX
discloses that fee-on-transfer behavior can make the recipient receive less than the
specified amount. These are practical defenses and warnings for token behavior, though
neither guarantees safety from a pool-level simulation detector. ([0x tax support](https://docs.0x.org/evm/0x-swap-api/additional-topics/buy-sell-tax-support),
[UniswapX repository](https://github.com/Uniswap/UniswapX))

[FINDING] Enso says its own toxic-pool detection is designed to remove routes that look
favorable during discovery but are unlikely to deliver the displayed output on-chain.
That is the “trust but verify” product response: compare simulated and realized behavior
over time, monitor revert and output deltas, and quarantine a venue rather than assuming
one clean probe proves safety. ([Enso report](https://blog.enso.build/toxic-pools/),
[Uniswap v4 security framework](https://developers.uniswap.org/docs/protocols/v4/security))

[FINDING] Blockaid’s JaredFromSubway response illustrates the address/contract-screening
side of the defense: it says the attacker wallets and contracts were flagged before the
final drain. A router can apply the analogous control by blocklisting or quarantining a
pool/hook after differential simulation or abnormal realized-output evidence. ([Blockaid incident report](https://blockaid.io/blog/the-predator-becomes-the-prey-how-a-counter-mev-honeypot-drained-75m-from-jaredfromsubway))

## Caveats and confidence

[FINDING] **Verified:** Salmonella, the 2019 zero-gas honeypot literature, Uniswap’s v4
interface and dynamic-fee design, the OpenZeppelin audit, Bunni/Cork post-mortems, Enso’s
2026 toxic-pool report, the 2026 CoW/shallow-liquidity incident, and the listed execution
API defenses each have a checkable paper, source repository, official specification,
audit, or post-mortem. ([Salmonella](https://github.com/Defi-Cartel/salmonella),
[Enso](https://blog.enso.build/toxic-pools/), [v4 interface](https://github.com/Uniswap/v4-core/blob/main/src/interfaces/IHooks.sol),
[execution API](https://ethereum.github.io/execution-apis/api/methods/eth_simulateV1/))

[FINDING] **Uncertain or adjacent:** the classic trapdoor-token papers establish honeypots,
not necessarily simulation-aware taxes; the Talos incident establishes shallow-liquidity
routing failure, not malicious quote poisoning; Bunni and Cork establish hook exploits,
not misleading fee returns; and no primary source reviewed here proves a historical
`gasleft()`- or code-size-gated aggregator attack. ([Trapdoor Tokens](https://arxiv.org/abs/2309.04700),
[Talos analysis](https://www.talos.com/insights/state-of-the-network-355), [Bunni post-mortem](https://blog.bunni.xyz/posts/exploit-post-mortem/),
[Cork post-mortem](https://www.cork.tech/blog/post-mortem))

## Verdict

[FINDING] The genuinely new part should be stated narrowly: this project documents a
Robinhood-chain cluster and ties its observed `beforeSwap` fee discontinuity to an
operator-controlled deployment in which the operator is the sole LP, with the exact
addresses, probes, fee ranges, and on-chain fee-flow evidence in the accompanying report.
That is a new documented instance and evidence package, not a proven first in the world.
The broader idea—simulation-aware behavior, baiting automated searchers, token sell traps,
fee-on-transfer quote failure, and route selection on a misleading simulated result—is
well established; most importantly, Enso’s 16 July 2026 report already documents the same
gas-price-keyed LP-fee pattern inside a Polygon Uniswap v4 hook. ([article evidence](../post.md),
[research notes](README.md), [Enso report](https://blog.enso.build/toxic-pools/),
[Salmonella source](https://github.com/Defi-Cartel/salmonella), [0x tax support](https://docs.0x.org/evm/0x-swap-api/additional-topics/buy-sell-tax-support))