Cowrie Research

donation-share-price-manipulation

14 min read

Donation / Share-Price Manipulation

  • Name: donation / share-price manipulation
  • Category: exploit pattern / share-accounting distortion / exchange-rate inflation / collateral- and redemption-monetization bug class
  • Summary: This pattern appears when a protocol treats assets per share, pricePerShare, exchangeRateStored, rebasing index state, or similar receipt-token math as if every increase came from earned value or approved issuance paths. The attacker then forces more assets, accounting weight, or numerator-side value into that ratio without minting proportional shares — by direct donation, stealth donation from rounding, upstream staking-credit inflation, or cacheable valuation tricks — and cashes out the resulting overstatement through collateral borrowing, self-liquidation, redemption, or token-balance presentation itself. The core failure is accounting, not just price manipulation: the protocol lets attacker-authored balance growth become canonical issuance truth, then often lets that freshly published share truth become immediate redeemable or borrowable authority elsewhere.
  • What it is:
    • A share-like claim token derives value from some numerator such as totalAssets, cash, staking principal, rebasing index, or cached NAV divided by shares outstanding.
    • The protocol assumes numerator growth only reflects legitimate deposits, earned yield, or trusted accounting updates.
    • The attacker finds a path that increases the numerator without issuing matching shares, or otherwise concentrates ownership so a tiny surviving share base controls most of the claim on that numerator.
    • The inflated share price is then honored by some economic surface: lending collateral, liquidation seize math, redemption, rebasing balanceOf, or the next depositor’s mint rate.
    • The real loss appears when the system pays out against that printed exchange rate rather than challenging where it came from.
  • Typical preconditions:
    • The protocol computes a solvency-critical ratio from balances or indices that can move outside the normal mint path.
    • Direct donations, rounding leftovers, reward sync, debt-repayment edge cases, or upstream staking receipts can increase effective assets without proportional share minting.
    • Share ownership can be concentrated, especially in empty, thinned, or dust-supply states.
    • Another path monetizes the inflated rate quickly enough: borrow power, self-liquidation, redemptions, cached balance presentation, or overcharging the next depositor.
    • The system does not neutralize off-path balance growth with dead shares, virtual offsets, internal accounting, rate caps, or provenance checks.
  • Common vulnerable surfaces:
    • ERC-4626 vaults or wrapper tokens whose totalAssets can be skewed by donation or rounding
    • lending markets that accept vault shares, wrapper receipts, or rebasing collateral as money-good collateral
    • rebasing or index-based tokens where balanceOf or collateral value depends on a global numerator attackers can print upward
    • staking wrappers whose backing can be inflated one layer deeper than the wrapper mint path itself
    • cached-NAV or harvest/sync systems that crystallize attacker-timed value into canonical share price or balance state
    • empty-market or near-empty-market states where a tiny attacker position dominates supply
  • Exploit sequence:
    1. The attacker becomes an early, dominant, or strategically concentrated share holder in the target wrapper or vault.
    2. They increase numerator-side value without receiving matching new shares: direct donation, stealth donation loops, upstream recipient inflation, or manipulated cache/write timing.
    3. The protocol recomputes assets/share, pricePerShare, rebasing index, or equivalent from that polluted state.
    4. A downstream consumer treats the printed ratio as real solvency truth.
    5. The attacker borrows, self-liquidates, redeems, or otherwise extracts stronger assets against the fake mark.
    6. The manipulated structure collapses, leaving the protocol short, the next depositor overcharged, or the remaining holders diluted.
  • Variants:
    • Direct donation — raw underlying assets are transferred into the vault or wrapper so exchange rate rises without new shares.
    • Stealth donation — repeated rounding residues accumulate inside the vault and compound the rate without an explicit donation call.
    • First-deposit inflation — the attacker seeds an empty pool, donates into it, and causes the next depositor to receive almost no shares; use first-deposit-inflation when that launch-state victimization is the main analytical story.
    • Bootstrap replay — a live system is driven back toward dust supply or totalSupply == 0, reviving launch-era exchange-rate sensitivity; pair with bootstrap-state-replay-reversible-initialization-semantics when re-entry into initialization semantics is the sharper lesson.
    • Upstream recipient inflation — backing is inflated through an underlying staking or reward sink that sits beneath the wrapper mint path.
    • Cached valuation inflation — attacker-timed donations or market state are frozen into canonical NAV, rebasing index, or balance presentation.
    • Collateralized share-price attack — another lending market honors the inflated wrapper mark as borrowable collateral.
    • Self-liquidation monetization — the attacker prints the rate, borrows against it, then captures liquidation value on the way out.
  • Detection heuristics:
    • Ask whether numerator-side accounting can increase without a proportional share mint.
    • Inspect direct balance reads, cached NAV updates, rebasing index writes, reward syncs, and staking-recipient accounting as solvency surfaces, not mere UX helpers.
    • Stress-test empty, thinned, and near-zero-supply states; donation economics usually become cheapest there.
    • Trace every path where rounding leaves value behind and ask whether that residue is neutralized or compounds into the next rate calculation.
    • Treat wrapper-share collateral integrations as oracle integrations in disguise.
    • Ask whether balanceOf, convertToAssets, liquidation seize math, or redemption amounts can become attacker-authored via the same printed rate.
    • Re-test after burns, migrations, claims, or rescues that can recreate bootstrap-like supply conditions long after launch.
  • Defenses:
    • Use dead shares, virtual offsets, or other meaningful initial-liquidity buffers so a tiny actor cannot dominate the share base cheaply.
    • Track assets internally where appropriate instead of trusting raw token balances or ambient backing changes.
    • Explicitly discard or neutralize stealth donations and rounding leftovers instead of letting them accumulate into exchange-rate truth.
    • Gate or haircut wrapper-share collateral admission; do not assume pricePerShare is an oracle-grade fact.
    • Separate presentation math from solvency math so rebasing balanceOf or cached NAV cannot become same-block borrowing truth.
    • Bound cache-write, harvest, sync, or staking-recipient authority; whoever can crystallize numerator growth can often print value.
    • Treat supply near zero again as a production hazard, not just a launch hazard.

Three accounting promotions reviewers should not collapse

  1. Numerator-side value exists

    • Assets, rewards, raw balances, or backing somewhere in the wrapper stack have gone up.
    • This is only a local accounting fact. It does not yet answer whether existing shares deserved that increase, whether the increase was attacker-authored, or whether the protocol should publish it as canonical holder economics.

  2. The protocol published canonical share truth

    • The system turned that observed value into assets/share, pricePerShare, rebasing balance state, cached NAV, or another holder-facing wrapper truth.
    • This is the promotion Wise, ParaSpace, Zunami, and Raft-style incidents keep testing from different angles: some local or upstream balance-side change is no longer merely present, but has been socialized into the accounting object that users and integrations are told to believe.

  3. Downstream systems spent against that truth

    • Redemption, collateral, liquidation, recursive-borrow, or next-depositor pricing logic then honored the freshly published share mark as money-good authority.
    • This is a third and stronger claim than share accounting updated. A wrapper can be locally coherent enough to describe holder economics while still being far too fresh, too thin, or too attacker-shaped to deserve immediate borrow, redemption, or self-liquidation authority.

The recurring review mistake is to collapse these into one story: balance went up, so share price went up, so that share price was safe to spend against. Healthy systems keep those promotions visibly separate.

What sound design looks like

  • A healthy share system keeps four things tightly coupled and separately reviewable: recognized assets, issued shares, the canonical published share truth derived from them, and the economic surfaces allowed to honor that truth. If assets can increase without a deliberate recognition step, or if published share truth can immediately mint borrow power or redemption authority, the design is already too trusting.
  • Numerator growth should arrive through named, reviewable rails. Earned yield, approved donations, staking rewards, debt repayment residue, and strategy-side inventory changes should not all collapse into one undifferentiated totalAssets number unless the protocol is comfortable treating every one of those rails as money-good.
  • Share-price publication should be slower and stricter than share accounting. A vault may choose to expose a best-effort convertToAssets() view for UX, but collateral engines, liquidation math, rebasing balances, and cached-NAV mint/burn paths should consume a guarded version with caps, smoothing, haircuts, or quarantine.
  • Near-zero supply is a lifecycle state, not just a launch edge case. Good designs either make bootstrap conditions economically expensive to recreate or force renewed quarantine / reseeding before the share price can become trusted again.
  • Wrapper integrations should assume the wrapper’s own accounting can be attacker-authored. If another market wants to lend against that wrapper, it should treat the wrapper as a structured collateral object with its own manipulation model, not as a passive token.

Failure-prevention checklist

  • Define which balance changes are allowed to increase canonical share value: deposits, realized strategy profit, approved rewards, rescue flows, donations, debt repayments, or operator syncs. If the answer is all balance changes, the protocol is probably too permissive.
  • Keep an internal accounting ledger where possible and require explicit recognition steps for off-path asset increases, especially direct donations, reward drips, debt-repayment residue, and strategy-side transfers.
  • Add meaningful dead shares, virtual asset/share offsets, or minimum-liquidity floors large enough that a dust shareholder cannot cheaply dominate the exchange rate.
  • Re-test the same share math under thinned-supply and near-zero-supply states created by redemptions, bad-debt socialization, claims, migration drains, or emergency exits; do not stop at first-deposit analysis.
  • Bound rounding loss accumulation across deposit, mint, withdraw, redeem, repay, liquidation, and fee-accrual paths. If repeated user actions can manufacture unrepresented assets, those residues need explicit discard or amortization logic.
  • Treat wrapper-share collateral listing as an oracle and market-risk decision. Apply haircuts, borrow caps, delayed collateral enablement, and independent sanity bounds before a printed share rate becomes borrow power.
  • Require an explicit second gate between wrapper-local share truth exists and other modules may spend against it. Redemption, collateral admission, liquidation, recursive borrow, and next-depositor pricing should not all inherit the freshest possible wrapper mark automatically.
  • Keep presentation-layer outputs separate from solvency truth. balanceOf, rebasing index math, cached NAV, and user-facing convertToAssets should not become same-block collateral, redemption, or settlement authority without additional controls.
  • Restrict who can crystallize pending value into canonical rate state: harvest, sync, cache writes, staking-recipient updates, reward settlement, or index publication are security-sensitive authority surfaces.
  • Document what should happen when share price moves faster than the underlying strategy can plausibly earn. If there is no pause, clamp, quarantine, or haircut path, the protocol is assuming attacker-authored appreciation cannot happen.
  • Monitor concentration of share ownership and supply-floor states. If one actor can cheaply end up holding most surviving shares, the exchange rate has become a control surface.

Audit prompts

  • Which exact code paths can increase the numerator used in assets/share, pricePerShare, convertToAssets, or rebasing balance math without minting proportional shares?
  • Which code path first publishes that new numerator state as canonical share truth, and which separate code path — if any — later lets redemption, collateral, liquidation, or recursive-borrow logic spend against it?
  • If the vault receives assets outside the normal deposit path, where does the code decide whether those assets are earned value, quarantined value, or ignored value?
  • Can repeated rounding across deposit/withdraw, repay/borrow, liquidation, or fee settlement create compounding stealth donations rather than bounded one-off dust loss?
  • After large burns, redemptions, migrations, or rescue flows, can the live system re-enter a near-empty or bootstrap-like state where one actor cheaply dominates the share base?
  • Does any downstream module treat wrapper shares, rebasing balances, or cached NAV as if they were manipulation-resistant oracle inputs? If so, what independent cap or haircut limits the damage?
  • Who can trigger harvest, sync, cache publication, staking-recipient updates, or index refreshes, and can an attacker time those writes around transient numerator inflation?
  • Are balanceOf() and other presentation helpers ever consumed by collateral, liquidation, settlement, or allowance-sensitive logic that assumes the value is economically realized?
  • If the share price jumped 5x or 50x in one block, what mechanism would stop that printed move from immediately unlocking borrows, redemptions, or liquidations?
  • Does the protocol have an explicit policy for direct donations, unexpected rewards, rebasing underlying assets, and rescued funds, or does it silently let all of them feed the same share-price truth?
  • In the worst case, how much real value can leave the system before operators or governance can challenge the printed exchange rate?

Lessons that should already be standard

  • Exchange rate is not an innocent accounting output. In any integrated system it is a solvency primitive and should be reviewed like an oracle.

  • Internal accounting solves only the paths it actually names. If rounding residue, reward sync, or upstream staking state can still increase recognized assets, the donation problem is still alive.

  • Near-zero supply is not a historical event. Live systems can drift back into launch-dangerous states through burns, claims, and emergency operations.

  • Wrapper integrations fail at the seam, not only inside the wrapper. The exploit becomes real when another module treats a locally printable share mark as globally valid wealth.

  • Published share truth is still not automatic redeemable or borrowable authority. Wrapper-local accounting coherence deserves a slower downstream gate than the number now exists in storage.

  • Presentation math is inside the security boundary once balances, rebases, or cached NAV can drive borrowing, redemption, or liquidation outcomes.

  • User-protective rounding is not automatically safe. Repeated rounding in favor of the vault can become an attacker-owned issuance rail.

  • Whoever can publish or crystallize numerator growth is part of the custody model, even if the function was added for gas efficiency or operational convenience.

  • High-signal incidents:

Where this pattern helps most

  • Use this note when the core bug is that share-accounting or wrapper-backing truth became attacker-authorable.
  • Reach for donation-share-price-manipulation when the sharper follow-up is the broader oracle/collateral lens across vault and market designs, especially when comparing this family to other cheaply printable price exploits.
  • Reach for balance-delta-provenance-failure when the deepest question is not yet how was the rate monetized? but why did the protocol mistake ambient balance growth for earned value at all?
  • Reach for bootstrap-state-replay-reversible-initialization-semantics when the distinctive lesson is that a live system accidentally re-entered launch-only supply semantics.

Internal linkages

Control surface

Graph View

Backlinks