How a Two-Week Oracle Delay Exploit Quietly Drained Levana Protocol of $1.1M

Perpetuals platform Levana Protocol lost more than $1.1 million — roughly 10% of its total liquidity — to an oracle-manipulation campaign that ran for nearly two weeks before anyone at the project noticed.

A disclosure posted on Wednesday revealed that the bulk of the damage only became visible once congestion on the Osmosis network pushed gas prices higher, which in turn made the exploit dramatically more lucrative for the attacker. That sudden jump in losses is what finally tipped off the team, prompting them to halt the protocol.

Per Levana's own account of the timeline: the exploit had actually begun 14 days earlier, and across the first 12 days the attacker had quietly siphoned off close to 4% of the protocol's liquidity pools. At the time, that shift in PnL was chalked up to legitimate trader gains and imperfect cash-and-carry dynamics in Levana's thinner markets. It wasn't until the following day, when Osmosis congestion spiked, that the attack accelerated sharply — draining an additional 5% or so from the pools before the team locked out new position openings.

In other words, absent that spike in network traffic, the drain might have continued unnoticed for far longer.

Credit for piecing together the mechanics goes to Levana's own writeup and to independent analysis from Carter L. Woetzel. According to Levana's post-mortem, the campaign started on December 13 and escalated substantially by December 26.

At its core, the exploit abused the brief lag — a price "delta" — between oracle price updates, using that window to place trades guaranteed to win in what the post-mortem calls "volatile markets with high leverage."

The mechanism itself is straightforward, but only makes sense with the right context. Levana's oracle refreshes whenever a regular user trade occurs, and additionally every 90 seconds via an off-chain update bot. By carefully timing their moves — and by making sure no other transaction could slip in ahead of them — the attacker was able to carve out a recurring window of opportunity.

During the exploit's opening phase, gains were modest, since success depended on a fairly narrow set of conditions lining up: a sufficiently large price delta appearing within that 90-second oracle cycle, combined with a total absence of competing trades or bot activity in that same window.

The second and far more damaging phase coincided with a period of Osmosis network congestion — though it's still unclear whether that congestion arose naturally or was deliberately triggered to serve the attack. Either way, the congestion created many more opportunities for the attacker to fire off pre-loaded, guaranteed-profit trades, since ordinary user transactions were effectively locked out. As the post-mortem describes it, a flaw in Osmosis's fee-market mechanism meant that during congested periods, the gas price being offered was often too low for either regular trades or the bot's routine maintenance to actually land on-chain.

Compounding matters, Levana was simultaneously fending off a sustained DDoS attack for most of the exploit's duration, which further limited the team's ability to react.

The affected markets and their individual losses, totaling $1.146 million, broke down as follows:

stATOM_USD: $241k

ATOM_USD: $229k

BTC_USD: $190k

ETH_USD: $128k

TIA_USD: $108k

*_USDC: $168k + $82k

Carter L. Woetzel's breakdown of the attacker's playbook lays out the sequence in five parts:

1. Flood the network with spam transactions so that no oracle-update transaction — from either ordinary users or Levana's own infrastructure — can get processed.

2. Simultaneously DDoS the backend systems responsible for the scheduled oracle updates.

3. Run a monitoring system capable of tracking the growing delta between the stale on-chain price and the real, current market price, ready to act the moment it's favorable.

4. Bundle a long or short position together with the oracle update itself inside a single multiexecute transaction — since the attacker already knows exactly what price the stale oracle is about to be refreshed to, this guarantees a profitable, directionally-correct trade.

5. Because the attacker was themselves the source of the congestion, they had precise knowledge of which transactions the network nodes would actually accept, letting them time their submissions accordingly.

Levana had previously undergone audits from both FYEO and Peckshield earlier in 2023, but vulnerabilities contingent on external conditions like network congestion evidently fell outside the scope of either review.

To make affected users whole, Levana intends to draw on protocol fees along with a planned airdrop of LVN tokens. The team is also introducing a transaction-queuing mechanism that will require a freshly updated oracle price before any new position can be opened.

Even in a space built around autonomous, code-driven systems, no protocol operates in true isolation. This incident is a reminder that dependencies on external oracles and the underlying chain's fee mechanics need continuous scrutiny and fine-tuning to keep a product running safely — a point made sharper by the current wave of inscription activity clogging networks across the ecosystem, which could easily hand similarly-minded attackers new openings elsewhere.

Given how many moving parts were involved here — network-level congestion, protocol-level trading logic, off-chain bot behavior, and a concurrent DDoS attack used as cover — it's worth asking whether Levana was simply unlucky, or whether this incident is an early sign of more sophisticated, timing-sensitive exploits to come.