Ostium, an on-chain perpetuals trading platform, lost millions in a five-minute exploit on July 15 after attackers manipulated price oracles through a registered forwarder. The incident, which hit the platform’s public liquidity vault (OLP) between 14:18 and 14:23 UTC, saw unauthorized reports with future-dated prices create artificial trading profits that drained the vault.
The exploit method
Security firms tracking the incident said the attackers used a PriceUpKeep forwarder — a registered contract for updating prices — to submit authorized oracle reports that had deliberately future-dated prices. The platform’s OstiumVerifier code, which recovers an ECDSA signer and checks authorization, didn’t enforce price-plausibility tests or timestamp bounds. That allowed the fabricated reports to pass validation and generate profits that shouldn’t have existed.
Ostium co-founder Kaledora Kiernan-Linn confirmed the team spotted the attack within minutes and coordinated a trading pause before the hour ended. But by then, the damage was done.
Discrepancies in loss estimates
Multiple security firms provided different loss figures, highlighting the difficulty of pinning down a single number in a complex DeFi exploit. Blockaid estimated around $18 million, Cyvers put the figure at $23.7 million, and PeckShield reported roughly $24 million. SlowMist tracked a single USDC outflow of 11,862,444.782, which would equate to about $11.86 million — suggesting the attacker may have tapped multiple assets or that the firms’ methodologies varied.
PeckShield noted that the extracted USDC was swapped into 12,080 ETH, of which 10,540 ETH was sent to Tornado Cash, a mixer often used to obfuscate fund trails. The remaining 1,540 ETH hasn’t been moved yet.
Ongoing investigation and next steps
Ostium’s statement didn’t provide a definitive loss total, root cause, or final postmortem. The team said it’s working with law enforcement, SEAL 911, and third-party security specialists. Key questions remain: Was a signer key compromised? Did an authorized operator act maliciously? Or was another privileged path abused? The incident is distinct from the Bonzo Lend exploit on Hedera, where the verifier accepted a proof with no valid signature at all. In Ostium’s case, the signer path was authorized — the data just wasn’t safe.
The platform still needs to determine exactly how the attackers gained access to the authorized forwarder and whether the vulnerability was an isolated code flaw or a symptom of a broader security gap. Until the investigation concludes, the full scope of the losses — and the lessons for other projects using similar oracle setups — won’t be clear.
