Inflation Attacks are a class of vulnerabilities affecting tokenized vaults, particularly ERC-4626 implementations, where attackers manipulate the share-to-asset exchange rate by directly transferring assets to the vault contract without using the deposit function. This manipulation causes subsequent depositors to receive dramatically fewer shares than they should, with the attacker able to redeem their shares to claim a disproportionate amount of the total assets including the victim's deposits.

The attack gained widespread attention in DeFi security research after affecting several early vault implementations. As documented in the Arbitrary Execution blog series referenced in the article about the Burve Protocol audit, this vulnerability stems from the mathematical relationship between total assets, total shares, and the exchange rate used to calculate how many shares to mint for a given deposit.

Attack Mechanics and Execution

The inflation attack exploits the initial state of a vault when no shares have been minted yet. The attack sequence follows a precise pattern that manipulates integer division rounding. First, the attacker makes a minimal deposit to the vault, typically just 1 wei of the underlying asset. This deposit causes the vault to mint 1 share to the attacker, establishing the initial share-to-asset ratio of 1:1.

Next, the attacker directly transfers a large amount of assets to the vault contract without calling the deposit function. This is the critical step—direct transfers increase the vault's totalAssets() value without minting any new shares. If the attacker transfers 1,000,000 tokens, the vault now holds 1,000,001 tokens total but still has only 1 share in circulation. The exchange rate has been artificially inflated to approximately 1 share = 1,000,001 tokens.

When a victim attempts to deposit, the vault calculates their shares using the standard formula: shares = assets * totalSupply() / totalAssets(). If the victim deposits 1,000 tokens, the calculation becomes shares = 1000 * 1 / 1,000,001 = 0.00099..., which rounds down to 0 shares due to Solidity's integer division. The victim receives no shares despite their deposit successfully completing.

Finally, the attacker redeems their 1 share using the inflated exchange rate, receiving back their original 1 wei deposit plus the 1,000,000 tokens they donated plus the victim's 1,000 tokens—netting a profit of 1,000 tokens at the victim's expense. The attack is economically viable when the stolen amount exceeds the cost of the donation, which the attacker recovers.

Mathematical Foundation and Rounding Exploitation

The vulnerability fundamentally exploits rounding errors in integer arithmetic combined with attacker-controlled input to the exchange rate calculation. Ethereum's EVM operates exclusively with integer arithmetic, meaning any division operation that would produce a fractional result simply discards the remainder. When shares are calculated as (amount * totalSupply) / totalAssets, small numerators divided by large denominators round to zero.

The attacker's donation inflates the denominator (totalAssets) while keeping the numerator (totalSupply) minimal. This creates maximum rounding impact—even substantial deposits from victims may calculate to zero shares. The mathematical relationship requires that victim deposits must exceed the donation amount to receive even a single share, effectively establishing a "minimum deposit threshold" that the attacker controls.

Some implementations attempt to use 18-decimal fixed-point arithmetic to reduce rounding impact, but this only shifts the threshold—it doesn't eliminate the vulnerability. If calculations use a scaling factor of 10^18, attackers can still donate amounts that force rounding to zero, though they must donate correspondingly larger amounts to achieve the same effect.

Prevention and Mitigation Strategies

The most common defense against inflation attacks involves initial share seeding—burning a portion of the first deposit to create a permanent floor on total share supply. When the vault is initialized, a substantial first deposit (e.g., 1,000 tokens) is made and a corresponding number of shares are immediately burned to the zero address. This establishes a non-zero baseline that makes inflation attacks economically infeasible.

OpenZeppelin's ERC-4626 implementation provides internal virtual functions that derived contracts can override to implement this mitigation. The pattern typically involves checking if this is the first deposit (totalSupply() == 0), requiring a minimum deposit amount, minting shares normally, then burning a substantial portion to address(0). Future deposits calculate against this burned share floor, preventing effective inflation.

Minimum deposit requirements provide a simpler but less robust defense. By requiring the first deposit to be substantial (e.g., 1,000 tokens minimum), vaults raise the economic cost of the attack. However, this approach has limitations—it creates poor user experience, doesn't prevent the attack mathematically (just makes it expensive), and can be bypassed if the attacker can make the first deposit themselves.

Virtual assets/shares accounting modifies the share calculation to include a virtual offset, making the denominator and numerator larger by fixed amounts. This dilutes the impact of donated assets on the exchange rate. The formula becomes shares = (amount * (totalSupply + virtualShares)) / (totalAssets + virtualAssets). While this reduces attack effectiveness, careful parameter selection is required to balance security against user experience.

Detection and Auditing Considerations

Identifying inflation attack vulnerabilities during audits requires analyzing the vault's share minting logic, particularly during initialization. The competitive audit experience described in the article demonstrates the value of pattern recognition—auditors who have studied documented inflation attacks can quickly identify vulnerable implementations by examining how the first deposit is handled.

Key audit checkpoints include verifying whether the vault implements any first-deposit protections, checking if initial shares can be minted for minimal asset amounts, examining whether totalAssets() can be increased without minting shares (always true for ERC-20 tokens via direct transfer), and analyzing the economic viability of an attack given the vault's expected asset values and decimal precision.

Testing inflation attacks with Foundry is straightforward and should be part of every vault audit. A basic test performs the attack sequence: deploy the vault, make a 1-wei deposit as the attacker, directly transfer donation tokens, attempt a victim deposit, and verify that the victim receives zero shares despite their deposit succeeding. If this test passes (victim gets zero shares), the vulnerability exists.

Foundry's fuzzing capabilities can explore the attack's parameter space—varying donation amounts, victim deposit amounts, and decimal precision to identify exactly what combinations make the attack profitable. Property-based invariant tests should verify that the relationship (userShares * totalAssets) / totalSupply >= userOriginalDeposit always holds for all users, catching inflation attacks as invariant violations.

Real-World Incidents and Case Studies

While the Burve Protocol finding described in the article was discovered during a competitive audit before the protocol deployed to mainnet, several production protocols have suffered inflation attack exploits. Early implementations of vault strategies on Ethereum and Layer 2 networks lost funds before the vulnerability was widely understood, leading to the development of standard mitigation patterns now documented in security best practices.

The vulnerability particularly affects yield aggregator vaults that compose multiple strategies. When a meta-vault deposits into an underlying ERC-4626 vault, the meta-vault itself becomes a victim if the underlying vault is vulnerable. This composability risk means that inflation attack analysis must consider not just the immediate vault but the entire dependency chain of nested vaults.

Cross-chain vault deployments face additional risk because attackers can potentially execute the inflation attack more cheaply on networks with lower transaction costs. A vault implementation that seems economically protected on Ethereum mainnet (where gas costs make small attacks unprofitable) might be vulnerable on Layer 2 networks or sidechains where the attacker's donation cost is negligible.

Understanding inflation attacks requires recognizing them as a specific instance of the broader class of rounding error exploitation vulnerabilities. The attacker doesn't break any cryptographic assumptions or bypass access controls—they simply manipulate the mathematical environment in which share calculations occur, exploiting the deterministic but lossy nature of integer division. The attack demonstrates that protocol security depends not just on access control and logic correctness, but on economic game theory and mathematical properties of the implementation. As the article emphasizes, studying documented vulnerability patterns like inflation attacks provides auditors with a mental library of known issues to check, dramatically improving audit efficiency and findings quality.