Inflation Attack

The attacker mints a large quantity of a low-value token (often a newly created one) and uses it as collateral to borrow valuable assets from a lending protocol. The attack exploits the protocol's oracle pricing, which may not immediately reflect the token's true, inflated supply or lack of liquidity, allowing the attacker to drain the protocol's reserves.

This attack critically depends on manipulating the price feed that the protocol relies on. Common targets include:

• DEX-based oracles that calculate price based on a pool's reserves, which the attacker can skew.
• Time-weighted average price (TWAP) oracles with short windows that can be manipulated before the average updates. The protocol incorrectly values the inflated collateral, enabling excessive borrowing.

In January 2022, the Wonderland treasury was exploited via an inflation attack on MIM (Magic Internet Money). The attacker:

1. Created a new token and established a liquidity pool with MIM.
2. Drastically inflated the new token's supply, manipulating the pool's ratio and thus the oracle price of MIM.
3. Used the artificially cheap MIM as collateral to borrow other assets from Abracadabra.money, causing significant losses.

Protocols defend against inflation attacks through several mechanisms:

• Using robust oracles like Chainlink that draw from multiple, high-liquidity sources.
• Implementing collateral whitelists and rigorous due diligence for new assets.
• Applying circuit breakers or debt ceilings for specific collateral types.
• Utilizing time-locked oracles or longer TWAP windows to resist short-term manipulation.

A similar attack vector targets share-based liquidity pools (e.g., in staking or yield vaults). An attacker donates a large amount of a single asset to the pool, artificially inflating the value of LP shares. This allows them to withdraw a disproportionate amount of the other assets in the pool before the share price corrects. Defended against by using a virtual balance or a minimum lockup period.

A canonical thought experiment for the attack vector. An attacker targets a new pool with a low total value locked (TVL). The process is:

1. Donate a large amount of Token A to the pool, skewing the constant product formula x * y = k.
2. The pool now reports a wildly inflated price for Token B.
3. The attacker uses this manipulated price as an oracle to borrow assets against Token B on a lending protocol. This highlights the oracle manipulation risk from low-liquidity pools.

Inflation attacks pose a unique threat to stablecoin liquidity pools (e.g., USDC/DAI). Because the assets are pegged, a large, malicious donation can:

• Drastically lower the spot price of one stablecoin far below its $1 peg.
• Create a permanent loss scenario for liquidity providers (LPs) that cannot be arbitraged away easily.
• Undermine the core stability assumption of the pool. This case study emphasizes that even pools of high-quality assets are not immune to this economic exploit.

Many launchpads and Initial DEX Offerings (IDOs) now implement specific rules to prevent inflation attacks, turning case studies into best practices. Common mitigations include:

• Hard caps on initial liquidity to prevent disproportionate contributions.
• Vesting schedules for team/early investor tokens to limit immediate sell pressure.
• Liquidity locks using smart contracts to ensure the paired asset cannot be removed.
• Dynamic pricing mechanisms instead of fixed-ratio launches.

Requiring a minimum amount of liquidity to be locked upon pool creation is a foundational defense. This prevents an attacker from creating a pool with a trivial amount of the legitimate token and a massive amount of the malicious token. A common implementation is to require the first liquidity deposit to be a significant, non-withdrawable amount, raising the capital cost of the attack. This is often the first line of defense in protocols like Uniswap V2 and its forks.

Many inflation attacks use fee-on-transfer tokens, where a tax is levied on each transaction. To mitigate this, AMMs can implement checks that compare the actual token balance received against the expected amount. If a discrepancy is detected (indicating a fee), the transaction can be reverted. This prevents the pool's internal accounting from being desynchronized from the actual token balances, which is a key vulnerability exploited in these attacks.

This strategy prevents the first liquidity provider from setting the initial price. Instead, the pool remains inactive until a sufficient amount of liquidity from multiple, independent depositors is added. This ensures the initial price reflects a more honest market consensus rather than being set by a single, potentially malicious actor. It removes the attacker's ability to be the sole price setter for the new pool.

Decentralized exchanges or lending protocols can implement token list policies to exclude known malicious or non-standard token types. This is a proactive, though more centralized, measure.

• Blacklisting: Blocking tokens with known dangerous mechanics (e.g., certain fee-on-transfer or rebase tokens).
• Whitelisting: Only allowing tokens that have passed a security review or community governance vote. This shifts the burden of due diligence to the protocol or its DAO.

A critical non-technical mitigation is educating users on the risks of providing liquidity to new or unaudited pools. Key warnings include:

• Never be the first LP in a pool for an unknown token.
• Verify that the pool creator has locked a substantial amount of liquidity.
• Be cautious of pools containing tokens with unusual contract code. Informed LPs are the last line of defense against social engineering aspects of the attack.

Newer AMM designs incorporate architectural changes that reduce the attack surface. For example, Uniswap V3's concentrated liquidity model means initial LPs typically deposit significant capital into tight price ranges, making it economically unfeasible to manipulate the price across the entire curve. The focus on larger, targeted capital deposits inherently raises the cost of an inflation attack compared to V2-style pools where liquidity is spread uniformly.

This is the core mechanism of an inflation attack, where an attacker mints a large number of low-value tokens to dilute the holdings of existing users in a liquidity pool. The attack exploits the constant product formula (x * y = k) used by Automated Market Makers (AMMs) like Uniswap V2.

• Process: The attacker adds a massive amount of a worthless token to the pool, drastically skewing the ratio.
• Result: The pool's price oracle reports an artificially inflated value for the worthless token, allowing the attacker to drain legitimate assets.

A specific, common scenario for inflation attacks targeting newly created liquidity pools with low Total Value Locked (TVL). The attack is cost-effective here because minting the attack tokens and providing minimal paired liquidity (e.g., ETH) is cheap.

• Vulnerability: Pools created without a liquidity provider (LP) lock or with no initial minted tokens are prime targets.
• Prevention: Projects should pre-mint a portion of the token supply and seed the initial pool themselves, or use a locker contract for the initial LP tokens.

A DeFi primitive that can be used to execute an inflation attack by providing the upfront capital required. While not the attack itself, flash loans lower the barrier to entry for such exploits.

• Role in Attack: An attacker can borrow a large amount of a legitimate asset (e.g., ETH) via a flash loan, use it to provide the paired liquidity for their minted tokens, execute the swap to drain the victim's assets, repay the loan, and keep the profit—all within a single transaction.
• Consideration: This makes attacks feasible for actors without significant initial capital.

A user-defined parameter in decentralized exchanges that, if set incorrectly, can exacerbate losses during an inflation attack. It determines the maximum acceptable price movement for a trade.

• Attack Vector: An attacker can create extreme slippage by manipulating the pool's reserves. If a user has a high slippage tolerance setting, their swap may execute at this artificially terrible price, resulting in significant loss.
• Best Practice: Users should set low, conservative slippage tolerances (e.g., 0.1-0.5%) for swaps, especially in pools with new or low-liquidity tokens.

A practical case study occurred in May 2022 against a Rari Capital Fuse pool. An attacker executed a classic inflation attack:

• Used a flash loan to deposit a massive amount of a single asset.
• A victim made a normal deposit, receiving a tiny share of the now-inflated pool.
• The attacker withdrew, burning the victim's share value. This incident demonstrated the risk to non-ERC-4626 compliant pools and led to a loss of approximately $11 million, underscoring the need for standardized vault logic.

Developers can implement several defenses:

• Seed Liquidity: Deploy the vault with an initial deposit (a "seed") to establish a base share price, making inflation economically prohibitive.
• Use preview Functions: As per ERC-4626, always call simulation functions before committing funds.
• Oracle-Based Deposits: For non-standard pools, use a trusted external price oracle (e.g., Chainlink) to calculate deposit amounts instead of relying solely on the pool's internal ratio.
• Dead Share Prevention: Implement a minimum share minting requirement to block dust attacks.

A closely related exploit that is the inverse of an inflation attack. In a donation attack, an attacker donates (or transfers without minting shares) a large amount of tokens to a vault. This artificially inflates the value per share. The attacker then deposits a small amount to mint shares at the inflated price. When the share price corrects (e.g., after a victim's withdrawal), the attacker profits. Both attacks exploit the manipulability of share price in simple vault implementations.

Security auditors focus on specific red flags for inflation/donation vulnerabilities:

• Does the vault lack an initial seed deposit?
• Are deposit/mint functions susceptible to front-running?
• Does share calculation rely solely on internal balances without safeguards?
• Is the contract not compliant with ERC-4626 preview function requirements?
• Can the totalAssets() or totalSupply() be manipulated in a single transaction (e.g., via flash loans)? Addressing these points is critical for secure vault deployment.