AMM Vulnerabilities and Exploits: How DeFi Liquidity Pools Get Hacked
Apr, 10 2026
If you've ever swapped tokens on a decentralized exchange, you've used an AMM. While they've revolutionized how we trade, they've also created a playground for sophisticated attackers. To protect your assets, you need to understand that the risk isn't just 'bad code,' but the systemic way these pools interact with the broader crypto ecosystem.
The Core Engine: How AMMs Create Risk
Before we talk about the exploits, we have to understand the machine. An AMM is a decentralized exchange protocol that uses a mathematical formula to price assets, replacing the traditional order book with liquidity pools. Most use the Constant Product Formula (x * y = k), meaning the product of the quantities of two assets in a pool must remain constant. This creates a predictable price curve, but it also means the price is entirely dependent on the ratio of tokens in the pool.
The danger arises because this price isn't 'real'-it's just a reflection of the current pool balance. If an attacker can drastically shift that balance for a few seconds, they can trick the protocol into thinking an asset is worth much more or much less than its actual market value. This is where the most devastating exploits begin.
Flash Loan Attacks: Borrowing Millions for Chaos
A Flash Loan is a DeFi instrument that allows a user to borrow a massive amount of capital without collateral, provided the loan is repaid within the same transaction block. Normally, you'd need millions of dollars to move a market. With flash loans, anyone with a few hundred dollars in gas fees can suddenly wield the power of a whale.
In a typical flash loan attack, the hacker borrows a huge sum from a provider like Aave is a decentralized non-custodial liquidity protocol that allows users to lend and borrow various crypto assets. They use this capital to flood an AMM pool, skewing the price of a specific token. Once the price is manipulated, they use that 'artificial' price to take out a low-collateral loan from another protocol or swap assets at an unfair rate. By the time the transaction finishes, they've repaid the flash loan and kept the profit, often in the millions.
Price Oracle Manipulation and the 'Truth' Gap
AMMs don't know the price of gold or ETH in the real world; they rely on Price Oracles is services that provide external data feeds to smart contracts, telling them the current market price of an asset. The vulnerability occurs when a protocol uses a single AMM pool as its only price source. This is called a "spot price oracle."
If a protocol relies on a single pool for pricing, an attacker can manipulate that pool's balance using a flash loan, causing the oracle to report a fake price. For example, if an attacker pushes the price of token A up by 1000% in a pool, any other protocol using that pool as an oracle will think token A is suddenly incredibly valuable. The attacker then deposits token A as collateral and borrows a much more stable asset, like USDC, and simply disappears. The protocol is left with 'worthless' collateral and a massive hole in its treasury.
MEV and the Art of the Sandwich Attack
Not all exploits are catastrophic hacks; some are just predatory. MEV is Maximal Extractable Value, the profit a validator or miner can make by reordering, including, or excluding transactions within a block. This leads to a specific type of exploit called a sandwich attack.
A sandwich attack happens when a bot spots a large pending trade in the Mempool is the waiting area for unconfirmed transactions before they are added to a block by a validator. The bot quickly places a buy order *before* the user (pushing the price up) and a sell order *after* the user. The user ends up buying at a higher price, and the bot pockets the difference. While this isn't a 'bug' in the AMM, it's a vulnerability in the way blockchain transactions are processed, resulting in significant slippage for the average trader.
| Exploit Type | Primary Mechanism | Impact Level | Target |
|---|---|---|---|
| Flash Loan Attack | Instant high-capital borrowing | Critical | Liquidity Pools |
| Oracle Manipulation | Faking asset prices | Critical | Lending Protocols |
| Sandwich Attack | Transaction front-running | Moderate | Individual Traders |
| Slippage Abuse | Exploiting wide price gaps | Low to Moderate | Low-Liquidity Pools |
Impermanent Loss and Liquidity Draining
While not an 'exploit' in the sense of a hacker, Impermanent Loss is the temporary loss of funds experienced by liquidity providers when a token's price moves significantly from when it was deposited. Bad actors can intentionally trigger this by aggressively trading against a pool. By forcing a price crash or spike, they can make it mathematically disadvantageous for liquidity providers to stay in the pool, causing a "bank run" where providers pull their funds, further crashing the price and allowing the attacker to buy the remaining assets for pennies on the dollar.
Furthermore, some AMM implementations suffer from "rounding errors" in their smart contracts. In a world where we deal with 18 decimal places, a tiny mistake in how a contract calculates fees or shares can be exploited. Over thousands of transactions, an attacker can siphon off small amounts of liquidity-a digital version of "salami slicing"-until the pool is empty.
How to Spot a Vulnerable Protocol
You don't need to be a Solidity expert to identify red flags. First, look at the oracle. If a project says they "get their price from the Uniswap pool," be careful. Reputable projects use decentralized oracle networks like Chainlink is a decentralized oracle network that provides high-quality data feeds for smart contracts by aggregating data from multiple sources. Chainlink aggregates data from many different exchanges, making it nearly impossible for a single flash loan to manipulate the price.
Second, check the audit history. A "certified" audit isn't a guarantee, but it shows the team is trying. Look for audits that specifically mention "economic security" or "game theory," not just "code correctness." A contract can be mathematically perfect but economically broken. Finally, check the liquidity depth. If a pool has very low liquidity, it's much easier to manipulate the price, making it a prime target for sandwich attacks and slippage exploits.
The Future of AMM Security
The industry is moving toward "Concentrated Liquidity," a model popularized by Uniswap V3 is an AMM version that allows liquidity providers to provide liquidity within specific price ranges, increasing capital efficiency. While this makes trading more efficient, it adds complexity. The narrower the price range, the more volatile the price can become if liquidity is thin, potentially opening new doors for manipulation.
We are also seeing the rise of "Time-Weighted Average Prices" (TWAP). Instead of looking at the price *right now*, a TWAP looks at the average price over the last 30 minutes. This kills the flash loan attack because a hacker cannot maintain a manipulated price for 30 minutes-the cost of holding that position would be astronomical. When you see a protocol using TWAP or multi-source oracles, you're looking at a much safer bet.
Can I get my money stolen if I just trade on an AMM?
Usually, trading (swapping) is safer than providing liquidity. However, you can still lose money to "sandwich attacks" or high slippage, which effectively steals value from your trade. The biggest risk is always providing liquidity or depositing assets into a lending vault that relies on an AMM for pricing.
Why can't developers just ban flash loans?
They can't, because flash loans are just another transaction on the blockchain. A protocol can't "block" a user from having a certain amount of money in a single block. The only way to stop flash loan attacks is to make the protocol's logic resistant to sudden price swings, such as using TWAP or external oracles.
What is the difference between a bug and a logical exploit?
A bug is like a typo in the code that causes the program to crash or behave unexpectedly. A logical exploit is when the code does exactly what the developer told it to do, but the developer didn't realize that the rules they created could be used to steal money. In AMMs, most "hacks" are logical exploits of the financial math.
How does a sandwich attack actually work in real-time?
A bot monitors the mempool and sees you want to buy 100 ETH with USDC. The bot submits a buy order for ETH with a higher gas fee, so it gets processed first. This pushes the ETH price up. Your trade then goes through at the new, higher price. Immediately after, the bot sells its ETH, profiting from the price increase your own trade caused.
Is an audited protocol 100% safe?
No. An audit only proves that the code does what it claims to do. It doesn't guarantee that the economic model is sound. Many audited protocols have been exploited because the auditor looked at the code but didn't simulate a flash loan attack scenario or a price oracle failure.
Next Steps for Safe DeFi Interaction
If you are a casual trader, start by adjusting your "Slippage Tolerance" in your wallet settings. Setting it too high (e.g., 5% or 10%) makes you a prime target for sandwich bots. Keep it as low as possible while still allowing the trade to execute.
For those providing liquidity, diversify your pools. Don't put all your capital into a single low-volume pair. Stick to well-established pools with deep liquidity and use protocols that integrate Chainlink or other robust oracle systems. If you're venturing into new "yield farms," always check if they use spot-price oracles-if they do, the risk of a flash loan drain is significantly higher.