Cowrie Research

lodestar-finance-plvglp-donation-oracle-manipulation-2022-12-10

13 min read

Lodestar Finance plvGLP Donation / Oracle Manipulation Exploit (2022-12-10)

  • Name: Lodestar Finance plvGLP donation / oracle manipulation exploit
  • Date: 2022-12-10
  • Protocol: Lodestar Finance
  • Chain: Arbitrum
  • Category: donation / share-price manipulation / collateral-price inflation / oracle manipulation / bad-debt extraction
  • Loss: about 6.9M, with public statements at the time saying roughly 2.8M GLP remained potentially recoverable inside the manipulated collateral path
  • Summary: The Lodestar attacker used about 6M of bad debt.
  • Trigger / entry point:
    • Lodestar accepted plvGLP as collateral but did not use a Chainlink-style external price feed for it; the protocol’s own docs explicitly carved out plvGLP as an oracle exception.
    • The oracle path valued plvGLP from the Plutus vault exchange rate, i.e. totalAssets / totalSupply, multiplied by the underlying GLP price.
    • Plutus’ donate() behavior was normal vault behavior: assets could increase without new shares being minted.
    • Lodestar treated that instantly changeable exchange rate as money-good collateral inside a Compound-style lending market.
  • Root cause:
    • Lodestar assumed the plvGLP vault exchange rate was a trustworthy collateral input even though one actor could increase vault assets through donation without minting proportional shares.
    • The protocol therefore converted a legitimate vault-accounting feature into a manipulable oracle. Plutus’ own statement after the incident emphasized that donate() was effectively equivalent to transferring underlying assets into a standard vault; the bug was not that Plutus mis-accounted those assets, but that Lodestar treated that instantly changeable vault state as money-good collateral.
    • Once lplvGLP collateral value rose, Lodestar’s borrow controls still honored it at face value.
    • In practice, the protocol merged two brittle assumptions: that plvGLP exchange rate could not jump violently inside one block, and that a vault-share price derived from spot totalAssets / totalSupply was safe to use as lending collateral.
  • Exploit path:
    1. The attacker funded contract 0x7596acadf6c93f01b877f5a44b49407fffc53508 with a bundle of flash loans totaling about 70,096,512.99 USDC plus 14,960 WETH equivalent buying power across eight loans.
    2. They deposited roughly $70M of value into Lodestar’s lUSDC market, minting about 3,490,966,280.82 lUSDC and using that position as the base collateral for the rest of the loop.
    3. They borrowed the entire underlying plvGLP balance from Lodestar’s lplvGLP market, then immediately redeposited that plvGLP back into Lodestar to mint lplvGLP receipt tokens.
    4. By repeating the borrow-then-redeposit loop about 16 times, they concentrated control of roughly 3,051,070,160.01 lplvGLP, i.e. effectively the whole market’s receipt-token supply.
    5. They then called Plutus’ GlpDepositor.donate() path, increasing plvGLP assets without increasing plvGLP supply. Public postmortems describe the resulting plvGLP : GLP exchange rate moving from about 1.07 to about 1.82.
    6. Lodestar’s oracle read that manipulated exchange rate as a real collateral-price increase. Because the market’s collateral factor was 80%, SourceHat’s reconstruction implies each $1,000 of plvGLP that previously supported about $800 of borrowing now supported about $1,464 after the donation-induced reprice.
    7. The attacker transferred the inflated lplvGLP position to second contract 0xe1ba6511f95d8e6bca786ecbc4472de4c4137bff, isolating the debt on the first address while using the second to drain liquidity from the rest of Lodestar’s markets.
    8. With the inflated collateral marked at face value, the second contract borrowed out the remaining liquid assets across Lodestar, leaving the protocol undercollateralized.
    9. The attacker then unwound the manipulated plvGLP, redeemed into underlying fsGLP, sold out to harder assets, repaid the flash loans, and bridged proceeds away.
  • What the attacker needed to be true:
    • Lodestar had to let a large flash-loaned deposit dominate the borrow side of the relevant markets before any rate limit, cap, or collateral quarantine stopped the loop.
    • The plvGLP oracle had to read a live vault exchange rate rather than a delayed or haircut value.
    • The Plutus vault had to permit asset donations that increased totalAssets without issuing new plvGLP shares.
    • Lodestar needed to accept the manipulated lplvGLP value quickly enough that the attacker could borrow out stronger assets before governance or operators paused the market.
    • The protocol needed enough remaining liquid assets in sibling markets for the inflated collateral to monetize into real value.
  • Technical anatomy worth remembering:
    • This was not a fake oracle report. The oracle honestly reflected a manipulable vault state. The mistake was using that state as lending collateral truth.
    • The exploit sits at the boundary between oracle manipulation and donation / share-price manipulation. The donation into Plutus printed the exchange rate; Lodestar’s oracle and Comptroller turned that printed exchange rate into borrowable solvency.
    • Plutus’ donate() path was ordinary vault behavior, not the exploit in itself. The sharper lesson is that any integrator who reads totalAssets / totalSupply as same-block collateral truth is inheriting the vault’s donation semantics whether or not the vault is behaving as designed.
    • The borrow/redeposit loop mattered because it let the attacker own almost all of the lplvGLP supply before paying the cost to inflate the exchange rate.
    • The two-address structure mattered too: one address kept the debt, while the other used the now-overvalued collateral tokens to extract the healthy assets.
    • Lodestar’s own lesson after the hack was blunt: plvGLP collateral could not be allowed to undergo instantaneous same-block price change.
  • Representative transactions and addresses:
    • Main exploit transaction: 0xc523c6307b025ebd9aef155ba792d1ba18d5d83f97c7a846f267d3d9a3004e8c
    • Attacker EOA highlighted by REKT: 0xc29d94386ff784006ff8461c170d1953cc9e2b5c
    • Primary attack contract (A in SourceHat’s reconstruction): 0x7596acadf6c93f01b877f5a44b49407fffc53508
    • Secondary drain contract (B in SourceHat’s reconstruction): 0xe1ba6511f95d8e6bca786ecbc4472de4c4137bff
    • Lodestar lUSDC market: 0x5e3f2abaecb51a182f05b4b7c0f7a5da1942de90
    • Lodestar lplvGLP market: 0xcc25dac54a1a62061b596fd3baf7d454f34c56ff
    • Profit-distribution address noted by REKT / CertiK: 0xb50f58d50e30dfdaad01b1c6bcc4ccb0db55db13
  • Response / mitigation:
    • Lodestar paused deposits and set interest rates to zero while assessing the bad debt and trying to negotiate with the attacker.
    • Public statements said roughly 2.8M GLP remained potentially recoverable from the manipulated collateral side, though the protocol still faced large realized losses.
    • Post-incident commentary converged on the same immediate fix: do not let a vault-share oracle used as collateral react instantly to donation-driven exchange-rate changes.
    • More generally, the incident reinforced that adding one custom asset to a battle-tested lending fork can create a new system-defining attack surface.

Why this incident matters

  • Lodestar is a clean example of a vault donation becoming a lending-oracle exploit without any compromised reporter or stale feed.
  • It broadens the donation / share-price-manipulation corpus beyond near-empty ERC-4626 launches like Resupply and rounding-heavy cases like Wise by preserving the non-empty yield wrapper used as collateral oracle variant.
  • It is also a useful bridge case between oracle manipulation and donation/share-price manipulation: the attacker did not need the oracle to lie, only to tell the truth about a manipulable exchange-rate input.
  • The sharper preserved healthy-side boundary is that wrapper exchange rate is readable should not have been treated as wrapper can immediately underwrite full borrow power and liquidation authority across deeper sibling reserves. Lodestar needed a stronger downstream distrust boundary than Plutus math is locally canonical right now.

Three wrapper-and-borrow-authority promotions this incident collapsed

  1. Extra GLP-backed value appeared inside the plvGLP wrapper

    • Plutus’ GlpDepositor.donate() path increased wrapper assets without minting matching new plvGLP shares.
    • At this stage the strongest safe claim was only that more underlying value now sat behind the wrapper. That did not yet mean incumbent shares had economically earned that increase, that the move was manipulation-resistant, or that the new exchange rate deserved immediate lending meaning.

  2. Lodestar published that donated wrapper state as canonical collateral truth

    • GLPOracle / PriceOracleProxyETH turned Plutus’ live totalAssets / totalSupply exchange rate into Lodestar’s plvGLP price input.
    • This was the decisive over-promotion. A wrapper-local accounting state that Plutus could honestly report was treated as if it were already a protocol-safe collateral mark for a Compound-style money market.

  3. The rest of Lodestar spent against that published truth

    • After the donation-driven reprice, the attacker moved the inflated lplvGLP position to a second address and borrowed real assets out of healthier sibling markets.
    • This was the final and most dangerous promotion: wrapper exchange rate moved became protocol-wide borrow authority exists right now, even though the new mark was still just attacker-authored wrapper state.

Pattern tags:

Why the exploit worked

  • Lodestar carved plvGLP out into a custom oracle path that treated the live Plutus exchange rate as collateral truth instead of applying a slower or more skeptical solvency mark.
  • The attacker could dominate the lplvGLP market through recursive borrow-and-redeposit loops, so any later donation-driven reprice applied to almost the entire economically relevant collateral base.
  • Plutus’ donate() path legitimately increased assets without minting new shares; Lodestar inherited that semantics as if it were a manipulation-resistant oracle input.
  • Collateral transfers and borrowing remained permissive enough that the attacker could separate the debt-bearing account from the draining account and monetize the inflated mark before pause controls caught up.

Detection and audit pivots

  • Inventory every asset that bypasses the default oracle stack and ask whether the exception path ultimately resolves to live totalAssets / totalSupply, pricePerShare, or another wrapper-local rate.
  • Simulate what happens if one actor owns nearly all receipt tokens in a listed wrapper market before the exchange rate moves; concentration often matters as much as the donation itself.
  • Check whether collateral tokens can be transferred to a fresh account while debt stays behind, especially when that transfer can turn one printed mark into protocol-wide borrowing power.
  • Review whether a same-block wrapper-rate jump can expand borrow capacity with no cap, damping, or delayed collateral-recognition window.
  • Ask whether the protocol has an asset-local de-recognition path once a listed wrapper proves donation-sensitive in production.

Failure-prevention checklist

  • Treat every wrapper-local exchange rate used as collateral as a separate solvency object from the underlying asset’s spot price. A custom oracle path that resolves to totalAssets / totalSupply or a vault-specific exchange rate deserves its own collateral policy, not the base asset’s default settings.
  • Keep donation-sensitive wrappers in isolated mode or under tight debt ceilings until the protocol has a strong answer for direct-donation, low-supply, and market-concentration stress cases. listed wrapper should not mean may underwrite the whole rest of the balance sheet.
  • Add borrow-side quarantine for abnormal wrapper-rate jumps. If a wrapper mark moves far faster than plausible earned yield, the healthier default is haircut, delay, or pause rather than immediate new borrowing power.
  • Model recursive market-concentration loops as part of listing risk. If one actor can borrow the wrapper, redeposit it, and end up owning almost the entire receipt-token side before paying to move the exchange rate, the oracle is already too close to attacker control.
  • Keep collateral transfer, liquidation, and debt-separation paths coupled to the manipulated-asset risk model. If one address can warehouse the debt while another carries the inflated collateral mark into healthy sibling markets, the protocol should treat that portability itself as part of the exploit surface.
  • Maintain an explicit semantic revocation path for wrappers. Once production proves that canonical wrapper math and safe collateral meaning can diverge under donation, governance and operators need a fast way to de-recognize the asset rather than continue honoring the raw wrapper mark.

Audit prompts

  • Which exact function or state read sets the collateral value for this wrapper, and can direct donations or other off-path balance changes move it without minting matching shares?
  • If one actor first dominates the wrapper market through borrow-and-redeposit loops, how much real capital is then required to move the wrapper exchange rate enough to break the protocol’s collateral assumptions?
  • What concrete control stops a same-block wrapper-rate jump from becoming immediate borrow power across deeper sibling reserves: a cap, a haircut, a delayed mark, isolated mode, or nothing at all?
  • Can an attacker separate debt and monetization across addresses after the wrapper mark is printed, leaving one account undercollateralized while another drains healthier assets?
  • If the wrapper’s exchange rate doubled but exit liquidity or redemption depth did not, where does the protocol encode that distinction before lending against the wrapper at face value?
  • How quickly can governance or operators revoke collateral recognition for one listed wrapper without freezing unrelated markets, and is that path operationally realistic during an active exploit?

Lessons that should already be standard

  • An oracle can be perfectly honest and still be catastrophically unsafe. If it reports attacker-printable wrapper state, the feed told the truth is not a defense.
  • Wrapper integrations are not ordinary token listings. They are balance-sheet transformations, and the wrapper’s accounting semantics become part of the lending protocol’s own solvency surface.
  • Market concentration and oracle design are one attack surface. Letting one actor own almost the whole receipt-token side before they pay to move the exchange rate is already a major pricing failure.
  • Redeemable at this rate inside the wrapper is not the same claim as safe to fund protocol-wide borrowing at this rate right now. Collateral meaning has to be stricter than local wrapper math.
  • Donation-sensitive wrappers need a fast downgrade path. Once a wrapper proves that fresh accounting state can outrun realistic exit value, the healthy response is to quarantine or de-recognize it, not to keep trusting the same mark out of consistency.

Internal linkages

  • Core recurring pattern: donation-share-price-manipulation — the donation itself was ordinary wrapper accounting; the deeper recurring mistake was letting off-path asset growth become canonical share-price truth.
  • Broader oracle/collateral framing: donation-share-price-manipulation — useful when the sharper question is how that printed wrapper mark crossed the next trust boundary and became borrowable collateral.
  • Adjacent pattern: oracle-manipulation — the monetization step was classic fake-collateral borrowing, but the price-printing mechanism came from vault-share donation math rather than a thin spot market.
  • Positive-design companion: collateral-admission-lag-and-borrow-side-quarantine — Lodestar’s real downstream mistake was not merely reading the wrong number, but letting a fresh donation-sensitive wrapper mark become immediate borrow-side authority across the rest of the protocol.
  • Wrapper-semantics companion: wrapper-semantic-price-revocation-and-collateral-derecognition — once a listed wrapper proves that canonical exchange rate and safe collateral meaning can diverge under donation, the healthier response is to tighten or revoke collateral recognition instead of honoring the raw wrapper mark at face value.

Control surface

Graph View

Backlinks