Loss: about $1.146M, roughly 10% of Levana’s Osmosis LP liquidity over the full attack window
Summary: Levana’s Osmosis perps markets let traders submit valid Pyth price updates as part of position-management flow. That was supposed to be safe because fresh user flow and Levana’s own bots would keep prices current. In practice, the protocol still accepted non-EMA Pyth updates up to 120 seconds old, while market-level staleness for the ATOM-USD market was reportedly configured at 2 hours. The attacker exploited the gap between latest publishable Pyth VAA and latest price Levana had actually recorded onchain, then made the gap much more profitable by starving competing oracle updates and user trades during congestion. The result was a slow-burn oracle-liveness exploit: over roughly 13 days, the attacker repeatedly chose when a favorable stale Pyth update would enter Levana, opened the directionally correct position against that stale mark, then closed against a newer mark they already knew was available, draining about $1.146M from LPs.
Trigger / entry point:
Levana’s Osmosis perpetual markets used Pyth price feeds bridged through Wormhole VAAs, and Range’s writeup says the market contract stored accepted prices in a PRICES variable.
Pyth updates could be submitted permissionlessly through update_price_feeds, and Levana position flow could append the latest accepted price when opening or closing a position.
Levana reportedly used the Pyth non-EMA price rather than the EMA value, which left the protocol more directly exposed to short-horizon price timing.
For the ATOM-USD market, Range reports age_tolerance_seconds = 120 and staleness_seconds = 2 hours, creating a real but bounded stale window the attacker could monetize.
Congestion on Osmosis and disruption of Levana’s own update bots reduced the chance that honest activity would refresh the oracle path before the attacker completed the trade cycle.
Root cause:
Levana assumed the chain and its own offchain bot infrastructure would keep oracle freshness high enough that letting traders submit valid recent Pyth updates remained safe.
The protocol let order execution depend on which valid VAA landed onchain, not just on whether the referenced Pyth price was authentic. That handed the attacker timing optionality over a still-valid but no-longer-current price.
Levana also coupled trading availability to network liveness: when congestion or backend disruption prevented routine price pushes, the stale window stopped being a rare nuisance and became the core exploit surface.
The decisive bug was not that Pyth published a false price. It was that Levana kept honoring an older but still-valid price as live execution truth while the attacker could already see newer publishable prices and could suppress competing refreshes.
Exploit path:
The attacker monitored fresh Pyth VAAs relayed through Wormhole and identified moments when the live market had moved enough relative to the last price Levana had recorded onchain.
They waited for a sufficiently profitable delta between an attack entry price and a later attack exit price still inside Levana’s accepted age window.
They submitted update_price_feeds with the older favorable price and opened a long or short position in the direction that would profit once the newer price was recorded.
They then submitted another update_price_feeds carrying the later price and closed the position, crystallizing the pre-known price move as protocol-honored PnL.
Honest user flow or Levana bots could have interrupted this by publishing fresher prices first, so the attacker benefited enormously from execution starvation during congestion.
The exploit appears to have run at lower intensity from about 2023-12-13, when suspicious accounts began showing unusually profitable directional trading, and then accelerated sharply on 2023-12-26 during severe Osmosis congestion.
By the time Levana paused new positions and markets, the affected pools had lost about $1.146M.
What the attacker needed to be true:
Valid but favorable Pyth updates had to remain consumable by Levana long enough for the attacker to choose among them.
Levana had to let traders submit oracle updates as part of the same execution path that opened and closed positions.
Market activity or bot activity had to be sparse enough, or made sparse enough, that a fresher price would not reliably preempt the attacker’s selected update.
Enough leverage and liquidity had to remain available that repeated deterministic edge on small price deltas could compound into material LP losses.
Technical anatomy worth remembering:
This is not a fake price feed incident. Pyth behaved as designed; the exploitable object was publication timing and Levana’s willingness to treat a merely valid recent price as execution truth.
Range’s reduction of the attack to four messages is the cleanest mental model: update_price_feeds -> open_position -> update_price_feeds -> close_position.
The exploit sits on the boundary between oracle manipulation and stale-price exploitation. The attacker did not need to print a fake market price; they needed to choose when real prices became protocol-visible and stop others from making fresher truth arrive first.
Levana’s official postmortem highlights an operational multiplier that matters for similar systems: fee-market configuration mismatch across RPC nodes meant Levana’s own infra often used gas prices that some validators would not propagate, making the stale window worse exactly when the protocol most needed aggressive oracle upkeep.
The associated DDoS / ransom pressure against Levana backend services mattered because it further weakened the offchain machinery expected to keep onchain prices fresh.
The long duration matters. This was not a one-block flash exploit; it was a repeated extraction strategy whose profitability increased drastically once network conditions made interruption less likely.
Affected markets and losses reported by Levana:
stATOM_USD: about $241k
ATOM_USD: about $229k
BTC_USD: about $190k
ETH_USD: about $128k
TIA_USD: about $108k
*_USDC markets: about $168k + $82k
Representative contracts and infrastructure:
ATOM-USD Levana market contract cited by Range: osmo1hd7r733w49wrqnxx3daz4gy7kvdhgwsjwn28wj7msjfk4tde89aqjqhu8x
Pyth contract on Osmosis cited by Range: osmo13ge29x4e2s63a8ytz2px8gurtyznmue4a69n5275692v3qn3ks8q7cwck7
Levana and Range both describe the exploit as involving Pyth update_price_feeds calls plus open/close position flow, but the public writeups used here do not pin one canonical transaction hash for the full exploit campaign.
Response / mitigation:
On 2023-12-26, after identifying the exploit mechanics, Levana attempted to push prices every block with high-fee local bots, but congestion and fee-estimation problems kept causing insufficient-fee failures.
The team then moved to pause markets on Osmosis, which itself was slowed by congestion and multisig transaction-broadcast friction.
Levana updated its bot gas-price mechanism and, more importantly, changed protocol design toward deferred execution: orders would sit in a queue and only execute once a fresh Pyth price became available, instead of letting users atomically choose a favorable valid-but-stale price update inside position flow.
Levana also froze opening new positions on Sei and Injective as a precaution while shipping the safer execution model.
Authentic oracle data, attacker-chosen publication timing: the exploiter did not need a false Pyth price, only the ability to decide which still-valid Wormhole / Pyth update Levana would honor next
Same actor could both publish and monetize the mark: update_price_feeds -> open_position -> update_price_feeds -> close_position fused oracle-publication authority and settlement capture into one trader-controlled path
Congestion and backend disruption widened the stale window from nuisance into edge: Osmosis fee-market friction, RPC propagation mismatch, and pressure on Levana’s updater stack made honest refresh less likely exactly when the trade became attractive
The stale state was economically real because newer prices were already known and publishable elsewhere; what lagged was Levana’s own execution truth, not the existence of fresher market information
Why the exploit worked
Levana’s own postmortem and Range’s reconstruction already preserve the decisive boundary: the attacker never had to fabricate a price, only to choose when a real Pyth update became Levana’s live execution mark. That means the useful lesson is not oracle lied; it is authentic update path stayed live while execution semantics lagged behind fresher publishable truth.
The protocol let one trader control both sides of the stale window. Because update_price_feeds sat inside the same operational path as position entry and exit, the attacker could first publish a favorable-but-still-valid mark, take the directional position that benefited from the known gap, then publish the later mark and close.
Congestion mattered because Levana’s security story depended on fresher competing updates landing first often enough to erase this option value. Once Osmosis congestion, RPC fee-policy mismatch, and stress on Levana’s own bots reduced honest update frequency, a bounded 120-second age tolerance became a repeatable extraction surface rather than an occasional inconvenience.
The exploit also shows why oracle is cryptographically authentic and market is safe to settle against this mark right now are separate claims. Levana kept treating validity of a recent VAA as sufficient settlement truth even when the attacker could already see and selectively release newer publishable prices.
The mitigation Levana adopted after the incident confirms the preserved design lesson: queueing orders until a fresh price exists was safer than letting users atomically author publish chosen old mark and capture resulting PnL in one flow.
Detection and audit pivots
Inventory every place the protocol can lose freshness without losing authenticity: relayer delays, bot outages, fee-estimation mismatches, validator mempool policy changes, congestion, RPC/provider divergence, and any same-path design where traders themselves may choose when a valid update lands.
Ask whether a trader can both publish the next oracle state and settle immediately against it. If yes, the relevant risk question is not only is the price valid? but what prevents selective publication of one still-valid mark followed by immediate profit capture before fresher truth lands?
Monitor the gap between newest externally observable / publishable oracle update and newest update actually recorded onchain by the protocol, especially during congestion. Levana shows that this lag is a balance-sheet variable, not just an infra metric.
Treat sustained asymmetric trader PnL during oracle-delay periods as a liveness alarm. Repeated update -> open -> update -> close profit patterns, especially during chain stress, are evidence that publication timing has become settlement authority.
Review degraded-mode policy for pull-based or user-publishable oracle systems: when freshness degrades, which rights narrow first — fresh position opens, leverage increases, settlement size, or only bot behavior? If the answer is none, the stale window is still a monetizable product feature for attackers.
Failure-prevention checklist
Separate oracle publication from trade settlement whenever users can permissionlessly submit valid external updates. If the same caller can choose the next accepted update_price_feeds payload and immediately open or close against it, the venue has already handed that caller timing authority over settlement truth.
Bind every market to an explicit degraded-mode ladder tied to freshness lag: as soon as the gap between latest publishable VAA and latest market-recorded price exceeds the venue’s safe budget, disable fresh position opens and leverage increases first instead of waiting for a full market pause.
Define one execution-freshness contract per market and prove infra can satisfy it under stress. Levana’s age_tolerance_seconds = 120 only helped if bots, RPCs, fee policy, and validators could reliably land fresh updates inside that window during congestion.
Use deferred execution or equivalent queueing whenever the protocol cannot guarantee that the price-setting transaction and the profit-taking transaction are meaningfully decoupled. Order waits for a fresh mark or times out is safer than user chooses when a merely valid mark becomes executable truth.
Prefer oracle values whose short-horizon publication timing is less monetizable on the venue’s exact product surface. If a spot / non-EMA mark plus high leverage plus same-path submission gives attackers deterministic edge on short lags, the venue should either smooth the mark, narrow permissions, or queue execution.
Prebuild liveness runbooks around chain congestion and fee-policy divergence: alternate RPCs, explicit gas-floor overrides, high-fee updater lanes, and the exact guardian / multisig path needed to freeze new risk should already exist before stale-state trading begins.
Instrument anomaly detection around update_price_feeds -> open_position -> update_price_feeds -> close_position, repeated directional wins immediately after user-submitted price updates, and large sustained gaps in crank / oracle-update cadence.
Review backend exposure as part of oracle security whenever keeper or bot freshness is a safety assumption. If DDoS or infrastructure enumeration can selectively suppress honest refreshes, that is part of the live execution-truth boundary, not an unrelated ops problem.
Cap market-level extractable value during stale states. Position limits, delta-neutrality limits, per-market exposure ceilings, and queue throttles should assume freshness can fail exactly when volatility is highest.
Audit prompts
Can a trader both choose the next accepted oracle publication and settle against it in the same logical workflow, or has the venue introduced a real time / queue boundary between publish and monetize?
What exact telemetry measures latest publishable external update minus latest update this market has actually recorded, who sees that lag live, and what automatic permissions narrow when it breaches threshold?
Which market actions shut off first when freshness weakens: new positions, leverage increases, collateral top-ups, closes, liquidations, or only background bot retries?
What evidence shows the venue’s updater bots and RPC path can still meet the market’s freshness budget during validator fee-policy divergence, mempool stress, or partial backend outage?
If honest users and bots disappear for ten minutes during volatility, can one address repeatedly run update -> open -> update -> close with positive expectancy, and what exact control stops that loop before LPs absorb it?
Does the protocol rely on a spot / non-EMA price where short-horizon timing edge is directly monetizable? If yes, what compensating control prevents publication timing from becoming a trading primitive?
If congestion or DDoS hits the updater stack and governance pause path simultaneously, what is the smallest still-available action that prevents fresh risk creation onchain?
Are anomaly detectors tuned to economic liveness abuse rather than only code-level exploits: repeated small deterministic wins, sharp divergence between protocol price age and external price age, and suspicious suppression of competing oracle updates?
Where is the boundary between users may still exit safely and users may still create new oracle-dependent risk, and can the venue enforce that boundary without first restoring perfect infra conditions?
Lessons that should already be standard
Authentic oracle data is not enough. If attackers can decide which valid update becomes the venue’s live mark next, publication timing itself has become a monetizable oracle surface.
Price age tolerance is not a safety parameter by itself. It only means something if network conditions, fee policy, and updater infrastructure can still keep the venue near the frontier of publishable truth under stress.
Degraded mode should narrow authority before it pauses everything. A venue that waits for total halt before disabling fresh risk creation has already left attackers a stale-state profit window.
Pull-based oracle freshness is a custody boundary for perps, not just a UX detail. Whoever can delay or sequence updates can partially author realized PnL.
Backend and mempool assumptions belong in the protocol threat model when those systems are expected to keep settlement marks fresh. A DDoS or fee-propagation mismatch can be economically equivalent to weakening the oracle itself.
The healthy design move is often queue first, settle later. Levana’s post-incident direction is a good reminder that forcing orders to await a fresh mark is sometimes the cleanest way to stop publish chosen stale truth and capture it immediately.
Why this incident matters
Levana is a strong exemplar of oracle truth depends on liveness, not just authenticity. A cryptographically valid oracle update can still be the wrong solvency object if the attacker chooses when it becomes live.
It is also a good reminder that offchain bot infrastructure, RPC fee-policy assumptions, and chain congestion are part of DeFi protocol security when those systems are expected to keep price state fresh.
The incident preserves a useful distinction from classic spot-price oracle attacks: the attacker did not mainly move a shallow AMM to invent a price; they harvested optionality around real Pyth price updates and then widened that optionality by degrading competing execution.
It is one of the cleaner Cosmos examples where smart-contract design, network fee-market behavior, and backend service resilience all had to fail together before the losses became large.
Positive-design companion: oracle-independence-inventory-and-degraded-mode-discipline — the healthier-side question is what Levana should have done once authentic Pyth updates were still available but operational independence and timely publication were no longer strong enough to justify full settlement authority.
Positive-design timing companion: delayed-snapshots-and-same-block-quarantine — not because Levana was a read-only-reentrancy case, but because the post-incident move toward deferred execution preserves the same deeper lesson that latest observable update and safe executable settlement truth may need a deliberate time boundary between them.
The decisive leverage sat in oracle publication timing, age tolerance, execution queuing, offchain updater resilience, fee-market assumptions, and whether the protocol let the same actor both submit the price update and capture the resulting trading edge.
Levana’s mistake was not merely using Pyth. It was allowing who gets the next valid update onchain, and when to become a profitable balance-sheet authority surface.