Vampire Attack
Pronunciation: VAM-peyer uh-TAK
Definition
A vampire attack uses targeted incentives to draw users, liquidity, volume, or market share away from an established decentralized protocol. Defenses against Vampire Attack combine secure design, least privilege, validation, monitoring, rate or value limits, and tested containment and recovery procedures. For Vampire Attack, an attempted action, a detected indicator, a confirmed compromise, and a realized loss are separate states that require different evidence and response.
Overview
In decentralized finance, a competing protocol may reward participants who migrate liquidity-provider positions or activity from another venue. The strategy can rapidly bootstrap liquidity and governance ownership by converting an incumbent’s existing network into the challenger’s initial user base.
The behavior is primarily economic, but it can create security and market consequences. Temporary rewards may attract mercenary capital, fragment liquidity, distort prices, overload migration contracts, expose copied code, or leave users with unfamiliar governance, custody, and smart-contract risks.
Participants should compare sustainable fees, token emissions, lockups, contract authority, audits, migration permissions, liquidity depth, and exit conditions rather than rewards alone. Protocols can reduce vulnerability through durable user value, transparent incentives, secure integrations, and careful monitoring of concentrated liquidity movements.
A vampire attack uses targeted incentives to draw users, liquidity, volume, or market share away from an established decentralized protocol. A vampire attack competes by subsidizing migration, so users must evaluate long-term economics and new technical risks beyond short-lived token rewards.
Assessment of Vampire Attack should trace the use of targeted incentives to draw users, liquidity, volume, or market share away from an established decentralized protocol from prerequisite and entry point through observable impact on the affected service. A theoretical weakness or scanner result involving targeted incentives to draw users, liquidity, and volume should not be reported as exploitation without corroborating logs, transactions, or configuration evidence. Prevention, detection, containment, and recovery for the Vampire attack path should be tested against the architecture associated with targeted incentives to draw users, liquidity, and volume.
Retesting for Vampire Attack should reproduce the Vampire attack path involving targeted incentives to draw users, liquidity, and volume, examine adjacent paths, and verify the conditions for safely returning the affected service to normal operation.
Key Takeaway
A vampire attack competes by subsidizing migration, so users must evaluate long-term economics and new technical risks beyond short-lived token rewards.
Sources
- NIST Documentation: Cyberframework — NIST (2026-07-30)
- FATF Documentation: Virtual Assets — FATF (2026-07-30)