How to detect liquidity drains on DEX pools

A liquidity drain is the sudden removal of the funds backing a DEX trading pool, and it's how most rug pulls take the money. You detect one by watching the pool's net reserve change per block: swaps cancel to roughly zero, while liquidity removal shows as a strongly negative dollar total. Chainalysis tracked $94.8 million in rug-pull losses in 2024.

The scale of the problem is hard to overstate. Chainalysis analyzed the 2,063,519 tokens launched in 2024 and found that 3.59% showed pump-and-dump patterns, and that roughly 94% of the suspicious pools were drained by the same address that created them. On Solana's Pump.fun, Solidus Labs found that 98.6% of the 7 million tokens deployed between January 2024 and March 2025 carried rug-pull or pump-and-dump characteristics. Most of these are small. The median rug on Raydium took $2,832. But they're fast: a 2025 study of 48,380 tokens on TON found that 49.7% of rug-pulled assets vanished within 4 hours of listing.

Speed is the entire detection problem. A liquidity pull is a single transaction. It confirms in one block, which is 400 milliseconds on Solana and about 12 seconds on Ethereum. Any detection method that checks pools on a schedule, even an aggressive one, mostly tells you what you already lost.

Here's what each kind of pool activity looks like at the reserve level:

How drain detection works

Every DEX pool holds reserves of two tokens. When someone swaps, one reserve rises and the other falls, and the dollar values of those two moves cancel each other almost exactly. When a liquidity provider exits, both reserves fall together. Nothing cancels. That asymmetry is the entire detection mechanism, and it's hard to game: a drain can't dress itself up as trading volume, no matter how it's structured.

So a detector needs three things per pool, per block: the pool's current reserves in dollars, the net dollar change in that block, and a pair of thresholds. The standard rule looks like this:

1. Ignore the move if it's under an absolute floor, say $10,000. That filters dust.
2. Ignore it if it's under a percentage of the pool, say 20%. That filters big-but-normal moves on big pools.
3. Alert on anything that clears both. Negative means drain. Positive means a large liquidity add, which is worth watching for different reasons.

The two thresholds scale together. On a $50 million blue-chip pool, 20% means an eight-figure event that should page somebody. On a $100,000 day-old memecoin pool, a $20,000 pull trips the same rule. One configuration covers both ends of the risk spectrum.

There's one source of false positives worth knowing about: just-in-time (JIT) liquidity. Bots on major pools add and remove six-figure positions around individual swaps to capture fees, and measurements on an $8 million Base pool showed them moving about 4% of the pool every block. The liquidity genuinely moves, so a naive detector genuinely fires. It's plumbing, not an exit. A 20% threshold clears that churn with a 5x margin, and netting deltas over a few consecutive blocks kills it entirely, because JIT cycles cancel and real drains don't.

What about catching a rug before it happens? Pre-buy scanners check for risk factors: unlocked liquidity, concentrated holdings, mint authority. They're worth running, and they're also not enough. The HAWK token launch in December 2024 reached a $490 million market cap within 15 minutes and collapsed 90% in the next 20, with insider wallets holding 96% of supply. Reserve monitoring won't predict that. It will tell you the moment it starts, which for anyone holding the token is the difference between exiting at minus 30% and discovering the chart at minus 97%.

What this looks like in practice

The hard part used to be the data: getting per-block reserve changes meant running a node, subscribing to event logs, and decoding every DEX's contract format separately. That stack is why most working drain detectors live inside paid infrastructure.

DexPaprika's reserve stream collapses it to one HTTP call. It pushes a pool_reserves event over Server-Sent Events every time a subscribed pool's reserves change, with the USD math already done server-side. No node, no per-DEX decoding, and it covers 35 chains with the same event shape. The raw feed is one curl away:

curl -N "https://streaming.dexpaprika.com/sse/reserves?method=pool_reserves&chain=ethereum&address=0x88e6a0c2ddd26feeb64f039a2c41296fcb3f5640"

Each event carries total_reserve_usd (the pool's liquidity right now) and total_delta_usd (the signed dollar change this block). Those two fields plus the threshold rule above are a complete detector. The drain detection guide builds it in about 70 lines of JavaScript or Python, watching 25 pools across multiple chains on a single connection.

Does it work? On its first night running, an open-source monitor built exactly this way (LiquidityRadar, which you can fork and point at your own pools) caught a fresh Base pool called WETH/INPAY losing 97.3% of its liquidity, $66,982, in one block at 23:27 UTC. The pool had launched at 19:23 the same day, traded for 76 minutes, and was dead by midnight: zero volume ever since. That's the Chainalysis statistic, the one about 94% of suspect pools being drained by their own creators, playing out in data, four hours start to finish.

For anything running unattended, the streaming connection itself needs care: reconnect backoff, heartbeat watchdogs, and knowing which errors retry. The production streaming guide covers those patterns, and they're the same ones behind our production-ready price feeds article.

Frequently asked questions

Key takeaways

• Reserve-level detection works because of an accounting identity, not a heuristic: swaps cancel, exits don't. That makes it much harder to evade than pattern-based scanners.
• Use two thresholds together (an absolute floor around $10,000 and 15 to 20% of the pool) and they self-scale from memecoin pools to blue chips.
• Speed only matters end to end. A one-block signal is worthless behind a 30-second poll, so push streaming isn't an optimization, it's the difference between detection and autopsy.
• The data layer for this used to cost a node subscription and per-DEX decoding work. It's now a single SSE endpoint, which moves drain detection from "infrastructure project" to "afternoon script."
• If you're building the alerting side, start with SSE explained for crypto apps and the Uniswap guide if pool mechanics are new to you.