Cowrie Research

bootstrap-state-irreversibility-and-supply-floor-design

14 min read

Bootstrap-State Irreversibility and Supply-Floor Design

  • Name: bootstrap-state irreversibility and supply-floor design
  • Category: vault reference / low-supply lifecycle checklist / bootstrap-replay defense note / share-accounting companion
  • Summary: Healthy share systems should not infer this is a pristine first-deposit state from live economic variables like totalSupply == 0, prev_supply == 0, or one dust share remains. Bootstrap is a one-time authorization state, not a runtime market condition. The defensive goal is to keep four facts separate: bootstrap permission was already consumed, runtime supply later became thin again, the protocol chose to publish one low-supply accounting object, and some later path chose to spend against that object as if it were ordinary issuance, redemption, or collateral truth. If a live system can burn, reconcile, or round its way back into launch semantics, then first-deposit inflation and bootstrap-only mint logic are not deployment-day problems; they are latent runtime exploits.
  • Why this note exists:
    • The exploit corpus already preserves the negative side clearly: first-deposit-inflation for pure next-depositor theft, donation-share-price-manipulation for printed exchange-rate fiction, and Yearn yETH for the stronger bootstrap path became reachable again in production cousin.
    • What is still worth preserving explicitly is the positive design target for systems that may revisit dust-supply conditions without ever becoming safely new again.
    • The main analytical win is to stop asking only how do we seed the vault at launch? and instead ask what exact state transition is never allowed to become true again, even if supply later decays toward zero?

The core design rule

Bootstrap must be irreversible as a control state, even if low-supply conditions remain reachable as an economic state.

A healthy system can tolerate small supply only if it does not also reinterpret small supply as permission to:

  • reuse first-deposit pricing logic
  • reset share issuance assumptions
  • bypass nonzero floors or virtual offsets
  • let donated assets define the next capitalization table
  • make presentation math or collateral adapters trust a newly fragile exchange rate immediately

Four low-supply facts reviewers should keep separate

  1. Bootstrap permission was already consumed

    • Deployment already crossed the one-way control boundary that allowed first-deposit semantics, seed-only mint assumptions, or other launch-only logic.
    • This fact should remain true forever, even if supply later revisits zero, dust, or one-holder conditions.

  2. Bootstrap-sensitive runtime conditions appeared again

    • Supply became tiny, prev_supply or an equivalent accounting checkpoint hit a dangerous boundary, or one actor now dominates the surviving capitalization table.
    • This answers only the live system is back in a thin and dangerous economic state, not bootstrap permissions should reopen.

  3. The protocol published one low-supply accounting object

    • The vault chose how that fragile state affects pricePerShare, convertToAssets, rebasing balances, cached NAV, reward checkpoints, or other local accounting surfaces.
    • This is already a stronger claim than runtime got thin again, because it says the protocol endorsed one capitalization story instead of merely observing a dangerous state.

  4. Users or downstream systems may spend against that object

    • Depositors, redeemers, lending markets, liquidators, wrappers, and integrators now treat that low-supply local mark as ordinary issuance, redemption, collateral, or liquidation truth.
    • This is the most dangerous promotion, and it should usually happen later than both runtime got thin again and the protocol published one low-supply accounting object.

The five separations healthy low-supply systems should preserve

  1. Initialization permission versus runtime supply state

    • initialized == true should be a one-way control fact, not an inference from totalSupply, prev_supply, pool balances, or another reversible economic variable.
    • Launch-only branches should key off an irreversible flag or consumed initialization object.
    • If a live system can later reach supply == 0, that should mean system is in a dangerous low-supply runtime state, not system is young again.

  2. Supply floor versus redeemable ownership

    • Dead shares, virtual offsets, or non-redeemable seed liquidity are not cosmetic bootstrap tricks; they are a permanent barrier against one user cheaply owning the whole capitalization table.
    • The right question is not only is there a floor at genesis? but can that floor ever be redeemed away, socialized away, or bypassed by migrations, wrapper upgrades, or reconciliation paths?
    • If the answer is yes, the floor was not really a floor.

  3. Raw balance recovery versus accounted asset truth

    • When a pool is nearly empty, every donation, reward sync, loss socialization, or reconciliation step becomes more rate-sensitive.
    • Healthy systems should not let we found or received more assets automatically mean the surviving dust shareholder just became rich.
    • This is where direct donations, reward-sync timing, and protocol-owned-liquidity reconciliation become part of the same low-supply threat model.

  4. Low-supply accounting versus presentation math

    • balanceOf, rebases, cached NAV, internal index math, and other presentation layers should not immediately consume a fragile or newly recovered low-supply rate.
    • If the system is near dust supply, presentation should usually lag, clamp, quarantine, or distrust that rate instead of making it same-block spendable truth.
    • Otherwise the protocol can move from bootstrap replay risk to printed balance became payout rail without any new bug.

  5. Vault-local recovery versus downstream solvency admission

    • Even if a low-supply pool is still locally coherent enough to continue operating, that does not mean sibling lending markets, liquidators, or wrappers should immediately trust its rate.
    • This is the same second promotion boundary carried more explicitly in low-supply-recovery-and-recapitalization-discipline: the protocol published one low-supply local accounting object still does not mean other systems may already spend against it as ordinary money-good authority.
    • A healthy design treats recovered from low supply as a potentially degraded mode that may still need caps, delays, isolation, or collateral disablement.

What sound design looks like

1. One-way bootstrap state

  • Use an irreversible initialization flag or consumed initialization object.
  • Never reactivate launch pricing or launch mint semantics because a reversible economic variable returned to zero.
  • If a system genuinely needs a restart path, make it an explicit governed migration, redeploy, or recapitalization flow, not an accidental consequence of arithmetic state.

2. A floor that survives adversity

  • Use dead shares, virtual asset/share offsets, or other non-redeemable seed structure that cannot be withdrawn by the first real user.
  • Re-test that floor against claims, burns, POL reconciliation, emergency exits, migration helpers, and admin repair flows.
  • The control question is what state can never again be owned by one dust shareholder?

3. Degraded-mode handling for dust supply

  • Treat near-zero supply as a dangerous runtime mode.
  • Possible responses include pausing reward sync, slowing NAV updates, disabling collateral admission, blocking certain redemptions, or requiring explicit operator recovery steps.
  • The key point is not which exact fallback is best; it is that dust supply should have its own operating policy instead of silently inheriting full-production assumptions.

4. Donation-neutral or donation-expensive low-supply accounting

  • If unsolicited assets can still arrive, their low-supply impact should be bounded.
  • Internal accounting, virtual liquidity, delayed recognition, or explicit discard of attacker-supplied reward inventory can all help.
  • The reusable design target is that a dust holder should not be able to convert I sent assets in into I now own the next depositor's capitalization table.

5. Presentation and solvency quarantine after low-supply events

  • A system recovering from dust supply should not instantly let that rate flow into balanceOf, rebase credits, cached NAV, lending collateral, or liquidation math.
  • Rate smoothing, quarantine windows, isolated markets, caps, or operator-reviewed re-enablement are all better than assuming low-supply recovery is economically trustworthy by default.

High-signal contrast cases

  • GoGoPool ggAVAX is the clean launch-state reminder: a vault can be technically working while still letting one dust depositor plus one donation define the next user’s capitalization table.
  • Yearn yETH is the sharper lifecycle reminder: a live system can become launch-dangerous again if prev_supply == 0 silently reopens bootstrap-only logic.
  • Zunami and Raft Finance show why low-supply safety is not only about who gets shares, but also about which presentation or cached-accounting layers start trusting attacker-printable rates.
  • ResupplyFi shows the same economic sensitivity after the problem has already crossed into downstream lending math.

Design questions worth asking first

  • What exact irreversible fact marks the end of bootstrap?
  • Can any reachable runtime path make totalSupply == 0, prev_supply == 0, or an equivalent dust state true again?
  • If yes, what logic changes when that happens, and should any of that logic really be keyed off supply state at all?
  • Is there a permanent, non-redeemable supply floor or virtual offset, and can any migration or admin path bypass it?
  • Which functions can turn a low-supply rate into user-visible balanceOf, cached NAV, rebase credits, redemption rights, or collateral value?
  • What degraded-mode policy exists for low-supply runtime states?
  • What exact event promotes runtime got thin again into the protocol published one low-supply accounting object, and what exact later event lets users or downstream systems spend against that object?
  • If the system receives unsolicited assets while near zero supply, who economically benefits from them, and why is that safe?

Red flags that usually mean bootstrap can come back

  • We only use this branch on first deposit with no irreversible flag
  • totalSupply == 0 or prev_supply == 0 used as a proxy for pristine state
  • Dead shares that can later be redeemed, diluted away, or bypassed by another issuance verb
  • Reward-sync, reconciliation, or cache-update code that becomes more powerful exactly when supply is smallest
  • Zero-share deposits revert, so the bootstrap attack is fixed even though larger later users can still be overcharged
  • Presentation math that treats a fresh low-supply rate as immediately spendable or borrowable truth

Failure-prevention checklist

  • Use a one-way initialization fact that can never be inferred back from supply, reserves, or another reversible runtime variable. initialized, consumed seed objects, or one-time deployment checkpoints should be authoritative; prev_supply == 0 should not be.
  • Keep a permanent, non-redeemable floor under share ownership concentration. Dead shares, virtual assets / virtual shares, seeded minimum liquidity, or equivalent supply-floor machinery should survive burns, migrations, rescues, and emergency paths.
  • Treat low-supply runtime as its own operating mode. If supply falls below a threshold, require slower rate publication, disabled collateral admission, or explicit operator review rather than silently continuing with ordinary bootstrap-sensitive math.
  • Separate low-supply recovery from ordinary deposits. If a pool needs reseeding or recapitalization, route that through an explicit recovery object instead of letting the next depositor, donation, or reward sync define the new capitalization table.
  • Bound how unsolicited assets behave near zero supply. Direct donations, reward drips, reconciliation flows, debt-repayment residue, and protocol-owned-liquidity adjustments should not cheaply rewrite the next exchange rate.
  • Keep presentation and solvency consumers behind a stronger distrust boundary than vault-local arithmetic. balanceOf, cached NAV, rebasing balances, collateral adapters, and liquidation math should not immediately trust a newly fragile low-supply rate. Bootstrap permission was consumed long ago must stay separate from runtime got thin again; that thin state is still not the protocol published a safe low-supply accounting object, and even that is still not other systems may already spend against it.
  • Re-test low-supply invariants across every share-changing entrypoint, not just the obvious deposit path: mint, migration helpers, admin rescue surfaces, reward sync, withdraw / redeem edge cases, and any inherited standard verb.
  • Add telemetry and explicit alerts for supply-floor erosion, residual-share concentration, abrupt exchange-rate jumps at low supply, and any transition back toward bootstrap-like arithmetic conditions.

Audit prompts

  • What exact irreversible fact proves bootstrap has already happened, and where could runtime code accidentally reconstruct bootstrap not yet done from live economic state?
  • Can any reachable path make totalSupply == 0, prev_supply == 0, or an equivalent dust-supply state true again after launch? If yes, what behavior changes when that happens?
  • Are dead shares, virtual offsets, or minimum-liquidity floors truly non-redeemable and non-bypassable across migrations, rescues, bad-debt socialization, and admin maintenance paths?
  • Which functions become more powerful as supply gets smaller: reward sync, cache writes, reserve reconciliation, donation handling, rate updates, or liquidation pricing?
  • If the pool receives unsolicited assets while near zero supply, who economically benefits from them, and what code decides whether those assets are ignored, quarantined, or socialized?
  • Which user-visible or downstream-consumed surfaces would trust a low-supply repricing today: balanceOf, convertToAssets, cached NAV, rebase credits, collateral value, liquidation seize math, or borrow caps?
  • What exact fact proves bootstrap permission was consumed permanently, and where could runtime code accidentally reinterpret a thin-state variable as permission to reuse launch-only semantics?
  • What exact event promotes runtime became thin again into the protocol published one low-supply accounting object, and what exact later event promotes that local object into ordinary mint, redeem, borrow, liquidation, or routing authority?
  • Is there an explicit degraded-mode policy for low supply, or does the protocol simply keep running the same math and hope the launch assumptions remain safe?
  • After a severe drain or recapitalization, how does the protocol distinguish damaged live system from pristine first deposit state before ordinary issuance resumes?
  • What adversarial tests prove that a dust holder cannot turn a low-supply or zero-supply state into control of the next meaningful capitalization table?
  • If bootstrap-sensitive logic still exists for legitimate reasons, what exact governance or operator action is required to reach it, and can users or keepers reach it accidentally through ordinary flow?

Lessons that should already be standard

  • Bootstrap is a control state, not a market condition. Reversible arithmetic facts like supply == 0 should never be allowed to impersonate one-time initialization authority.
  • A supply floor that can later be redeemed away or bypassed was never a real floor.
  • Low supply is not just a pricing inconvenience. It is a degraded security state that changes who can cheaply author the next exchange rate.
  • Bootstrap happened once is a stronger fact than supply is currently nonzero or supply just fell back toward zero. The control boundary should stay consumed even when runtime conditions deteriorate.
  • Low supply happened again is not bootstrap may run again, and even the protocol republished one low-supply rate is still not other systems may spend against it as ordinary money-good authority.
  • First-deposit bug is often a misleading label. The real family is who gets to define the capitalization table once supply is tiny enough to be manipulable.
  • Presentation math and collateral math become part of the bootstrap threat model once low-supply repricing can spill into balances, redemptions, borrows, or liquidations.
  • Recovery is a separate design problem from initialization. Systems that may revisit dust supply need explicit recovery rails, not accidental re-entry into launch-era assumptions.
  • If low-supply safety depends on humans remembering that a branch is supposed to be unreachable now, the protocol has not actually made bootstrap irreversible.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks