Tracing the logic gates back to the genesis block. The interface is a lie; the backend is the truth. On June 12, 2024, a single Ethereum address deployed a malicious Curve pool. It returned a perfect quote during simulation—low slippage, high execution quality. Then, on-chain, it reverted. The attacker netted $34,600. The real cost? $30,000 in gas fees burned by failed transactions. This is not MEV. This is not a sandwich attack. This is simulation spoofing—a systemic exploit of the trust layer that every DeFi aggregator, wallet, and router depends on.
Context: The Trust Machine
Modern DeFi is built on simulation. When you click "swap" on MetaMask, Rabby, or 1inch, your wallet doesn't just send the transaction blindly. It simulates the transaction locally—or against a node—to estimate gas, slippage, and final output. The simulation chooses the optimal pool among dozens. Curve, Uniswap, Balancer—all compete for your flow. The aggregator picks the pool with the best simulated return. The user signs. The transaction is sent. The chain executes. The assumption: simulation matches execution.
That assumption is now broken. Enso, a blockchain security firm, uncovered a class of malicious liquidity pools on Ethereum and Polygon that exploit the simulation phase itself. The pools are designed to detect when they are being simulated—and return a favorable quote. When the same call is executed on-chain, they revert or return a worse price. The result: users waste gas on failed transactions, aggregators lose trust, and attackers profit from the gas fee difference or from front-running the revert.
The attack does not require flash loans, oracle manipulation, or complex MEV infrastructure. It requires a single deployed contract with conditional logic. And it works against every wallet that relies on simulation without verification.
Core: The Code-Level Anatomy of a Spoof
Let me read the assembly, not just the documentation. The malicious pool implements a hook—either via Uniswap v4's hook system or via custom logic in Curve's pool factory. The core conditional is simple:
if (gasleft() > SIMULATION_GAS_THRESHOLD) {
// On-chain execution: revert or return bad price
revert("execution failed");
} else {
// Simulation: return fake favorable quote
return bestQuote;
}Gas limits are the key discriminator. During simulation, wallets typically pass a gas limit far below the block gas limit—often 1-2 million. On-chain execution, especially for complex swaps, may use 10+ million. The attacker sets SIMULATION_GAS_THRESHOLD to, say, 5 million. If the call has less gas (simulation), return the fake. If more gas (real execution), revert.
But that's the naive version. The actual exploit is more sophisticated. Enso observed that the malicious Curve pool on Ethereum handled 129,000 transactions. Of those, a subset succeeded with manipulated prices; the rest reverted. The attacker didn't simply revert every real transaction—that would be too easy to detect. Instead, they alternated between honest and malicious behavior. Sometimes the pool executed a legitimate trade. Other times, when conditions favored the attacker (e.g., a large slippage tolerance), the pool would spoof the quote and then execute a worse trade or revert.
The Polygon Uniswap v4 hook case is even cleaner. The hook was deployed to a liquidity pool. Out of all transactions attempted, 99.1% failed. The remaining 0.9% that succeeded likely went to the attacker's own addresses or were honeypot trades. The hook checked msg.sender and tx.origin—if the sender was a known aggregator contract, it would return a fake quote; if a private wallet interacting directly, it might execute honestly. This is a form of address-based simulation detection.
Based on my audit experience with flash loan simulations, I noticed the vulnerability in conditional reverts long before this public disclosure. In 2022, I reviewed a lending protocol that used staticcall to simulate liquidation. The protocol assumed the simulation was accurate because it didn't write state. But malicious contracts can detect staticcall via opcode ADDRESS and GAS and change behavior. I filed it as a low-severity issue—the likelihood seemed low. Now it's proven.
The economic breakdown: The attacker's gross profit from the exploited pools is reported as $34,600. But the gas fees burned by all users on failed transactions totaled approximately $30,000. The attacker paid gas only for their own transactions (the ones that succeeded), which are negligible. The net profit to society is negative—$30,000 in dead weight loss. The attacker gained $34,600, but the ecosystem lost $64,600. That's an efficiency disaster.
Contrarian: The Blind Spot Everyone Missed
The common narrative is that DeFi security has improved—flash loan attacks are down, audits are standard, formal verification is emerging. But this attack targets the trust layer, not the protocol layer. The vulnerability is not in Curve or Uniswap's code. It's in the simulation assumption that all wallets and aggregators share.
Most security research focuses on reentrancy, oracle manipulation, and access control. The simulation layer is considered a UX optimization, not a security boundary. This is a blind spot because simulation is executed off-chain or on a node with no guarantees of state consistency. The attacker exploits the difference between simulated state and real state. This is not a bug; it's a feature of how Ethereum's EVM works—contracts can branch on environmental information.
Some will argue that aggregators can simply add a verification step: after execution, compare the actual output to the simulated output. If divergence exceeds a threshold, revert the transaction (or alert the user). But this is non-trivial. The simulation happens before the transaction is sent; the execution happens after. By the time you know the quote was fake, you've already paid gas. You can't undo it. You can only refund the user off-chain, which aggregators don't do.
Another counterpoint: "This is just a small attack, $34k. It's not a big deal." That's the trap. The technique is replicable at scale. The same operator deployed multiple contracts across chains. Only two were caught. A determined actor could deploy hundreds of malicious pools, each with different gas thresholds, address whitelists, and alternating honest/malicious behavior. Detection requires continuous monitoring of pool behavior under simulation vs. execution. Most security firms don't do that. The attack surface is the entire set of liquidity pools created after permissionless deployment.
Takeaway: The Next Bull Run's Hidden Tax
Simulation spoofing is not a one-off bug. It's a new attack vector that will scale with the next bull market. As more users return to DeFi, they will rely on aggregators and wallets for fast swaps. The aggregators will compete on liquidated quotes. Malicious pool operators will exploit the simulation layer to extract rent without needing to steal directly.
The fix is not simple. Aggregators must implement on-chain verification of simulated quotes—either by committing to a hash of the simulated result before execution, or by using a dedicated verification oracle. Wallets must display warnings when a transaction's actual output deviates from simulation. Protocols must consider limiting hook capabilities for liquidity pools to prevent conditional behavior.
Read the assembly, not just the documentation. The attack works because the industry optimized for latency over integrity. Gas costs are the tax on human impatience. Now we must pay the tax on trust.
The question is not whether this attack will be repeated. It already is. The question is whether the industry will fix the simulation layer before the next wave of capital arrives. I expect we won't. We'll patch the symptom, not the cause. And then we'll wonder why the failed transaction count stays high.