ERC-4626 Inflation Attack and How to Mitigate It.

---

Now, let’s picture this together — a freshly deployed vault, seemingly secure, awaiting user deposits. Within minutes, an attacker deposits just 1 wei — an amount so small it’s almost laughable. But then, through a precise and calculated sequence of interactions, they take off more value than they ever put in, leaving legitimate users with worthless shares and broken trust.

This isn’t fiction — it’s a real vulnerability lurking in many seemingly “safe” smart contract architectures.

In this analysis, we look into this fine yet dangerous exploit that abuses vault share mechanics, donation timing, and reward synchronization to drain value from honest users. We break down how it happens, why it works, and how you can bulletproof your contracts against it.

ERC-4626 vaults are efficient, but they’re vulnerable to inflation attacks if not properly designed. Let’s take it step by step.

What is ERC4626?

ERC-4626 is a standard for tokenized vaults in Ethereum. A vault is like a smart contract that holds tokens and allows users to deposit and withdraw them.

Think of it like a bank account for tokens:

• You deposit a token (such as USDC), and the vault gives you shares in return. These shares represent your share of the vault’s total assets.

• When you withdraw, you return your shares, and the vault gives you back the underlying tokens.

The standard makes sure all vaults work in a consistent way, making it easier for DeFi apps to interact with them.

Understanding how the ERC-4626 inflation attack works

Vault Inflation Attack: The Piggy Bank Robbery

Think of the vault as a special digital piggy bank (called a “vault”) where people can deposit money. Instead of just keeping track of how much each person put in, this piggy bank gives out paper tickets (called “shares”) that represent ownership of what’s in the bank.

How It Normally Works

1. If you’re the first person to put money in the empty piggy bank, you get tickets equal to exactly what you put in.

• Example: You put in $10, you get 10 tickets.

2. If you deposit later, the piggy bank calculates your tickets like this:

• Your tickets = (Your deposit × Current total tickets) ÷ Current total money

• Example: If there’s already $100 in the bank with 100 tickets, and you deposit $50, you get: ($50 × 100) ÷ $100 = 50 tickets

3. When you want your money back, you return your tickets and get your fair share:

• Money you get = (Your tickets ÷ Total tickets) × Total money in bank

The Inflation Attack Step-by-Step

Here’s exactly how a sneaky person (let’s call them “Bob”) can steal your money:

1. First Move: Bob sees you’re about to put $100 into a brand new empty piggy bank. Bob quickly rushes ahead of you and puts in just 1 cent.

• Bob now has 1 ticket (0.01 shares)

• Total in bank: $0.01

• Total tickets: 0.01

2. Inflation Move: Bob then does something tricky. Bob “donates” $100 to the piggy bank without getting any new tickets. This is different from a normal deposit.

• Bob still has only 0.01 tickets

• Total in bank: $100.01

• Total tickets: 0.01

3. Your Deposit: Now you come along and deposit your $100. The piggy bank calculates your tickets:

• Your tickets = ($100 × 0.01) ÷ $100.01 = 0.00999… (which rounds down to 0 tickets)

• You get ZERO tickets for your $100!

4. The Theft: Bob now withdraws using their 0.01 tickets, which is 100% of all tickets in existence.

• Bob gets: (0.01 ÷ 0.01) × $200.01 = $200.01

• Bob put in $100.01 total but takes out $200.01

• Your $100 is gone!

Using a cookie jar illustration

Let’s assume you’re opening a brand new cookie jar where people can store their cookies safely. When someone puts cookies in, they get tickets showing how many cookies they own. This is basically what a “vault” is — a safe place to store digital money (like cryptocurrencies), where you get special tokens (called “shares”) representing your ownership.

1. First, Alice wants to put 100 cookies into the brand new cookie jar.

2. Before she can do it, a sneaky person (the attacker) quickly puts just ONE cookie in first.

3. Now, the attacker secretly slips 100 more cookies into the jar without taking tickets for them.

4. When Alice finally puts her 100 cookies in, something strange happens.

• The math says she gets 100 ÷ 101 = 0.99 tickets.

5. The attacker now takes ALL the cookies because they’re the only one with tickets.

How can the attacker get plenty of shares for almost nothing?

The key issue is how shares are calculated when the vault is new or near-empty.

In ERC-4626, the formula used to calculate shares is based on the relationship between the total assets in the vault and the total shares already issued. The formula is:

formula used to calculate shares in ERC-4626

Where:

• deposit amount: The amount of tokens being deposited by the user.

• total shares: The total number of shares that have been issued by the vault (this includes all shares already given to all users).

• total assets: The total value of tokens held by the vault.

1. First, they deposit just 1 wei (the smallest possible amount)

• When a vault is empty, the math is simple: they get 1 share for 1 wei

• This is because the vault uses the formula above.

• With no assets yet, it’s just 1 ∗ 1 / 1 = 1 share

2. Then they secretly send more tokens directly to the vault

• They don’t deposit these through the normal process

• This increases the vault’s total assets but doesn’t change the number of shares

• The vault’s math doesn’t account for these “donated” tokens differently

3. This creates a perfect trap for the next depositor

• When someone else tries to deposit, the math works against them

• The formula now looks like:

• Since donatedAmount is huge compared to 1, they get almost no shares

For example, if the attacker donates 100 tokens after their 1 wei deposit:

• When someone deposits 100 tokens, they get

• The attacker still has their 1 share

• The attacker can withdraw everything because they own all the shares

Why This Works

This works because the vault’s math rounds down when calculating shares. The attacker is essentially manipulating the denominator in the formula to make everyone else’s deposits worth almost nothing, while keeping their tiny deposit worth everything.

The key to this attack is that the vault treats all incoming tokens the same, whether they come through a proper deposit or are sent directly to the contract. This allows the attacker to artificially inflate the vault’s assets without getting more shares, making their existing shares worth everything

Analyzing the submission for prePO contest on code4rena

Looking at this submission on solidit, we see it’s similar to our discussion. This was found during an audit contest for prePO on code4rena. It was submitted as a high finding. This is why I called this vulnerability very dangerous initially.

Summary of the Attack in the Submission

The submission describes an inflation attack similar to what we discussed earlier. Here’s a simplified breakdown:

1. Initial Deposit (2 wei):

• The attacker deposits 2 wei, which is enough to mint 1 share (since there’s a minimum deposit amount).

2. Manipulating the Share Price (Massive Transfer):

• The attacker then sends a huge amount (1 million tokens) to the _strategyController to inflate the share price.

• This is similar to the manipulation of the vault’s assets to make it seem like the value of shares is higher than they should be. The share price rises, but this happens unfairly.

3. Subsequent Depositor (10,000 tokens):

• A new depositor tries to deposit a reasonable amount (10,000 tokens).

• However, because of the earlier inflation, their deposit doesn’t mint any shares.

• The attacker now controls all the shares, and the subsequent depositor receives 0 shares in return for their 10,000 tokens.

Relating This to Our Discussion on ERC-4626 Inflation Attacks

This attack directly exploits the mathematical formula for calculating shares and the fact that shares can be inflated by manipulating the total assets in the vault. Here’s how this relates:

1. Inflating Share Price:

• Just like in the ERC-4626 vault, the attacker manipulates the vault’s total assets to inflate the price of shares. This is similar to the attacker in our earlier example receiving 1 share for a small deposit, while the vault holds much more value.

• In this case, the attacker uses a massive transfer to the strategy controller, inflating the vault’s assets and, therefore, the value of shares.

2. No Share Issuance for Subsequent Depositors:

• After the share price has been inflated, subsequent depositors are at a disadvantage. They deposit a significant amount (e.g., 10,000 tokens) but receive 0 shares.

• This is similar to how in our previous example, the first depositor gets an unfair share (1 share for a very small deposit), and later depositors don’t get the appropriate share for their larger deposits.

3. The Attacker’s Advantage:

• Just like in the ERC-4626 inflation attack, the attacker in this scenario ends up controlling all the shares after manipulating the vault’s state. This gives them the ability to withdraw much more than they should when they want to.

Proposed Mitigation Steps in the Submission

Now, let’s analyze the recommended mitigation steps and how they relate to fixing the vulnerabilities in the ERC-4626 vault:

1. Uniswap V2’s Solution — Sending the First LP Tokens to Zero Address:

• The idea is to prevent the initial manipulator from gaining too much control over the vault’s shares.

• By sending the first set of tokens (or shares) to the zero address when the vault has no shares (i.e., when totalSupply() == 0), it essentially dilutes the share supply right from the start.

• This could prevent a single malicious user from receiving unfairly large share allocations from the start, which is a direct countermeasure against the attack we discussed.

2. Ensuring Non-Zero Share Minting:

• A simple check (require(_shares != 0, "zero shares minted");) ensures that if no shares are going to be minted, the function fails. This would prevent a situation where 0 shares are issued despite a deposit being made, which is what the attacker exploits to take over the vault.

3. Periphery Contract for Initialization:

• The idea of using a periphery contract that combines both the initialize() and deposit() functions could ensure that the vault is properly initialized with some deposits and shares before anyone else can deposit.

• This ensures that the vault’s state is safe from the initial manipulation and avoids the situation where a single user can unfairly dominate the share distribution.

Analyzing the submission for GoGoPool contest on code4rena

We can see another submission on GoGoPool contest in code4rena.

This case study illustrates a common vulnerability pattern in yield-bearing token implementations where the initial state of the contract can be exploited. It’s especially important for DeFi protocols that use ERC4626 or similar vault standards to be aware of this attack vector and implement proper initialization procedures.

The report details a high-severity vulnerability in GoGoPool’s ggAVAX token implementation that allows a malicious first depositor to artificially inflate the share price and steal funds from subsequent depositors.

Core Vulnerability

The vulnerability exists in the ERC4626 vault implementation, where the exchange rate between assets (AVAX) and shares (ggAVAX) is calculated as the ratio between totalSupplyof shares and totalAssets(). The attack works as follows:

1. Attacker front-runs the creation of the vault

2. Deposits a minimal amount (1 WEI) of AVAX to receive 1 share

3. Transfers a large amount of WAVAX directly to the vault

4. Calls syncRewards() to update the accounting

5. Due to the tiny number of shares vs the large amount of assets, the share price becomes severely inflated

Impact

The report identifies two serious consequences:

1. Fund theft: The attacker can withdraw significantly more assets than they deposited, effectively stealing from subsequent depositors.

2. Denial of service: Small depositors cannot deposit at all, as their deposits would convert to zero shares due to the inflated exchange rate, triggering a ZeroShares() revert.

Proof of Concept

The report includes a comprehensive Foundry test that demonstrates:

• Bob depositing 1 WEI and then donating 1000 AVAX

• Alice depositing 2000 AVAX but only receiving shares worth 1500 AVAX

• Bob withdrawing 1500 AVAX (stealing 500 AVAX from Alice)

• Small deposits below 1000 AVAX reverting entirely

Technical Details

The vulnerability exploits two specific aspects of the implementation:

1. The share price calculation in convertToShares() which uses the ratio of total supply to total assets

2. The reward cycle timing in syncRewards() which allows the attacker to quickly update accounting when conditions are favorable

Mitigation

The recommended solution is to seed the vault with initial funds during initialization, making it harder to manipulate the share price. This prevents front-running by including the initial deposit as part of contract initialization.

The report was confirmed by the GoGoPool team and the vulnerability was mitigated by implementing the recommended initialization with a deposit.

How to defend against this attack

From opezeppelin’s blog on A Novel Defense Against ERC4626 Inflation Attacks, these are some ways to defend against this attack.

Using an ERC4626 Router

This is a relatively straightforward approach, but it may only circumvent the issue rather than address it directly.

Keeping Track of Total Assets Internally

The second strategy aims to negate the effect of direct transfers by keeping track of the assets held by the vault internally. This means that donated tokens are not accounted for, which effectively eliminates the risk of inflation attacks.

Creating “Dead Shares”

This strategy is inspired by Uniswap V2, which created dead LP shares when the first liquidity was deposited. In ERC4626 vaults, a similar approach could be implemented by minting dead shares upon the first deposit/mint.

In the blog, you will find the pros and cons of each mitigation.

About the dead shares, you will see a full discussion on it here.

We can also see some mitigations and recommendations from the submissions we analyzed.

---

This analysis shows how dangerous small math mistakes can be in DeFi. A tiny 1 wei difference — something that seems harmless — can open the door to serious exploits, drain value, or block users from fair access.

The lesson? Never assume your math is safe just because it looks precise. Vaults, share calculations, and pricing logic all need to be tested like they’re potential points of attack — because they are.

If we want DeFi to be secure and trustworthy, we have to treat even the smallest details like they matter. Because in this space, they really, really do.

I like to call this Tiny Numbers, Big Risks.

Thank you for joining me today. I will see you next time