Cowrie Research

low-supply-recovery-and-recapitalization-discipline

18 min read

Low-Supply Recovery and Recapitalization Discipline

  • Name: low-supply recovery and recapitalization discipline
  • Category: vault reference / low-supply recovery checklist / recapitalization-control note / bootstrap companion
  • Summary: Some vaults, wrappers, and share systems cannot guarantee that production will never revisit dust supply, depleted reserves, or post-incident recapitalization. The safe answer is not to let ordinary deposits, donations, reward syncs, or residual-share math silently impersonate a restart. It is to make recovery an explicit control state with its own asset-intake rules, share-allocation rules, presentation quarantine, and downstream-admission delay. The note’s sharper review habit is to keep three promotions separate: repair capital arrived, the vault published a repaired local accounting object, and downstream systems may trust that repaired object as money-good authority. If bootstrap-state irreversibility says live systems must not accidentally become new again, this note says the companion truth: systems that really do need to recover from near-zero state must do so through a separate recapitalization object, not through ambient runtime accounting.
  • Why this note exists:
    • bootstrap-state-irreversibility-and-supply-floor-design already preserves the negative lesson that live low-supply states must not silently reactivate launch-only assumptions.
    • What still deserves a narrower positive-design note is the harder operational case: a live system may be damaged, partially drained, loss-socialized, or intentionally recapitalized, and never revisit low supply may not be realistic.
    • The analytical win is to stop treating recovery as just another deposit or another exchange-rate update. Recovery is a governance and accounting boundary change, so it needs its own explicit security object.

The core design rule

If a live share system must recover from dust supply, depleted reserves, or post-incident recapitalization, that recovery should happen through an explicit re-entry / recapitalization mode rather than through ordinary user deposit semantics.

A healthy system should not let these become equivalent:

  • operator or rescuer recapitalized the system
  • next depositor discovered a free first-deposit opportunity
  • surviving dust shareholders now own the repaired capitalization table
  • freshly repaired rate is immediately safe as presentation or collateral truth

Three recovery promotions reviewers should not collapse

  1. Repair capital arrived

    • Assets, treasury support, POL, migrated collateral, or rescue funds are now physically or economically present.
    • This answers only did value show up for recovery purposes?, not yet who owns the repaired system?

  2. The protocol published a repaired local accounting object

    • The vault, wrapper, or reserve has decided how that capital affects pricePerShare, convertToAssets, rebasing balances, cached NAV, loss realization, or migration receipts.
    • This is already a stronger claim than assets arrived, because it says the protocol chose one capitalization story instead of leaving recovery capital quarantined.

  3. Downstream systems may spend against that repaired object

    • Lending markets, liquidation engines, wrappers, accounting exports, and integrators now treat the repaired local mark as ordinary collateral, redemption, routing, or borrow truth.
    • This is the most dangerous promotion, and it should usually happen later than both assets arrived and local accounting was republished.

The five separations healthy recovery design should preserve

  1. Recovery authority versus ordinary deposit authority

    • A repair, recapitalization, POL top-up, treasury backstop, or governance-mediated restart is not economically the same thing as a normal user deposit.
    • If the system needs a special path to re-establish backing, that path should be explicit about who may call it, what assets count, and what state transition it authorizes.
    • The key question is not can more assets come in? but who is allowed to define the next capitalization table after damage?

  2. Recapitalization asset intake versus exchange-rate publication

    • New backing may need to arrive before the system is willing to publish a new trustworthy rate.
    • A healthy design can accept assets, record that recovery capital arrived, and still quarantine pricePerShare, convertToAssets, balanceOf, cached NAV, or collateral-facing exchange rates until the system leaves recovery mode.
    • This is the first promotion boundary: repair capital arrived still does not mean the protocol has republished one repaired local accounting object.
    • Otherwise the recovery path itself becomes a rate-printing primitive for surviving dust holders or opportunistic integrators.

  3. Repair accounting versus incumbent-holder windfalls

    • If reserves were depleted, prior shares may no longer deserve pro-rata claims on newly injected capital without explicit policy.
    • Recovery design should say plainly whether losses are crystallized, old shares are haircut or migrated, a new share class is issued, or recapitalization enters as subordinated or quarantined backing.
    • The unsafe default is letting whatever tiny residual share state survived the incident automatically own the repaired system.

  4. Recovery mode versus ordinary exits and new entrants

    • Systems in recapitalization should not necessarily allow ordinary mint, redeem, borrow, collateral-enable, or liquidation behavior immediately.
    • Healthy designs often need temporary caps, withdrawal gating, isolated markets, one-way flows, or migration-only exits while the system re-establishes coherent state.
    • The relevant question is whether users are interacting with a live production vault or with a controlled recovery process that still owes them stronger invariants before full reopening.

  5. Vault-local repair versus downstream solvency admission

    • Even if the vault itself is ready to resume accounting, other protocols should not instantly trust the repaired rate as collateral, liquidation, or borrow-side truth.
    • This is the second promotion boundary: the vault has republished one repaired accounting object still does not mean downstream systems may already spend against that object as ordinary money-good authority.
    • Recapitalization should usually lag downstream admission, especially if the recovery changed share supply, crystallized losses, or relied on operator discretion.
    • A repaired wrapper is still a freshly rewritten solvency object.

What sound design looks like

1. An explicit recovery / recapitalization mode

  • Recovery should be a named control state, not an accidental consequence of totalSupply == 0, direct donation, or emergency treasury refill.
  • The mode should declare which functions remain open, which are paused, and what conditions end recovery.
  • If a protocol cannot support such a mode safely, a governed migration or new vault deployment is usually healthier than pretending the old system is automatically normal again.

2. A separate recapitalization object

  • The safest repair paths make recapitalization legible as its own object: a governed top-up event, migration accounting entry, explicit seed tranche, or new share class / offset change.
  • That object should define who receives economic credit for repair capital and who does not.
  • The reusable design target is that new capital repaired losses must not collapse into old dust shares now own the rescue unless that policy is explicit and intentional.

3. Quarantined valuation until recovery completes

  • During recovery mode, user-visible balances and downstream-consumed rates should often lag the raw asset top-up.
  • Smoothed valuation, manual checkpointing, temporary fixed conversion, capped issuance, or migration receipts are all safer than letting repair capital immediately rewrite every rate consumer.
  • The point is not that manual intervention is always good; it is that repair-time valuation is governance-sensitive enough to deserve its own distrust boundary.

4. Controlled re-entry for new users

  • New entrants should know whether they are buying into a clean post-recovery capitalization table or into unresolved legacy claims.
  • Healthy systems may require seeded minimum liquidity, migration-only entry, delayed minting, or temporary segregation between legacy holders and fresh capital.
  • If the next open-market depositor can accidentally become the recapitalizer, the system has not really separated recovery from ordinary flow.

5. Delayed downstream re-enablement

Operational guardrails worth automating

1. Make recovery mode machine-visible to every integrator path

  • Recovery status should be legible onchain and in emitted events, not buried in governance forum context or UI banners.
  • The important signal is not only paused versus unpaused. Integrators need to know whether the object is in recovery intake, valuation quarantine, migration-only exit, or downstream-cooldown mode.
  • If keepers, adapters, or UIs cannot distinguish those states mechanically, they will default to treating a partially repaired object as ordinary collateral truth.

2. Alert on assets arrived while capitalization policy is unresolved

  • Treasury top-ups, protocol-owned liquidity injections, insurance payouts, bridge recoveries, and direct donations should all raise a typed alert if they hit a damaged or low-supply system before the protocol has published who owns that repaired value.
  • The high-signal production invariant is capital can arrive before exchange-rate publication, but it must not arrive without immediately entering a named recovery bucket or mode.
  • This is the recovery analogue of supply-floor monitoring: the dangerous state is not merely low supply, but low supply plus fresh value plus no explicit ownership policy.

3. Pre-commit the reopen ladder

  • Recovery should not jump from damaged to fully normal in one governance click.
  • A healthier ladder is: accept repair capital → reconcile liabilities and ownership → publish local accounting for controlled exits → allow migration / bounded minting → restore downstream collateral use → reopen ordinary flow.
  • The key property is that each rung has a distinct invariant and explicit sign-off condition.

4. Monitor for legacy-holder windfall shapes

  • Recovery dashboards should track residual supply concentration, legacy-share ownership, fresh-capital attribution, and whether any tiny incumbent holder set would capture a disproportionate share of the recapitalization.
  • The production smell is repair succeeded numerically while the capitalization table quietly says dust holders own the rescue.
  • That is exactly the state a protocol should detect before reopening mints, redemptions, or collateral admission.

Minimal recapitalization state machine worth encoding

StateWhat is trueWhat must still be falseTypical controls
degraded-liveThe system is still deployed, but the old share object no longer deserves ordinary trust because backing, supply structure, or post-incident obligations are impairedNew ordinary deposits, fresh donations, or residual-share math must not silently define the repaired capitalization tablepause or narrow mint paths, collateral factor 0, borrow disablement, recovery flag on, liquidation restrictions
recovery-intakeRepair capital may arrive through named recapitalization paths and be typed as treasury support, migration inventory, insurer funds, or other governed intakeRaw asset arrival must not yet imply legacy holders own it, pricePerShare is repaired, or downstream systems may spend against itnamed intake functions, pending / suspense buckets, asset-class validation, source tagging, event emission
ownership-resolutionThe protocol has decided how repaired value maps across legacy holders, new recapitalizers, haircuts, migrated claims, or subordinated buffersFresh capital still must not flow automatically into ordinary convertToAssets, rebasing balances, or collateral marks before the ownership answer is explicithaircut accounting, migration receipts, share freezes, new share class or offset update, governance checkpoint
local-republishedThe vault or wrapper can expose a repaired local accounting object for controlled exits, migrations, or bounded new entrySibling lending markets, liquidators, and routing systems still must not treat that local object as ordinary money-good solvency truthquarantined convertToAssets, capped minting, migration-only exits, local accounting visible, downstream adapters still disabled
downstream-cooldownThe repaired share object has one coherent local accounting story and is being observed under bounded conditionsFull recursive borrowing, unrestricted collateral admission, and ordinary liquidation authority still must not be back yetcooldown timers, isolated mode, low debt ceilings, borrow-pair allowlists, manual re-enable review
ordinary-flow-restoredRecovery accounting, capitalization policy, and downstream trust have all been re-earned explicitlyHistorical damage should not be forgotten; implicit re-entry into recoveryless steady state must not be the only safety storyexplicit exit from recovery mode, restored caps, monitoring still armed, downgrade triggers retained
  • The important design property is not the labels themselves. It is that repair capital arrived, one repaired local accounting object exists, and other systems may now spend against it are forced through distinct state transitions instead of one ambient assets went up side effect.
  • Healthy protocols usually allow movement into degraded-live or recovery-intake automatically when damage or dust-state conditions appear, while movement forward toward local-republished, downstream-cooldown, and ordinary-flow-restored should be progressively harder and more explicit.
  • The sharp exploit-family shortcut is blunt: if a system can jump from dust supply plus rescue capital straight to ordinary deposits, ordinary redemption previews, and ordinary collateral truth, then recovery is still pretending to be a normal deposit path.

Recovery-mode sequence that should be explicit before the incident

  1. Enter degraded mode and freeze the old trust assumptions

    • Stop ordinary mint / borrow / collateral-enable paths or narrow them immediately once the system is damaged enough that the old share object is no longer routine money-good truth.
    • The point is to halt automatic promotions, not merely to buy time socially.

  2. Accept repair capital through a named path

    • Distinguish rescue assets, migration inventory, insurer funds, treasury support, and opportunistic public deposits before they touch exchange-rate publication.
    • If the capital source does not fit a declared class, it should not silently become recapitalization.

  3. Publish the ownership and haircut policy

    • Decide how legacy holders, bad debt, fresh recapitalizers, and migrated claimants map into the repaired capitalization table.
    • This is where the protocol proves that assets came back is not being confused with the surviving dust ledger deserves them.

  4. Republish local accounting under quarantine

    • Only after reconciliation should the system expose repaired convertToAssets, PPS, NAV, rebasing credits, or similar local views, and even then with downstream restrictions still live.
    • Local legibility is a milestone, not the end of recovery.

  5. Restore external trust in layers

    • Reopen exits and migrations first if needed, then bounded new entry, then downstream collateral / liquidation use, then ordinary unrestricted flow after the repaired share object has survived explicit review and cooldown.
    • If the system cannot articulate this ladder before an incident, it is still relying on operator improvisation.

High-signal contrast cases

  • Yearn yETH is the sharp reminder that a live system can revisit effective bootstrap state without any explicit recovery envelope; once that happens, repair and ordinary issuance semantics collapse together.
  • GoGoPool ggAVAX preserves the simpler who gets to define the post-empty capitalization table? question at launch, which becomes the same question again whenever production systems revisit dust supply.
  • Zunami and Raft Finance show why repaired or donated backing should not instantly become presentation truth.
  • ResupplyFi shows the downstream version: by the time an almost-empty wrapper rate reaches lending math, the protocol is no longer merely choosing recovery accounting; it is choosing who gets borrow power.

Design questions worth asking first

  • Can the system ever revisit dust supply, depleted backing, or near-empty reserve conditions in normal or adversarial runtime?
  • If yes, what exact mechanism is supposed to repair it: ordinary deposits, treasury top-ups, migration, new deployment, or explicit recapitalization?
  • Who is allowed to authorize recovery capital, and who receives the economic benefit of that capital?
  • Can fresh backing enter without instantly updating public exchange-rate, balanceOf, cached NAV, or collateral value?
  • Are old shares haircut, frozen, migrated, subordinated, or left fully pro-rata after repair, and is that policy explicit?
  • What functions remain disabled or quarantined until recovery finishes?
  • When does downstream collateral or liquidation admission restart, and who decides that?

Red flags that usually mean recovery is pretending to be an ordinary deposit

  • If the vault gets topped up, the math just works again
  • Any direct donation helps restore solvency without saying who now owns the restored value
  • We only need to stop re-entering bootstrap without defining how legitimate recapitalization should ever happen
  • The exchange rate is fine once assets are back even though caches, rebases, or lending adapters consume it immediately
  • Users can keep minting during recovery without a clear answer about whether they are recapitalizers, ordinary depositors, or victims of unresolved legacy claims
  • We can always just reseed it with no explicit policy for residual-share holders or downstream integrators

Failure-prevention checklist

  • Add an explicit recovery / recapitalization mode with clear entry and exit conditions. Low supply happened is not itself a recovery plan.
  • Separate recapitalization authority from ordinary deposit authority. Treasury top-ups, governed rescues, POL injections, migration receipts, and market re-openings should travel through named functions or objects with explicit caller and asset constraints.
  • Define who owns repaired value before capital arrives. Residual legacy holders, new recapitalizers, treasury backstops, and migrated claimants should not discover the capitalization policy only after funds are already in the contract.
  • Quarantine valuation during recovery. Fresh capital should not immediately rewrite pricePerShare, convertToAssets, cached NAV, rebasing balances, collateral marks, or liquidation-facing exchange rates until the protocol deliberately graduates out of recovery mode. Keep repair capital arrived separate from one repaired local accounting object was published.
  • Keep ordinary mint / redeem / borrow / collateral-enable flows narrowed or paused while recovery is in progress. Recovery mode should usually be one-way or migration-shaped until the new capitalization table is coherent.
  • Delay downstream collateral re-enablement longer than vault-local repair. Lending markets, liquidation engines, and wrapper adapters should require a separate review or cooldown before trusting repaired rates. Locally republished is still not money-good everywhere.
  • Record recapitalization as its own accounting object. Recovery capital, socialized losses, residual bad debt, and fresh user deposits should not collapse into one undifferentiated assets went up event.
  • Test post-incident states directly: depleted reserves, dust supply, partial treasury refill, residual-share overhang, migrated liabilities, and operator-assisted reseeding should all preserve the declared ownership and publication policy.
  • Publish machine-readable recovery status where possible so integrators can fail closed instead of guessing whether the system is normal again.
  • Define what happens if recovery fails midway. A protocol should know whether it pauses, migrates, haircuts old claims, or refunds fresh entrants rather than improvising inside live market conditions.

Audit prompts

  • What exact state variable or object proves the system is in recovery mode, and which functions are still live while that state holds?
  • Who is allowed to provide recapitalization capital, and what economic claim do they receive in return?
  • If old shares survived a drain, why do those holders deserve pro-rata ownership of newly injected value, and where is that policy encoded?
  • Can ordinary users accidentally become recapitalizers through normal deposit or donation paths without realizing they are funding a recovery event?
  • Which rate consumers are still active during recovery: balanceOf, rebasing credits, redemption previews, collateral adapters, liquidation math, accounting exports, or UI-facing NAV?
  • What exact event promotes repair capital arrived into the protocol published one repaired local accounting object, and what exact later event promotes that local object into downstream borrow, liquidation, or routing authority?
  • What prevents a repaired or partially repaired rate from becoming immediate borrow power in sibling lending markets?
  • Does the protocol distinguish assets arrived from local accounting was republished and from recovery completed, or does one event automatically imply all three everywhere?
  • If the protocol uses protocol-owned liquidity or treasury funds to absorb losses, how is the resulting ownership change represented instead of silently enriching residual shareholders?
  • What migration or pause path exists if recapitalization starts but the system cannot safely return to ordinary flow?
  • How would an integrator, liquidator, or keeper know from onchain state that the system is still in recovery and should be treated as degraded or non-admissible?

Lessons that should already be standard

  • A damaged live system is not the same thing as a new system. Recovery should be explicit, not inferred from balances improving.
  • Assets are back does not answer who owns them now. Recapitalization policy is part of the security boundary.
  • Assets arrived does not yet mean the vault published a repaired accounting truth, and even that still does not mean other systems may already spend against it.
  • The next ordinary depositor should almost never be allowed to define the post-incident capitalization table by accident.
  • Recovery-time valuation is governance-sensitive valuation. It deserves stricter publication and downstream-admission controls than ordinary steady-state accounting.
  • Legacy shares, treasury backstops, and fresh entrants are different economic roles. Treating them as one generic holder set is how recovery turns into a new exploit surface.
  • Integrators need explicit degraded-mode signaling. Silence forces them to consume repaired wrappers as if nothing changed.
  • If a protocol can only be made safe again by humans manually doing the right thing, it should encode that recovery procedure as a real mode or migration object rather than leaving it as unwritten operator folklore.

How to use this note with the exploit corpus

Internal linkages

Control surface

Graph View

Backlinks