I want to share a practical, hands-on approach I use to detect on-chain liquidity attacks. These attacks—where malicious actors drain or manipulate liquidity pools to crash price or rug a token—are increasingly sophisticated. Over the years I’ve focused on developing low-noise signals tied to wallet behavior that reliably indicate malicious intent or imminent liquidity extraction. Below I describe three wallet-centered signals I trust most, how to implement them, and how to interpret what you see on-chain.

Why focus on low-noise wallet signals?

Many on-chain detection methods rely on price movement or volume spikes, which are noisy and reactive. Wallet signals, when selected carefully, let you detect preparatory behavior before a major liquidity move. That gives projects, traders, and market analysts time to react. I prefer signals that minimize false positives by tying actions to clear intents (e.g., LP token transfers, ownership concentration, and router approvals paired with immediate swaps).

Signal 1 — LP token movements and ownership concentration

This is my highest-confidence signal. Liquidity providers (LPs) receive LP tokens representing share of a pool. When those LP tokens are transferred to a router, burned, or moved to a new wallet immediately before a big swap, that’s a strong indicator of an imminent liquidity removal.

  • What to watch: Large LP token transfers from wallets that hold a material share of the pool to addresses associated with router contracts, burn addresses, or new/unknown wallets.
  • Why it’s low-noise: LP tokens are explicit proof of ownership. A transfer followed by a burn or a call to removeLiquidity is almost always a liquidity withdrawal intent.
  • Implementation tips: Track LP token transfers on the relevant pair contract. Compute share percentage per wallet (LP token balance / totalSupply). Flag events where a single wallet holds >X% (I often use 5–10% as a threshold) and then transfers >Y% of their LP tokens within a short window (e.g., 30 minutes).
  • Tools & queries: Use Dune or The Graph to index LP token transfers, or subscribe to Transfer events via an archive node. Nansen’s Smart Money or holder labels can speed up owner identification.

Signal 2 — Sudden change in wallet composition interacting with the pool

This signal looks at the composition and continuity of wallets interacting with the pool. A pool mostly used by a distributed set of long-established wallets has a different risk profile than one where a small set of wallets or a flood of brand-new wallets start interacting in a short period.

  • What to watch: Rapid increase in interactions from newly created wallets (age < 24–72 hours), or a single/ small set of wallets that previously never provided liquidity suddenly adding large positions and then appearing again for removal.
  • Why it’s low-noise: New wallets and sudden concentration are common patterns preceding rug pulls or coordinated attacks. This eliminates a lot of benign noise like organic retail buys, which often come from distributed, older wallets.
  • Implementation tips: Maintain rolling metrics: fraction of pool interactions from wallets younger than N days, and the Herfindahl index (concentration metric) of wallet shares. Trigger when new-wallet fraction exceeds a threshold (e.g., >20% of recent adds) or concentration metric rises sharply.
  • Tools & queries: Use on-chain wallet age (first transaction timestamp) via Etherscan APIs or indexed datasets. Dune queries can compute wallet age and activity quickly for a given token/pool.

Signal 3 — Approval-to-swap pattern and router sequencing

This is about behavioral sequencing: an approval to the DEX router (or permit signature) immediately followed by a swap or removeLiquidity call from the same wallet, usually with high gas price and clustered timing. It’s a classic pattern for bots and scripted attackers who approve, then execute their extraction within few blocks.

  • What to watch: Transaction sequences where approve() or permit() on a token is followed within a few blocks by large swapExactTokensForETH, swapExactTokensForTokens, or removeLiquidity, particularly when gas price is elevated and when the swap uses a large % of the wallet’s balance.
  • Why it’s low-noise: The approval + immediate large execution is an operational signature of automated extraction. Normal traders rarely do mass approval immediately followed by a huge swap at scale.
  • Implementation tips: Monitor approvals for the token to router addresses. Correlate approvals with subsequent swaps in a defined window (e.g., 1–10 blocks). Flag if the executed amount exceeds a % of pool depth that would cause meaningful price impact (you can compute expected slippage). Also prioritize cases where approvals come from wallets with recent deposit behavior.
  • Tools & queries: Index Approval and Swap events. Use Etherscan/websocket or archive node to correlate transactions in near-real time. For advanced setups, run mempool watchers to spot approvals with matching swap intent before inclusion.

Putting signals together — multi-signal rules for high confidence

Each signal is useful alone, but the strongest alarms come from combinations. I tend to assign weighted scores to each signal and only escalate when the aggregate passes a threshold. Example rule set I use:

  • LP token withdrawal >= 5% of pool => +5 points
  • High concentration change (single wallet share increase >5% in 24h) => +3 points
  • Approval-to-swap pattern within 10 blocks + large swap => +4 points
  • New-wallet flood (>20% of add liquidity txs from wallets <72h) => +3 points

Escalation: when score >= 7, send alerts (chat, email, on-chain tx monitor). When score >= 10, flag for emergency mitigations (e.g., whitelist checks, pause contracts if possible).

Practical thresholds and false positives

Thresholds depend on the pool's typical depth and activity. A 2% withdrawal in a $10M pool is much different from 2% in a $50k pool. I recommend:

  • Scale thresholds by pool size. For small cap pools, use lower absolute number thresholds but maintain proportional checks (e.g., >10% share triggers immediate scrutiny).
  • Avoid overreacting to organic market makers: established AMMs and institutional LPs will sometimes move LP tokens for rebalancing. Cross-check wallet history and labels (Nansen, Etherscan verified contracts) before acting.
  • Use a time-window approach to avoid transient noise—require sequences to occur within tight windows to indicate orchestration.

How I operationalize monitoring

Here’s a short playbook I apply when building monitoring pipelines:

  • Index events: Transfer for LP tokens, Approval and Swap events for token, removeLiquidity calls on router contracts.
  • Enrich wallets: compute wallet age, historical activity, and label known entities (exchanges, token team wallets, common bots).
  • Calculate pool metrics: total LP supply, per-wallet share, pool depth on both sides, and expected slippage for large trades.
  • Score events: apply the weighted rule-set above to each observed sequence.
  • Alerting: send immediate alerts for high-score sequences with transaction links, estimated impact, and recommended actions (pause minting, disable router, notify community).

Tools I use and recommend

I combine these data sources and tooling to keep noise low and reaction fast:

  • Dune Analytics — great for exploratory queries and historical dashboards.
  • The Graph — for building indexed subgraphs for tokens and pools.
  • Nansen — wallet labels and smart money signals.
  • Archive node or QuickNode/Alchemy — for real-time event subscriptions and mempool watching.
  • Custom scripts — Python/Node services to calculate pool shares and implement the scoring/alerting rules.

What projects should do once they detect a likely attack

Detection is only useful when paired with response. My go-to playbook for teams:

  • Verify: Quickly validate the wallet labels and check the transaction chain (are approvals followed by removes?).
  • Communicate: Inform the community if the risk is real—silence often fuels panic.
  • Mitigate: If the project controls a privileged contract, consider pausing key functions or invoking a timelock. If not, coordinate with the router/DEX if possible.
  • Post-mortem: After the event, share learnings and consider contract-level safeguards (vested liquidity, LP token locks, multisig timelocks).

Detecting on-chain liquidity attacks is part art, part engineering. By focusing on low-noise wallet signals—LP token movement and concentration, wallet composition shifts, and approval-to-swap sequencing—you can get early, reliable warnings. I build my monitoring around those signals and layer context and labels to reduce false positives. If you want, I can share sample Dune queries or a starter script for correlating approvals and swaps for a given token/pair.