Cowrie Research

first-deposit-inflation

16 min read

First-Deposit Inflation / Zero-Share Victimization

  • Name: First-deposit inflation / zero-share victimization
  • Category: exploit pattern / vault-bootstrap failure / donation attack / share-accounting manipulation
  • Summary: This pattern appears when an empty or near-empty vault lets the first shareholder set the opening exchange rate for everyone else. The attacker seeds the vault with dust, forces assets into totalAssets without minting matching shares, then frontruns the first real depositor so their deposit rounds down to zero or almost zero shares. The vault has not created borrowable fake collateral yet; it has simply reassigned the victim’s assets to the attacker’s tiny opening share position.
  • What it is:
    • Share-based vaults usually mint against some form of assets * totalSupply / totalAssets math.
    • In an empty vault, the first depositor effectively defines the starting share distribution.
    • If the vault also counts direct donations, pre-sent assets, or other unsolicited balance increases in totalAssets, the first shareholder can move the exchange rate before the next user arrives.
    • Because share minting rounds down, a victim deposit can legitimately transfer assets into the vault while minting zero shares.
    • Once that happens, the attacker still owns essentially all outstanding shares and can redeem the victim’s deposit as if it were normal vault value.
  • Typical preconditions:
    • The vault can start from totalSupply == 0 or from a nearly empty state with no meaningful dead shares or virtual offset.
    • totalAssets includes raw token balance or another quantity that can be increased without a corresponding share mint.
    • Deposit / mint math floors toward zero and does not revert on shares == 0 for a nonzero asset deposit.
    • The attacker can frontrun or sandwich the first meaningful honest deposit.
    • Bootstrap is permissionless, or launch seeding is left to convention rather than enforced state.
  • Common vulnerable surfaces:
    • ERC-4626 vaults deployed without virtual shares / virtual assets or minimum-liquidity seeding
    • older share vaults that read asset.balanceOf(address(this)) directly for accounting
    • strategy wrappers whose first honest depositor arrives after someone has already transferred underlying into the vault
    • low-supply vault states recreated after burns, claims, or redemptions shrink total supply back toward zero
  • Exploit sequence:
    1. The attacker becomes the first or dominant shareholder with a dust deposit.
    2. They donate, pre-send, or otherwise inject underlying assets into the vault without minting new shares.
    3. The first real depositor submits a normal deposit.
    4. Share-mint math rounds the victim’s shares down to zero or to an economically negligible amount because totalAssets is now huge relative to totalSupply.
    5. The victim’s assets stay in the vault anyway.
    6. The attacker redeems their tiny opening share position for most or all vault assets, which now include the victim deposit.
  • Variants:
    • Pure first-depositor frontrun — the canonical ERC-4626 launch-state attack where the next depositor gets zero shares.
    • Near-zero-supply replay — supply is later burned or claimed down to dust, recreating the same exploit surface without a fresh deployment; use reversible initialization semantics when the sharper preserved lesson is that live lifecycle state became bootstrap again rather than merely that the next depositor got zeroed out.
    • Donation-backed griefing — the attacker may not fully steal funds immediately, but can make early deposits economically irrational or force victims into negligible ownership.
    • Bootstrap-to-collateral bridge — instead of directly stealing the next deposit, the attacker uses the printed exchange rate in a sibling lending market; at that point the exploit graduates into the broader donation / share-price manipulation family.
  • Boundary tests that keep this pattern distinct:
    • Classify it here when the decisive theft is ownership misallocation inside the vault itself. If the preserved lesson is the next honest depositor transferred assets in but received zero or negligible shares, this note is doing the analytical heavy lifting.
    • Classify it under donation / share-price manipulation when the same printed exchange rate is mainly monetized through collateral borrowing, self-liquidation, cached NAV, rebasing balanceOf, or another downstream solvency rail. The bootstrap still matters, but the exploit has crossed into the broader exchange-rate fiction became borrowable or spendable truth family.
    • Classify it under fresh-market initialization failure when the first-actor advantage is mainly about lending-market launch sequencing rather than direct vault depositor theft. If the interesting question is who controlled the opening reserve state before collateralization was supposed to be safe, the lending-launch note is sharper.
    • Classify it under empty-market exchange-rate inflation when the vulnerable object is already a lending-market receipt token or reserve index rather than the vault’s own share-allocation step. There the attacker is not mostly stealing from the next vault depositor; they are turning tiny-supply market math into fake borrow power.
    • Ask whether the same attack still matters once a second honest depositor has already minted meaningful shares. If the exploit dies as soon as ownership is no longer concentrated and the main edge was the attacker defining the opening capitalization table, keep it here.
  • Detection heuristics:
    • Simulate an empty-vault bootstrap with a 1 wei first deposit followed by a direct donation and then a normal user deposit.
    • Check whether any nonzero deposit can mint 0 shares in reachable states.
    • Test whether unsolicited asset transfers change previewDeposit, previewMint, or convertToShares in ways a first shareholder can exploit.
    • Model recovery-to-near-zero states, not just the original deployment moment.
    • Treat shares == 0 on nonzero deposit as a security finding, not merely a UX bug.
  • Defenses:
    • Use meaningful virtual asset / virtual share offsets so the first shareholder cannot cheaply dominate the opening rate.
    • Seed dead shares or locked minimum liquidity that cannot be redeemed away.
    • Revert when a nonzero deposit would mint zero shares.
    • Consider internal accounting that ignores unsolicited donations when the vault model allows it.
    • Gate bootstrap behind an atomic seeding flow or a trusted initializer if the vault cannot otherwise defend its opening state.
    • Re-test low-supply edge states after claims, burns, migrations, and emergency exits; bootstrap risk can come back.
  • Practical guardrails worth preserving:
    • Preserve the same-state fairness invariant explicitly: after any reachable attacker donation or pre-send, the next nonzero honest deposit must either mint a non-negligible share amount or revert. assets transferred, shares = 0 is not a tolerable bootstrap edge case.
    • Treat capitalization-table integrity as the real security property. The first user should not be able to define a redeemable ownership structure that later users can fund but not join.
    • Test bootstrap replay, not just fresh deployment. If claims, burns, debt repayment, emergency exits, or solver mistakes can drive live supply back toward dust, the launch bug has merely moved later in time.
    • Keep collateral onboarding separate from bootstrap whenever possible. A vault whose opening exchange rate is not yet economically trustworthy should not already be accepted as money-good collateral elsewhere.
    • Make donation neutrality an explicit design choice. Either unsolicited assets are ignored for share-mint purposes, or the vault must maintain enough virtual liquidity / dead shares that they cannot zero out the next depositor.

What sound design looks like

  • The vault has a capitalization floor that costs real money to dominate. Virtual assets / shares, dead shares, or an irreversible seed position ensure that dust depositor owns basically everything is not a reachable opening state.
  • The fairness invariant is enforced at execution, not assumed from previews. A nonzero honest deposit either receives a meaningful claim on vault ownership or the transaction reverts; assets in, zero shares out is treated as a security failure rather than an unfortunate rounding outcome.
  • Bootstrap is a one-way lifecycle phase, not a condition inferred from totalSupply happening to be tiny. If the vault later decays toward dust supply, it enters a degraded runtime mode with fresh guardrails instead of silently reusing first depositor sets the table semantics.
  • Donation handling is explicit. Either unsolicited assets are excluded from mint-fairness math, or the vault keeps enough permanent virtual / dead liquidity that a direct transfer cannot cheaply rewrite the next user’s ownership price.
  • Presentation and collateral trust lag behind bootstrap trust. A just-seeded or near-zero-supply exchange rate may be locally useful for accounting, but it should not instantly become downstream collateral truth, oracle input, or same-block spendable value elsewhere in the system.
  • Recovery paths preserve the same ownership guarantees as launch paths. Burns, migrations, emergency exits, reward sync, sweeps, and recapitalization routines should not let the system accidentally recreate a world where one residual shareholder defines everyone else’s entry price.
  • When a live vault does fall back into dangerous low-supply territory, the safe next step is an explicit recovery / recapitalization mode rather than letting the next ordinary user deposit decide the new capitalization table by accident.
  • The clean design target is simple: no untrusted actor should ever be able to fund the vault with dust, move totalAssets with donations or pre-sends, and thereby decide whether the next honest user is allowed to become an owner at all.

Three low-supply promotions reviewers should not collapse

  • The vault is empty or near-empty again is only the first fact. It says the system has re-entered a dangerous economic shape, not that any newly printed exchange rate or share split is automatically trustworthy.
  • The protocol published one local share-pricing answer for that low-supply state is stronger. Preview functions, convertToShares, reward-sync paths, or recapitalization helpers may now expose one canonical-looking rate — but that still only means the protocol has expressed a local accounting answer.
  • Users or downstream systems may now spend against that answer is stronger again. Ordinary deposits, borrow-side collateral admission, liquidations, routed withdrawals, or oracle consumers may now honor that low-supply rate as money-good truth.
  • Strong review keeps those steps separate: runtime low supply, locally published pricing, and later economic authority. Many incidents happen because a system collapses them into one vague belief that the vault has a price again, when the real question is whether that price had actually re-earned the right to move money.

Failure-prevention checklist

  • Make nonzero assets in imply nonzero meaningful shares out or revert. Do not accept assets transferred, shares = 0 as a permissible bootstrap outcome.
  • Add meaningful virtual assets / virtual shares or irredeemable minimum liquidity so the first depositor cannot own essentially 100% of supply for dust cost.
  • If unsolicited donations are counted in totalAssets, prove they still cannot push the next honest deposit below a minimum-share threshold in any reachable low-supply state.
  • If unsolicited donations are not meant to affect mint fairness, use internal accounting that tracks managed assets separately from raw token balance and make sync paths explicit.
  • Gate launch and reseed flows so the first economically meaningful state is created atomically rather than left to mempool races.
  • Re-test all paths that can return the vault to near-zero supply: emergency exits, bad-debt socialization, sweeps, full redemption waves, migrations, burns, and claim flows.
  • If low supply reappears in production, route recovery through an explicit recapitalization path with temporary deposit / collateral restrictions instead of letting ordinary flow reuse bootstrap semantics.
  • Keep preview functions honest under adversarial pre-sends. previewDeposit, convertToShares, and actual deposit execution should not diverge in ways that hide zero-share victimization.
  • Treat rounding policy as part of the security model. If floor rounding can erase small deposits, enforce minimum deposit sizes or minimum-share checks at the entrypoint.
  • Delay or forbid collateral admission until the vault has crossed an explicitly safe capitalization threshold and bootstrap-sensitive states are no longer reachable.
  • Monitor for abnormal low-supply plus high-asset states and pause if the capitalization table becomes obviously attacker-definable again.

Audit prompts

  • Starting from totalSupply == 0 or 1, can an attacker donate or pre-send assets so the next honest deposit mints zero or negligible shares while still transferring assets in?
  • What exact quantity does totalAssets() read, and which of its components can increase without a corresponding share mint?
  • Does the contract revert whenever deposit(assets > 0) would mint 0 shares? If not, what user-protection story is supposed to make that safe?
  • Are there lifecycle paths that recreate launch semantics later, such as all-but-total redemptions, burned supply, migration drains, or claim routines that can collapse supply back toward dust?
  • Can preview functions be manipulated through direct transfers, reward syncs, rebases, or accounting lag so users see fair quotes but execution lands in a zero-share state?
  • How expensive is it for the first depositor to control the opening capitalization table, and what irreducible minimum economic commitment must they lock to do so?
  • If the vault is later used as collateral, oracle input, or settlement reference, at what point does bootstrap-sensitive share pricing become trusted elsewhere in the system?
  • Are dead shares, virtual offsets, or minimum-liquidity seeds actually nonrecoverable, or can governance, admin flows, or lifecycle bugs reclaim them and reopen the attack?
  • Does the system distinguish between vault balance increased and vault earned value, or are donations silently promoted into redeemable ownership math?
  • In incident tooling, can operators quickly see assets, supply, recent donations, and the effective shares-per-asset rate at the moment of first or near-first deposits?

Lessons that should already be standard

  • Launch state is not a harmless edge case. In share systems, bootstrap is ownership policy.

  • A vault should never be allowed to accept real assets from a user while giving them no economically meaningful claim in return.

  • Donation sensitivity is a design choice, not a law of nature. If raw balance can move exchange rate, the protocol must either neutralize that path or make bootstrap capitalization expensive enough that it cannot be gamed for dust.

  • First depositor sets the market is too much authority for an untrusted actor when later users inherit that capitalization table as if it were fair.

  • Near-zero-supply states deserve the same paranoia as fresh deployment. If bootstrap can reappear after months of live operation, the launch bug was never really fixed.

  • Preview and UX correctness are insufficient. The real invariant is fairness at execution time under adversarial state changes and unsolicited transfers.

  • Collateralizing or oracle-feeding a vault before its share distribution is robust turns a local ownership bug into a system-wide solvency bug.

  • High-signal examples:

    • OpenZeppelin’s ERC-4626 inflation-attack writeup remains the canonical worked example of the attack path: 1 unit deposited, u units donated, then a victim deposit u mints 0 shares because the attacker already owns the entire share supply. The enduring value is not only the arithmetic but the fairness invariant it exposes: the next depositor can transfer real assets in while receiving no ownership at all.
    • GoGoPool ggAVAX first-depositor share-price inflation near miss (2023-01-03) is the cleanest preserved protocol-specific near miss of the pure pattern: an unseeded vault, a 1 wei opening depositor, a large direct WAVAX donation, and a public syncRewards() path that let the attacker turn that donation into counted assets quickly enough to steal roughly 500 AVAX from a later 2000 AVAX depositor while also zeroing out smaller deposits.
    • Euler’s exchange-rate-manipulation writeup is the useful follow-on because it explains why dead shares, virtual offsets, and internal accounting change the economics but do not magically make every vault-share integration safe once the same printed exchange rate crosses into collateral logic.
    • infinite-mint exploit (2025-11-30) is the best preserved live reminder that bootstrap risk can come back: the attacker first drove a live pool back to prev_supply == 0, then a 16 wei dust deposit re-entered initialization logic and minted effectively infinite LP.
    • zero-exchange-rate exploit (2025-06-26) is the useful contrast case where the same near-empty-vault economics no longer steal from the next depositor directly; instead, the printed exchange rate crosses the boundary into lending collateral math and becomes a donation / share-price manipulation exploit.
    • first-depositor capture preserves the lending-market cousin where the same first actor defines opening state problem is monetized through a new borrow market instead of direct theft from the next depositor.
    • share-price manipulation is the parent family when the attacker turns the same printed exchange rate into collateral value, bad debt, or downstream oracle failure.

Internal linkages

Control surface

  • The decisive leverage sits in bootstrap state, rounding direction, whether unsolicited assets count as earned value, and whether the first honest depositor can ever receive zero shares.
  • The vulnerability is not just bad math. It is an ownership-allocation failure at vault birth: the protocol lets one actor define the opening capitalization table and then treats later deposits as if that table were trustworthy.

Sources

Last reviewed

  • 2026-07-31 UTC

Graph View

Backlinks