Cowrie Research

first-deposit-inflation

14 min read

First-Deposit Inflation / Zero-Share Victimization

  • Name: first-deposit inflation / zero-share victimization
  • Category: exploit pattern / vault-bootstrap failure / share-allocation theft / launch-state accounting bug
  • Summary: This pattern appears when an empty or near-empty share system lets the first meaningful actor define the opening capitalization table, then lets unsolicited assets, reward recognition, or other numerator-side growth reprice that table before the next honest participant arrives. The next depositor transfers real value in but receives zero, dust, or badly underpriced shares, while the attacker keeps the opening claim on the vault. In the broader corpus this often graduates into donation / share-price manipulation, but the pure version is simpler and meaner: the theft happens inside the share-allocation step itself.
  • What it is:
    • Share minting depends on assets * totalSupply / totalAssets or an equivalent ratio.
    • The attacker becomes the first or dominant shareholder when supply is zero or nearly zero.
    • They increase effective assets without minting matching shares, or otherwise reach a state where the next deposit prices against an attacker-controlled numerator.
    • Because minting rounds down or initialization logic is fragile, the next honest deposit receives zero or negligible ownership.
    • The attacker later redeems the victim-funded assets or uses the distorted state to reopen bootstrap-only logic.
  • Typical preconditions:
    • The system can reach totalSupply == 0, near-zero supply, or another launch-like state with no meaningful dead shares or virtual offsets.
    • totalAssets, reward inventory, or equivalent backing can increase outside the share-mint path.
    • Nonzero deposits can round to zero shares or initialization-only branches remain reachable after launch.
    • The attacker can front-run the first meaningful depositor or deliberately drive a live system back into bootstrap-like state.
  • Common vulnerable surfaces:
    • unseeded ERC-4626 vaults and wrappers
    • reward-bearing receipt tokens where sync / harvest functions can rapidly internalize attacker-supplied assets
    • live systems whose supply can be burned, reconciled, or otherwise driven back toward zero
    • initialization branches that key only on runtime supply state instead of irreversible one-time setup state
  • Exploit sequence:
    1. The attacker becomes the first or dominant shareholder with a dust deposit or by forcing live supply back toward zero.
    2. They donate assets, manipulate reward recognition, or otherwise inflate the numerator without proportional new shares.
    3. The next depositor or bootstrap path prices against that attacker-authored state.
    4. Share minting rounds down to zero or negligible ownership, or initialization math misfires under launch-like assumptions.
    5. The attacker redeems the victim-funded assets or uses the resurrected bootstrap branch to mint an absurd supply.
  • Variants:
    • Pure next-depositor victimization — the next honest depositor pays in and receives no meaningful ownership.
    • Reward-sync bootstrap inflation — donated reward inventory is made canonical via syncRewards() or an equivalent publication path just before the next deposit.
    • Near-zero-supply replay — a live system is pushed back into launch-like state, then bootstrap assumptions are exploited again; pair with bootstrap-state-replay-reversible-initialization-semantics when the lifecycle-reentry story is the main lesson.
    • Bootstrap-to-collateral bridge — the inflated opening rate is mainly monetized through downstream lending or collateral logic; at that point donation-share-price-manipulation usually does more analytical work.
  • Detection heuristics:
    • Simulate 1 wei initial deposit, attacker donation, then first real deposit.
    • Re-test after burns, claims, migrations, reconciliations, or emergency paths that can recreate dust supply.
    • Treat shares == 0 on nonzero deposit as a security finding, not only a UX problem.
    • Ask whether reward-sync or cache-write functions can make attacker-supplied assets count on attacker-chosen timing.
    • Audit bootstrap branches for irreversible initialization state instead of reversible runtime conditions like prev_supply == 0.
  • Defenses:
    • Seed meaningful dead shares or virtual asset / share offsets.
    • Revert when a nonzero deposit would mint zero shares.
    • Ignore or quarantine unsolicited assets during bootstrap when feasible.
    • Treat bootstrap as a one-time lifecycle phase enforced by explicit state, not merely by current supply.
    • If production can revisit low supply, route repair and reseeding through an explicit recovery / recapitalization mode rather than letting the next ordinary deposit silently become the new capitalization table.
    • Re-test every path that can make a live system look new again.

What sound design looks like

  • A healthy vault treats opening capitalization-table integrity as a first-class invariant. The first meaningful holder should not be able to buy a redeemable claim on all future deposits with dust.
  • Bootstrap economics should be intentionally expensive to manipulate. Virtual offsets, dead shares, trusted seeding, or minimum-liquidity locks should make dust deposit + donation insufficient to own the opening state.
  • Unsolicited assets and attacker-timed reward recognition should not instantly become share-mint truth. Good designs either ignore them for mint pricing, quarantine them until an explicit accounting step, or maintain enough seeded liquidity that they cannot zero out the next depositor.
  • Live system is near zero again should trigger special handling, not silent reuse of launch assumptions. If production can drift back into bootstrap-sensitive state, the vault should revert, reseed, or force a new initialization path before ordinary deposits resume.
  • Nonzero deposits should never quietly transfer assets for zero ownership. If a reachable state would mint zero or negligible shares, the system should reject the deposit rather than preserve a mathematically valid but economically fraudulent capitalization table.
  • If production can ever revisit dust supply, recovery should not be an accidental side effect of the next deposit, donation, or reward sync. The sharper lifecycle companions there are bootstrap-state irreversibility and supply-floor design for keeping bootstrap one-way and low-supply recovery and recapitalization discipline for making recapitalization an explicit control state rather than ambient runtime accounting.
  • Presentation and collateral trust should lag 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.
  • 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 capitalization-table promotions reviewers should not collapse

  • The vault is empty, dust-supply, or launch-like again is only the first fact. It says bootstrap economics are now attacker-shapable, not that any opening exchange rate, reward-sync result, or recapitalization answer is already fair ownership truth.
  • The protocol published one share-allocation answer for that state is stronger. convertToShares, reward-sync helpers, bootstrap mint logic, or recapitalization math may now expose one canonical-looking capitalization table — but that still only means the system has expressed a local accounting answer about who owns what.
  • Users or downstream systems may now spend against that answer is stronger again. The next depositor may transfer assets in under that ownership table, or sibling systems may honor the resulting share price as collateral, redemption, or routing truth.
  • Healthy review keeps those steps separate: dangerous low supply exists, the protocol published one capitalization answer for it, and later actors were allowed to fund or trust that answer. This family becomes much easier to miss when teams collapse them into one vague belief that the vault has a price again, because the real question is whether the next capitalization table had actually earned the right to assign ownership or move money.

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.
  • Treat reward publication timing as part of the same threat model. If a public sync, harvest, or cache-write helper can decide when attacker-supplied assets become canonical totalAssets, it is already participating in capitalization-table authorship.

Failure-prevention checklist

  • Add meaningful virtual assets / virtual shares, dead shares, or locked minimum liquidity large enough that a first actor cannot cheaply dominate the opening exchange rate.
  • Make nonzero assets in imply nonzero meaningful shares out or revert. Do not accept assets transferred, shares = 0 as a permissible bootstrap outcome.
  • Decide explicitly how direct donations, pre-sent assets, reward drips, and syncable balances affect mint pricing. If they count, explain why that cannot zero out the next depositor; if they should not count, keep separate internal accounting.
  • 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.
  • Make bootstrap one-way. Use irreversible initialization state or mandatory reseeding so redemptions, claims, burns, migrations, or bad-debt cleanup cannot silently restore new vault semantics.
  • Test first-deposit and near-zero-supply scenarios across every asset-recognition path: deposit, mint, reward sync, harvest, rescue, migration, claim, redeem, and emergency exit.
  • 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.
  • Keep collateral admission and downstream integrations away from fresh or thinned-supply vault states until share pricing is economically trustworthy.
  • Monitor supply floors and ownership concentration. If one address can cheaply end up with nearly all surviving shares, the vault is back in bootstrap-danger territory.
  • Document a clear operator response for anomalous share-price jumps during low-supply periods: pause deposits, quarantine donations, or require reseeding before normal operation resumes.

Audit prompts

  • Can a 1 wei first deposit followed by a donation or reward-sync event cause the next honest deposit to mint zero or trivial shares?
  • Which exact code paths increase the numerator used for mint pricing without minting proportional shares: direct transfers, reward sync, harvest, strategy balance reads, rebasing underlying, or rescued funds?
  • Does the vault key bootstrap logic off irreversible setup state, or only off reversible runtime conditions like totalSupply == 0 or prev_supply == 0?
  • After burns, claims, migrations, or emergency paths, can the live system be pushed back into a dust-supply state where bootstrap assumptions become exploitable again?
  • If a nonzero deposit would receive negligible ownership, does the code revert, warn, or silently accept the transfer?
  • Are previewDeposit, previewMint, convertToShares, and actual mint paths guaranteed to treat unsolicited assets consistently, or can an attacker time state changes between them?
  • Can a public sync, harvest, or cache-write function crystallize attacker-supplied assets into canonical totalAssets right before another user deposits?
  • What minimum seeding or virtual-liquidity amount is actually required to make the attack uneconomic for the asset’s decimals and expected deposit sizes?
  • Do any sibling lending, liquidation, or routing systems assume a fresh or near-empty vault share price is trustworthy before the bootstrap state is economically hardened?
  • If low supply or zero supply can be revisited after launch, what explicit recovery or recapitalization path is supposed to re-establish a safe capitalization table, and why can ordinary deposits not accidentally trigger it?
  • In the worst reachable low-supply state, how much value can the next depositor lose before automation or operators detect the vault is effectively attacker-owned?

Lessons that should already be standard

  • Mathematically correct is not the same thing as fair. A vault that accepts assets and mints zero shares is not merely unfriendly; it has failed at ownership accounting.
  • Bootstrap is a real security phase, not a ceremonial deployment detail. If nobody deliberately secures the opening capitalization table, the attacker will.
  • Near-zero supply is a production hazard, not just a launch hazard. Burns, claims, migrations, and emergency operations can bring bootstrap economics back long after deployment.
  • Donation neutrality must be intentional. If unsolicited assets can move mint pricing, the protocol is already letting outsiders help author the capitalization table.
  • Reward-sync and cache-write functions belong inside the security model. Whoever can decide when off-path assets become canonical can often decide who gets diluted.
  • First-deposit attacks are often the small, clean version of a bigger accounting problem. If the same printed rate later feeds collateral or redemption logic, the bug has graduated into a broader solvency failure.
  • Virtual offsets and dead shares are not cosmetic. They are explicit economic defenses that buy fairness for later depositors.
  • 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.

Where this pattern stops

  • Use this note when the decisive theft is the opening share allocation itself or the resurrection of bootstrap-only assumptions.
  • Use 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.
  • Use bootstrap-state-replay-reversible-initialization-semantics when the deeper preserved lesson is that reversible runtime state let production re-enter initialization semantics.

High-signal incidents

  • GoGoPool ggAVAX first-depositor share-price inflation near miss (2023-01-03) — the clean 1 wei opener + donation + reward-sync timing near miss where a later depositor could be overcharged while smaller deposits reverted with ZeroShares().
  • 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.
  • infinite-mint exploit (2025-11-30) — the strong live reminder that bootstrap assumptions can return after launch when adversaries drive supply back to zero and re-enter initialization-only math.
  • zero-exchange-rate exploit (2025-06-26) — useful contrast where the same near-empty-vault economics crossed into lending collateral math rather than stealing from the next depositor directly.
  • 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.

Internal linkages

Control surface

Graph View

Backlinks