ERC-4626 vulnerabilities keep showing up in audits and post-mortems years after the ecosystem thought the fix was settled, and the inflation attack, also called the first-depositor or donation attack, is the clearest example. If you're building or reviewing a vault, you need to know how an attacker can manipulate a fresh vault's share price before your first real user ever deposits, and what a 2026-grade vault needs to close the gap the standard itself still leaves open.

What Is an ERC-4626 Inflation Attack? One of the Most Common ERC-4626 Vulnerabilities

An ERC-4626 inflation attack is a first-depositor exploit where an attacker mints a trivial number of vault shares, then directly transfers, or "donates," a large amount of the underlying asset straight to the vault contract, bypassing the deposit function. That donation inflates the vault's asset-per-share ratio so severely that the next depositor's shares round down to zero, and the attacker redeems their own shares to claim the donated funds plus your user's stranded deposit. If you deploy a vault without accounting for this, you're exposed the moment totalSupply sits at zero or near it.

The Share-Price Math That Makes It Possible

ERC-4626 vaults price shares as a ratio: shares = assets * totalSupply / totalAssets. In a brand-new vault, whoever deposits first controls both sides of that ratio. An attacker mints 1 share for 1 wei of the asset, then transfers a large donation directly to the vault so totalAssets balloons while totalSupply stays at 1. When your next real depositor calls in, their assets * totalSupply / totalAssets calculation rounds down to zero shares, and their assets sit in the vault for the attacker to claim on redemption.

Why This Is Still One of the Most Common ERC-4626 Vulnerabilities

Two things keep this attack alive. First, you have to apply the fix per vault at deployment time, and it's easy to skip if you copy an older template or roll your own share-price math. Second, even if you've adopted OpenZeppelin's virtual shares defense, you can still be exposed if you leave decimalsOffset() at zero, or if your vault's exchange rate feeds an external price oracle that an attacker can distort for profit elsewhere, as the sDOLA and Venus cases below show.

How Do Attackers Exploit the First-Depositor Window?

Attackers exploit the first-depositor window by watching for an empty vault, minting a minimal share position, donating assets directly to the contract to spike the share price, and waiting for a real deposit to round down to zero shares before redeeming everything themselves. The window closes the moment a vault has meaningful, evenly priced liquidity, which is exactly why the attack targets brand-new or freshly redeployed vaults. If you're launching one, the first block matters more than you'd think.

Step-by-Step: Donation, Rounding, Theft

Here's how it plays out, step by step:

1. Watch for deployment. The attacker monitors the mempool or a factory contract for a new ERC-4626 vault with zero or near-zero totalSupply.
2. Mint the seed position. The attacker deposits the smallest possible amount, often 1 wei of the underlying asset, and receives 1 share.
3. Donate to inflate the ratio. The attacker transfers a much larger amount of the underlying asset directly to the vault's address using a plain token transfer, not the deposit function, so totalSupply does not change.
4. Wait for the victim. A legitimate user calls deposit, and the vault's rounding math (assets * totalSupply / totalAssets) truncates their share allocation to zero, or close to it.
5. Redeem and extract. The attacker calls redeem on their single share, which now represents the entire donated balance plus the victim's stranded deposit.

A Worked Example With Real Numbers

OpenZeppelin's own ERC-4626 documentation quantifies the cost of this attack precisely: absent a decimals offset, if a victim is about to deposit u assets, "the attacker only needs u+1 assets to perform a successful attack," according to the OpenZeppelin Contracts 5.x docs. In other words, an unprotected vault hands the attacker a profit margin worth roughly your victim's entire deposit, for the cost of matching it by one unit. That's a strikingly cheap trade for the payoff, which is exactly why the defense had to move from "audit finding" to "default constructor behavior," and why you shouldn't treat it as optional.

What Recent Exploits Show About ERC-4626 Vulnerabilities

Inflation and donation attacks against ERC-4626 vaults aren't a 2022 problem the ecosystem solved and moved past. Three separate incidents across 2025 and 2026, hitting different chains, different asset types, and different vault implementations, show the same rounding and donation mechanics still working against production protocols.

sDOLA / LlamaLend (March 2026): $245K and a 13.79% Rate Jump in One Block

On March 2, 2026, an attacker manipulated the sDOLA/crvUSD LlamaLend market by combining a large exchange on the LLAMMA AMM with a DolaSavings.stake() call to inflate the sDOLA oracle price. That single-block price spike hard-liquidated 27 borrowers holding roughly $10.9 million in debt, with approximately $822,475 in borrower equity seized, and the attacker netted roughly $245,000, per the same LlamaRisk report. The post-mortem attributes the root cause partly to the "absence of oracle smoothing" and a "manipulable convertToAssets()." Because the sDOLA-long2 market's oracle predates LlamaLend's later oracle proxy architecture, LlamaRisk notes it can't be patched in place and is being deprecated instead. If your vault's exchange rate feeds anyone else's oracle, this is the failure mode to design against before launch, not after.

Resupply (June 2025): $9.5M From a 2,000 crvUSD Donation

On June 26, 2025, an attacker donated 2,000 crvUSD to a Resupply vault and deposited just 2 crvUSD to mint 1 wei of cvcrvUSD, then used that manipulated position to borrow 10 million reUSD, for a total protocol loss of $9.5 million, according to QuillAudits' hack analysis of the Resupply exploit. QuillAudits' analysis puts the mechanism plainly: "Donated funds increase the balance of the vault, which inflates the price of each share in the pool." The team's recommended fix, virtual shares and a decimals offset, is the same defense OpenZeppelin ships by default, and it's the first thing worth checking if you're reviewing a vault deployed before 2023.

Venus Protocol (February 2025): Exchange-Rate Manipulation Beyond a Single Vault

Vaults whose share price is read by another protocol as collateral pricing matter beyond any single incident because the manipulated vault token can be used as collateral in a lending market. Unlike a normal spot-priced token, arbitrage can't correct an artificially inflated vault share price the way it corrects a mispriced asset on an open market, which is why OpenZeppelin now recommends capping the growth rate of any vault exchange rate feeding an external price consumer. If your vault token ever becomes someone else's collateral, you inherit this risk whether you planned for it or not.

What Does a 2026-Grade Secure Vault Look Like?

A secure ERC-4626 vault in 2026 combines three layers of defense: constructor-level protection against share-price manipulation, deposit-time liquidity locks that remove the zero-supply window entirely, and, if your vault's exchange rate feeds external protocols, rate-of-change limits on the oracle side. No single layer is sufficient on its own, as the Napier and sDOLA cases both show, so don't stop at the first fix that seems to work.

Virtual Shares and Decimal Offsets

OpenZeppelin's defense adds virtual shares and virtual assets to the exchange-rate formula, so the vault behaves as though it already holds a baseline of assets and shares even when real deposits are zero. Combined with a decimals offset, giving vault shares more decimal precision than the underlying asset, this makes the attack mathematically unprofitable. As OpenZeppelin puts it, "a virtual offset restricts the attacker's ability to manipulate the exchange rate effectively by including both virtual shares and virtual assets in the exchange rate computation." The Napier finding above is the catch: this only holds if you've actually set the offset above zero at deployment.

Minimum-Liquidity / Dead-Share Locks

A second, complementary pattern burns or permanently locks a small number of shares at deployment, borrowed from Uniswap V2's MINIMUM_LIQUIDITY design. This removes the zero-supply state entirely, so there's never a moment when a single attacker-controlled share represents the whole vault. If you're weighing this against a decimals offset, the Sherlock audit finding against Napier's LSTAdapter recommended it as an alternative or supplement, not a replacement.

Oracle Smoothing and Per-Block Rate-of-Change Caps

For vaults whose share price is read by another protocol as collateral pricing, internal vault defenses aren't enough, because the damage happens downstream in a lending market rather than inside the vault itself. If you're building on top of someone else's vault as collateral, take note: LlamaRisk's post-mortem recommends EMA or TWAP smoothing plus per-block rate-of-change caps for any future market built on a similar design.

ERC-4626 Audit Checklist for Founders

Before your vault contract goes to mainnet, run through this checklist. It isn't exhaustive, but it covers the specific failure modes behind the exploits above.

This mirrors the broader questions any Solidity security review has to ask about arithmetic and rounding, and sits inside the wider pre-launch security checklist you should run before mainnet.

When to Bring In an External Auditor

If you've never shipped an ERC-4626 vault before, don't rely solely on an internal checklist. QuillAudits' research hub lists a dedicated ERC-4626 Vault Security Audit Checklist covering "share price, inflation attacks, rounding, totalAssets, previews, reentrancy, oracles, and strategies." Getting that kind of review at the design stage matters here specifically because the decimals offset and dead-share lock are constructor-time decisions; they're far cheaper to set correctly before deployment than to patch afterward, as the sDOLA case shows, where the oracle couldn't be fixed in place and had to be deprecated instead.

That said, a checklist and a multi-chain audit practice aren't your only options. If you're still at the prototype stage, you might get more value from running free static analysis tooling, such as Slither or the OpenZeppelin and Foundry fuzzers, before paying for a full audit. And if you've built entirely inside one non-EVM ecosystem, a pure Solana Anchor vault, for instance, a boutique auditor with narrower but deeper tooling in that specific stack may serve you better. If your project spans EVM chains alongside Solana, Base, or other RWA and tokenization chains, it's worth weighing a multi-chain generalist audit against those narrower options.

Final Thoughts

The inflation attack survives in 2026 not because the fix is unknown, it's been documented since OpenZeppelin published virtual shares, but because it's a per-vault, per-deployment decision rather than something the ERC-4626 standard enforces. The sDOLA/LlamaLend, Resupply, and Venus incidents each hit a vault that had the general shape of ERC-4626 right and one specific guard missing: an offset left at zero, an oracle with no smoothing, or a liquidity vault with room to game the first-depositor window. Not every vault is protected the same way, and not every ERC-4626 vulnerability gets caught by the same layer of defense, which is why you're better off checking share-price math, liquidity locks, and downstream oracle consumers separately, rather than trusting a single fix to cover your whole attack surface. If you're building or extending an ERC-4626 vault, a Blockchain Audit can check where your implementation stands against this pattern before it becomes the next post-mortem.