Cowrie Research

donation-share-price-manipulation

25 min read

Donation / Share-Price Manipulation

  • Name: Donation / share-price manipulation
  • Category: exploit pattern / exchange-rate manipulation / vault-accounting failure / collateral-inflation vulnerability
  • Summary: Donation / share-price manipulation attacks break systems that treat vault share price, LP share price, or similar receipt-token exchange rates as trustworthy solvency facts. The attacker forces assets into the pricing equation without minting proportional shares — through direct donations, stealth donations from rounding, debt-repayment edge cases, raw-balance accounting, or other asymmetries — and then monetizes the inflated share price through whatever path the protocol honors fastest: collateral borrowing, self-liquidation, redemption, or even the receipt token’s own balance presentation. The sharpest modern lesson is that presentation math is not a harmless UI layer when balanceOf, rebase math, cached NAV, or allowance-relevant accounting starts consuming the same attacker-printable exchange rate as the solvency engine. The positive-design corollary is equally important: the wrapper can compute a new rate should not automatically mean that rate may instantly mint debt, trigger liquidation, or remain money-good after wrapper semantics break upstream.
  • What it is:
    • A vault, LP token, or receipt-token system values shares as a function of assets held versus shares outstanding.
    • The protocol assumes the asset side of that ratio only moves through approved accounting paths.
    • The attacker finds a way to increase accounted assets without receiving matching new shares, or to otherwise skew the assets-per-share ratio upward.
    • That inflated share price is then used as collateral, borrow power, withdrawal entitlement, or some other solvency-critical input.
    • The real theft comes after the price distortion: borrow stronger assets, drain a pool, or leave bad debt once the manipulated collateral disappears or proves unrealizable.
  • Typical preconditions:
    • Share price, exchange rate, or convertToAssets-style math is used in a lending, collateral, redemption, rebase, or cached-balance path.
    • The vault relies on raw token balance, rounding-biased conversions, or another path that can increase effective assets without issuing proportional shares.
    • The attacker can become a dominant or sole shareholder in the manipulated vault, or can otherwise retain enough of the share supply to redeem the inflated pool later.
    • Another protocol module trusts the manipulated share price quickly enough to let the attacker borrow, withdraw, settle, snapshot, or re-mark token balances before defenses catch up.
    • A cache, snapshot, or accounting adapter can freeze a transiently manipulated exchange rate long enough for the attacker to unwind the setup leg and still cash out the printed value.
    • Supply has become thin enough — whether from launch conditions, later redemptions, liquidations, or migration churn — that a practical donation can still move assets-per-share materially even though the vault is not literally empty.
    • The wrapper may exist in chain-local deployments whose convertToAssets state, supply floor, or emergency controls diverge from the canonical deployment, while integrators still inherit one broad same asset, same risk story.
    • The same wrapper family can be borrowed, posted as collateral, or recycled across closely related accounts, so a printed exchange rate can be monetized through self-liquidation or borrow/redeposit loops instead of only a one-shot borrow.
    • Dead shares, virtual offsets, internal accounting, rate smoothing, explicit discard of stealth donations, or hard separation between share accounting and presentation math are absent, incomplete, or bypassable.
  • Common vulnerable surfaces:
    • ERC-4626 vaults whose asset accounting can be skewed by direct donation
    • vaults with rounding behavior that lets repeated deposit/withdraw loops create stealth donations
    • lending markets that accept vault shares or LP receipt tokens as collateral
    • protocols that value shares from spot totalAssets / totalSupply style math with no guardrails
    • custom-oracle exception paths where one listed asset bypasses the default pricing stack and is instead valued from a wrapper-local exchange rate or adapter-specific convertToAssets logic
    • systems where debt repayment, fee accrual, or flash-loan accounting can move assets-per-share unexpectedly
    • empty or near-empty pools where one attacker can cheaply own most of the share supply before inflating the rate
  • Exploit sequence:
    1. The attacker gets an initial foothold in the target vault with a tiny deposit or otherwise becomes an early / dominant share holder.
    2. The attacker inflates assets-per-share through direct donation, stealth donation from rounding, or another accounting path that increases assets without proportional shares.
    3. The attacker repeats the skewing step until each share is worth far more on paper than it should be.
    4. The attacker uses those overpriced shares as collateral or as a claim on the vault, often through sibling lending pools.
    5. The attacker borrows or withdraws stronger assets against the fake share price.
    6. The attacker redeems the concentrated share position or otherwise collapses the manipulated structure, leaving the protocol with depleted reserves or bad debt.
  • Variants:
    • Direct donation — the attacker transfers underlying assets directly to the vault so totalAssets rises without new shares being minted.
    • Stealth donation — the attacker exploits rounding during deposit / withdraw / repay flows so small unrepresented asset amounts accumulate inside the vault and compound the exchange rate.
    • First-deposit inflation — the attacker seeds an empty vault, donates assets, and frontruns the first real depositor so the victim gets almost no shares.
    • Bootstrap replay / near-zero-supply recurrence — the system is driven back toward totalSupply == 0 or another dust-supply state, resurrecting launch-like exchange-rate sensitivity long after deployment and letting a tiny surviving share position dominate the next rate-setting step; use reversible initialization semantics when the sharper lesson is that production re-entered launch-only lifecycle semantics.
    • Collateralized share-price attack — the attacker inflates a share token specifically because another market accepts it as collateral.
    • Supply-thinning replay — the vault is not empty, but prior redemptions, burns, or cross-chain outflows have made live share supply thin enough that a direct donation becomes economically decisive again; the practical risk comes from a seasoned wrapper drifting back toward launch-like donation sensitivity.
    • Chain-local wrapper divergence — a wrapper’s exchange-rate semantics are chain-specific, so one deployment becomes donation-sensitive or easier to move while integrators and risk policies still treat the ticker as globally uniform.
    • Self-liquidation monetization — the attacker uses the manipulated exchange rate on both sides of a lending position, then cashes out through liquidation math instead of a simple borrow path.
    • Cached-NAV / balance-presentation attack — the protocol snapshots a manipulated asset price or NAV and reuses it inside balanceOf, rebase, or redemption math, so the receipt token itself becomes the payout rail.
    • Redemption concentration attack — after forcing most or all other shares out of circulation, the attacker redeems the remaining dominant share position against the swollen asset pool.

Three wrapper-price promotions reviewers should not collapse

  1. A wrapper-side value change exists

    • Assets, backing, cached NAV inputs, rebasing index components, or other numerator-side state moved somewhere in the wrapper stack.
    • That is only the weakest fact. It does not yet mean existing shares deserved the move, that the move was economically earned, or that downstream modules should honor it as a money-good solvency mark.

  2. The protocol published canonical wrapper-price truth

    • The system turned that local state into pricePerShare, convertToAssets, rebasing balanceOf, cached NAV, or another canonical wrapper mark.
    • This is the promotion donation-sensitive systems keep getting wrong: a local balance-side or upstream-backing change stopped being just state exists and became the official answer other modules are told to believe.

  3. Downstream systems spent against that published truth

    • Collateral engines, liquidation math, reciprocal-price paths, redemption logic, settlement snapshots, or even presentation-layer balances then honored the freshly published mark as if it already deserved reserve-moving authority.
    • That is a third and stronger claim than wrapper accounting updated. A wrapper can compute a new rate without that rate deserving same-block borrowing power, liquidation authority, or wallet-visible spendability.

Healthy review gets materially better once teams stop flattening those three promotions into one story: the wrapper mark changed, so the new mark was safe to spend against.

  • Detection heuristics:
    • Ask whether totalAssets can increase without a corresponding share mint.
    • Check every rounding direction in deposit, mint, withdraw, redeem, repay, fee-accrual, and liquidation paths.
    • Stress-test tiny-supply states, because exchange-rate manipulation is often cheapest when the pool is nearly empty.
    • Re-test the same economics after burns, claims, liquidations, migrations, bridge outflows, or POL reconciliation steps that can drive a live system back toward dust supply; launch-state donation risk often comes back later instead of staying confined to deployment day.
    • Track share-supply thinning explicitly, not just is supply zero?. A wrapper can stay non-empty and still become donation-sensitive again after large redemptions or chain-local outflows.
    • Treat any vault-share collateral integration as an oracle problem in disguise: can one actor cheaply print a higher exchange rate than the market can actually realize?
    • Model iterative attacks, not just one-off donations; stealth donations are dangerous because they compound.
    • Ask whether the protocol distinguishes real yield from arbitrary balance changes.
    • Inventory every asset that bypasses the protocol’s default oracle stack, and trace whether the exception path ultimately resolves to live wrapper-local state such as pricePerShare, convertToAssets, or totalAssets / totalSupply. A one-off adapter is often where donation-sensitive semantics sneak into an otherwise conservative lending fork.
    • If the wrapper exists on multiple chains or under multiple wrappers, compare each deployment’s local totalAssets, totalSupply, redemption path, and emergency controls rather than assuming the main deployment’s safety profile transfers automatically.
    • If the wrapper can be both borrowed and posted as collateral, model same-family borrow/redeposit and self-liquidation paths explicitly; do not assume the liquidator side provides independent price discovery.
    • Trace every place the exchange rate crosses a trust boundary: collateral factor math, liquidation math, rebases, balanceOf, allowance, settlement snapshots, and operator-triggered cache writes.
    • Inspect every caching or smoothing layer carefully: if a public or attacker-triggerable snapshot can freeze manipulated NAV into balanceOf, convertToAssets, rebase, or redemption logic, the cache is part of the exploit surface rather than a harmless gas optimization.
    • Ask whether the protocol’s presentation layer can make fake value spendable before governance, operators, or arbitrageurs can challenge the mark. If yes, the UI/accounting layer is inside the solvency boundary.
  • Defenses:
    • Use dead shares or meaningful virtual asset/share offsets so an attacker cannot cheaply own the whole pool and inflate from an almost-empty state.
    • Treat supply back near zero as a live hazard, not just a deployment hazard. If claims, pool drains, reconciliation, emergency exits, invariant repair paths, or chain-local redemption waves can recreate bootstrap conditions, the same donation economics can come back in production.
    • Re-underwrite donation-sensitive wrappers after large supply contractions. A wrapper that was tolerable at one live-supply regime may need lower caps, lower collateral factors, isolated mode, or full de-recognition after redemptions materially thin the share base.
    • Track assets internally when appropriate instead of trusting raw token balances.
    • Explicitly discard or neutralize stealth donations from rounding residues rather than letting them compound into exchange-rate growth.
    • Apply caps, haircuts, or separate oracle logic before accepting vault shares as lending collateral.
    • Treat chain-local wrapper deployments as separate solvency objects when their supply profile, redemption path, or donation sensitivity can diverge. Shared branding is not a substitute for per-deployment risk policy.
    • Smooth, snapshot, or otherwise constrain solvency-critical exchange-rate jumps when the underlying strategy cannot plausibly move that fast.
    • Keep share accounting, solvency math, and presentation math separate whenever possible. balanceOf, allowance, and rebase-style display logic should not become immediate consumers of attacker-triggerable NAV.
    • Never let an attacker-triggerable cache write turn manipulated NAV into immediate balanceOf or redemption truth; presentation-layer balance math should not become a same-block solvency oracle.
    • Treat cache writers, snapshot timing, and strategy-valuation adapters as privileged security surfaces even if they were added for gas savings or UX convenience.
    • Audit sibling modules together: the vault math, token-accounting layer, and lending-market collateral logic are one attack surface.

What sound design looks like

  • A healthy design keeps three questions visibly separate: what wrapper-side value change exists, what canonical wrapper mark gets published from it, and which downstream paths are allowed to spend against that mark. Those should not collapse into one unreviewed price updated moment.
  • The wrapper’s local exchange rate and the integrator’s solvency price should be treated as different objects. Good designs keep a guarded translation layer between them, with caps, time delay, haircuts, or independent sanity checks before the wrapper’s own accounting becomes borrowable wealth.
  • Cross-chain wrappers need one more separation too: shared ticker or issuer story is still weaker than per-deployment solvency truth. If one deployment’s local supply, redemption path, or exchange-rate sensitivity drifts, that deployment should lose inherited collateral trust even while sibling deployments remain unremarkable.
  • Oracle resilience for share tokens is not only about source diversity. If the underlying source is the wrapper’s own convertToAssets or pricePerShare, then the real defenses live in admission policy, supply-floor design, rate-change limits, and publication authority around that wrapper state.
  • Organic inflation should be bounded by strategy reality. If a vault cannot plausibly earn 20% in one block, the collateral system should never have to decide whether a one-block 20% mark is real.
  • The safest systems force time to pass between value appears in wrapper accounting, that value becomes canonical wrapper truth, and that truth becomes spendable elsewhere, especially when the observed move depends on donation-sensitive balances, rounding residue, or public cache/sync calls.
  • Healthy collateral systems also keep an emergency semantic revocation path: if a wrapper proves donation-sensitive, loses redemption integrity, or otherwise stops deserving its old price meaning, downstream modules can de-recognize it quickly instead of continuing to honor the raw wrapper mark out of habit.

Failure-prevention checklist

  • Write down three separate policies for every wrapper integration: what local value changes may exist, what code path is allowed to publish canonical wrapper-price truth from them, and which downstream actions may actually spend against that published mark. Do not let one convenience view answer all three questions by default.
  • Write down which wrapper marks may create collateral credit, borrowing power, liquidation authority, or redemption value, and which are only informational. Do not let a convenience convertToAssets view silently become all four.
  • Apply listing-time and runtime caps to ERC-4626 shares, rebasing wrappers, and receipt tokens based on exit depth and manipulation cost, not on the wrapper’s own self-reported rate alone.
  • Treat any oracle exception asset as higher-risk by default. If one market bypasses the standard pricing stack and relies on bespoke wrapper math, isolated mode, lower debt ceilings, slower collateral recognition, and explicit downgrade runbooks should be the baseline rather than optional hardening.
  • Add nonzero minimum-liquidity / minimum-share-state requirements before wrapper prices are trusted as collateral truth, and re-apply those checks if supply later thins back down.
  • Quarantine large share-price jumps that cannot be justified by strategy economics. Haircut, delay, or pause when wrapper exchange rates move faster than expected yield, reward schedules, or rebasing rules can explain.
  • Treat direct donation, stealth donation, and upstream-backing inflation as oracle-risk scenarios. If any of them can move a wrapper mark materially, the integration needs explicit defenses even if the wrapper itself is standards-compliant.
  • Separate publication from consumption: cache writes, syncs, rebases, balanceOf updates, and NAV snapshots should not instantly reprice collateral or base assets without an additional control layer.
  • Add a borrow-side quarantine for fresh or abnormal wrapper marks: lower collateral factors, isolated mode, recursion bans, debt ceilings, delayed liquidation eligibility, and asset-local pauses should all be available before a newly printed rate can underwrite deep-liquidity borrowing.
  • Prevent same-family balance-sheet reuse where appropriate. If a donation-sensitive wrapper can be borrowed, re-supplied, and then used to fund liquidation or recursive leverage, the protocol should assume self-liquidation monetization is part of the default threat model.
  • Add reciprocal-domain and upper-bound checks anywhere inflated wrapper marks later flow through inverse-price math, share-to-asset conversion, or liquidation seize formulas.
  • Keep borrow caps, liquidation incentives, and settlement limits coupled to the wrapper’s manipulation model. Thin wrapper markets should not be allowed to underwrite large withdrawals from deep-liquidity reserves.
  • Audit every composed dependency in the price path: wrapper accounting, underlying asset oracle, AMM TWAP, adapter normalization, cache timing, and liquidation math. Donation-sensitive wrappers usually fail across seams, not inside one function.
  • Instrument monitoring so operators can see when wrapper price growth is coming from donations, supply collapse, rebasing index jumps, or cache publication rather than from ordinary earned yield.

Audit prompts

  • What exact local state change exists first, what exact code path later publishes canonical wrapper-price truth from it, and what exact downstream module finally spends against that published mark?
  • What exact function or state read is the protocol trusting as the wrapper price: convertToAssets, pricePerShare, reserve-derived NAV, rebasing balanceOf, cached NAV, or a custom adapter?
  • Which listed assets bypass the default oracle stack entirely, and does the exception path reduce to wrapper-local accounting that one actor can move faster than the protocol can safely honor?
  • Can the wrapper mark increase without proportional share minting through direct donation, rounding residue, debt repayment, reward sync, staking-recipient inflation, or strategy-side transfers?
  • If the wrapper price moved 2x, 10x, or 100x in one block, what explicit limiter would stop that mark from creating immediate borrow power or bad-debt exposure?
  • Does the integrator treat the wrapper as a thin oracle surface with caps and haircuts, or as if the wrapper’s own accounting were equivalent to a deep external market price?
  • Can public users trigger the cache/snapshot/rebase/write that crystallizes manipulated wrapper state into collateral truth, and can they do so in the same transaction as borrowing or redeeming?
  • Are there near-empty, first-deposit, or post-redemption states where one actor can cheaply own most shares and therefore define the next meaningful price?
  • Does the protocol rely on TWAP or averaged AMM prices for the wrapper token while ignoring the fact that the wrapper’s internal exchange rate change is permanent rather than mean-reverting?
  • If the wrapper is used as both collateral and borrowed asset, what stops a self-liquidation or borrow/redeposit loop from monetizing the printed exchange rate on both sides?
  • After large redemptions or bridge outflows, what exact control forces the protocol to revisit manipulation cost before the wrapper keeps its old caps and collateral settings?
  • Are supposedly identical wrappers on different chains actually different solvency objects once local totalSupply, redeemability, or emergency controls diverge?
  • Where do reciprocal or normalization steps assume the wrapper mark stays within a safe range, and what happens if donation-driven inflation pushes that assumption past zero, overflow, or cap boundaries?
  • When monitoring sees a wrapper price spike, can responders tell whether it came from real earned yield, thin-supply donation economics, rebasing-index publication, or an attacker-timed cache update?

Lessons that should already be standard

  • Standards compliance is not oracle safety. An ERC-4626 token can be perfectly compliant and still be catastrophically unsafe as immediate collateral.

  • Wrapper-side value changed, the protocol published a new canonical wrapper mark, and downstream systems spent against that mark are three different claims.

  • TWAP does not rescue permanent share-price inflation. Once the wrapper’s internal rate has been printed upward, arbitrage often helps lock the higher price in rather than healing it.

  • Cross-chain sameness of ticker or issuer is not cross-chain sameness of donation risk. Chain-local wrapper supply and redemption state can make one deployment exploitable while siblings still look healthy.

  • Supply thinning is a live production state, not just launch trivia. A wrapper that survives long enough can still drift back into donation-sensitive economics after redemptions or migration churn.

  • Wrapper rates deserve their own collateral policy. Reusing the same risk settings as spot assets is how donation-sensitive accounting becomes protocol-wide bad debt.

  • A wrapper’s self-reported appreciation is not automatically earned yield. Donations, rounding residue, and upstream staking flows can all look identical unless the design separates local value appeared from published share truth deserves to move reserves.

  • Cache writers, sync calls, rebases, and balance-publication logic are oracle operators in practice. If they can turn attacker-authored accounting into spendable value, they are part of the trust boundary.

  • The wrapper and the integrator share one attack surface. Auditing them separately misses the exact seam where printed exchange rate becomes honored collateral.

  • If a price path cannot explain why the wrapper became more valuable this block, it should not be allowed to mint new credit this block.

  • High-signal incidents:

    • share-price manipulation (2024-01-12) — the clean modern exemplar of iterative rounding-based stealth donations inflating a vault share price until puppet accounts could overborrow against it.
    • zero-exchange-rate exploit (2025-06-26) — the sharp direct-donation variant where an empty ERC-4626 collateral vault printed such a large share price that the lending layer’s inverse price math rounded the exchange rate down to zero and disabled LTV checks outright.
    • GoGoPool ggAVAX first-depositor share-price inflation near miss (2023-01-03) — the clean first-depositor-victimization cousin where attacker-donated WAVAX plus attacker-timed syncRewards() turned the same printed exchange-rate lie into direct overcharging of the next depositor before any downstream lending or cached-NAV rail was needed.
    • infinite-mint exploit (2025-11-30) — the useful bootstrap replay cousin where a live system was first driven back to prev_supply == 0, reopening initialization-era rate-setting assumptions and showing that near-empty share-accounting hazards can return after launch rather than staying confined to first deposit.
    • [[../../../incidents/accounting-issuance-claims/cream-finance-yusd-pricepershare-donation-wrappable-token-collateral-drain-2021-10-27|C.R.E.A.M. Finance yUSD pricePerShare donation / wrappable-token collateral drain (2021-10-27)]] — the canonical pre-ERC-4626 wrapper case where direct yCrv donation into Yearn’s yUSD vault doubled pricePerShare() and C.R.E.A.M. immediately honored that printed wrapper exchange rate as borrowable collateral across its v1 markets.
    • oracle manipulation exploit (2022-12-10) — a useful non-empty yield wrapper used as collateral cousin where the attacker first concentrated the lending-market share supply, then used Plutus’ normal donate() path to print a higher plvGLP exchange rate that Lodestar’s oracle treated as borrowable value.
    • oracle self-liquidation exploit (2023-04-28) — a strong non-empty wrapper exchange rate priced through a custom oracle plus attacker-controlled liquidation cousin where a direct GHST donation printed a higher convertVGHST() rate and 0VIX immediately honored that wrapper state in both debt pricing and liquidation seize math.
    • cAPE third-party ApeStaking recipient inflation near miss (2023-03-17) — a useful rebasing staking-wrapper numerator can be inflated one layer deeper than the wrapper itself cousin where outsiders could deposit raw APE into address(cAPE)’s staking position, print a much higher rebasing index without minting matching wrapper shares, and turn that donation-like backing inflation into borrowable pcAPE collateral before BlockSec’s rescue transaction front-ran the final withdrawal.
    • zETH SDT-donation price-caching share-inflation drain (2023-08-13) — a strong strategy-side donation + cached share-price cousin where donated SDT and a flash-pumped sdtPrice made Zunami cache an inflated NAV, so the attacker’s own UZD balance expanded from about 4.87M to about 16.9M before those printed shares were dumped into Curve.
    • collateral-index manipulation unbacked-R mint (2023-11-10) — a strong rebasing collateral token / presentation-layer balanceOf cousin where a direct cbETH donation repriced Raft’s global rcbETH-c index, 1 wei deposits still rounded up to one raw share, and the protocol immediately treated each raw share’s inflated balanceOf() value as borrowable collateral.
    • Venus ZKsync wUSDM donation exchange-rate exploit (2025-02-27) — the sharp chain-local wrapper + supply-thinning replay + self-liquidation cousin: earlier zkSync redemptions had already shrunk live wUSDM supply, a direct USDM donation then printed a much higher local exchange rate, and Venus still let the same wrapper family sit on both the borrow side and the collateral side long enough for the attacker to cash out through liquidation.
    • [[../../../incidents/oracle-market-abuse/venus-protocol-thena-the-supply-cap-bypass-donation-price-manipulation-bad-debt-2026-03-15|Venus Protocol THENA THE supply-cap-bypass donation / price-manipulation bad-debt incident (2026-03-15)]] — the strong non-empty Compound-v2 market with capped mint path but uncapped raw-balance exchange-rate path cousin: the attacker first concentrated vTHE, then used direct THE donations to inflate exchange rate without minting new shares, and finally paired that printed collateral quantity with spot-price manipulation to turn it into borrowable value.
    • OpenZeppelin’s early ERC-4626 inflation-attack discussion remains the clean baseline for first-deposit donation mechanics, even when no second protocol is needed to monetize the distortion.

Internal linkages

Control surface

  • The leverage sits where wrapper-side value changes are observed, where those observations are promoted into canonical wrapper-price truth, and where that published truth is finally allowed to mint borrowing power, liquidation authority, redemption value, or presentation-layer spendability: vault accounting, rounding policy, empty-pool initialization, share-collateral admission, cache / snapshot authority, and every place a protocol confuses balance changes with earned value.
  • Donation / share-price attacks are not just vault math bugs. They are solvency-design failures where the protocol lets an attacker print exchange-rate reality and then borrow against it, self-liquidate against it, redeem against it, or even make balanceOf itself report the fiction as spendable truth.
  • The recurring systems mistake is organizational as much as mathematical: teams treat strategy valuation, token presentation, and collateral accounting as separate concerns even though an attacker only needs one path between them to turn a transient mark into real reserves.

Sources

Last reviewed

  • 2026-07-30 UTC

Graph View

Backlinks