OAK — OnChain Attack Knowledge

Worked example · 2026-07

Ostium — an authorised price-report path settles a BTC long opened at $5,000 and closed at ~$60,000 in one transaction, draining the OLP vault — Ostium (Arbitrum) — 2026-07-15

Loss
~$11.86M USDC confirmed in the primary transaction (~1,000 USDC deposited, ~$11.86M withdrawn), with additional unquantified extraction in sibling batches across roughly 20 trading loops between 14:18 and 14:23 UTC. Blockaid put the drain at about $18M, roughly 28% of Ostium's $63M TVL; later on-chain analysis circulated figures up to ~$23.7M. OAK records the ~$11.86M single-transaction figure as the confirmed floor and the $18M–$23.7M range as reported-but-unreconciled, because Ostium has published no final loss accounting.
OAK Techniques observed
OAK-T9.001 (Oracle Price Manipulation — primary; the outcome is confirmed, the authorisation path is not. Ostium uses a pull-based oracle in which signed price reports are delivered on-chain at trade execution. The attacker was able to submit price reports that the protocol accepted, and therefore settled their own trades at prices they chose: a Bitcoin long (pairIndex 0) opened at exactly $5,000 and closed at ~$60,000 inside a single atomic transaction, repeated across ~20 loops through a registered PriceUpKeep forwarder using delegated actions. This sits in T9.001's reporter-pull sub-shape, alongside BonqDAO, with the distinction that no dispute window had to be outlasted — the reports were accepted as authorised on submission. See techniques/T9.001-oracle-price-manipulation.md).
Attribution
pseudonymous. No named individual or group, and — unusually — no established mechanism, which leaves open a possibility the protocol itself has not excluded: that an authorised operator acted maliciously rather than an external attacker compromising a key. Public reporting discloses partial on-chain identifiers only: transaction sender 0xD1794196…85869, entry contract 0xfE12F636…5bd2E, and a fresh receiving EOA with no prior history, 0x321df194…bfd9 (partial forms are what sources published; OAK has not independently resolved them). Within a few hours the receiving wallet held no USDC — only ~99.6 ETH and spoofed token airdrops — and public analysis did not trace onward movement, so whether the proceeds were swapped, split, or bridged off Arbitrum is not documented. Nothing links the operator to a tracked OAK actor.
Key teaching point
If the entity that reports the price is also the counterparty to the trade, the price feed is not an oracle — it is a withdrawal function. Whatever produced the authorisation (a stolen signer key, a rogue operator, a gap in how reports were checked), the outcome was identical and it is the outcome that carries the lesson: whoever could sign a price report got to name the number that settled their own position, and the protocol had nothing left to say. Three independent controls would each have blunted it, and Ostium had none of them. Bounds on settlement-price deviation from the previous accepted value: Bitcoin does not move twelvefold inside one atomic transaction, and a deviation breaker rejects that regardless of how well-signed the report is. Freshness/timestamp validation: the reports were future-dated, and a report claiming a price from the future should never settle. Per-block and per-account vault payout caps: ~1,000 USDC in and ~$11.86M out is a ratio that no legitimate position produces, and a cap turns a total drain into a bounded, observable one. The audit-scope finding compounds all three — Zellic's 2024 review explicitly put key custody and infrastructure out of scope, and the September 2025 audits covered the trading engines but not OstiumPrivatePriceUpKeep. The component that failed had never been in anyone's scope.

How the attacker obtained the authorised path is not publicly established. Blockaid reported that the attacker gained control of an oracle signer private key, which would additionally implicate the OAK-T11 custody/signing family. Ostium itself has stated it has not determined whether a signer key was compromised, an authorised operator acted maliciously, or another privileged path was abused. OAK therefore maps only T9.001 and does not assert a key-compromise technique. This mapping should be revisited when a post-mortem lands; contributors updating it should add the custody-side technique only against a confirmed source.

Summary

Ostium is a decentralised perpetuals exchange for real-world assets on Arbitrum, offering leveraged exposure across about 75 pairs spanning stocks, ETFs, commodities, and crypto. Liquidity is provided by the public Ostium Liquidity Provider (OLP) vault, which is the counterparty to trader P&L. Pricing uses a pull-based oracle: signed price reports are delivered on-chain at the moment a trade executes, rather than a feed being continuously maintained.

On 2026-07-15, beginning at 14:18:48 UTC, an attacker submitted price reports that Ostium's verification accepted, using a registered PriceUpKeep forwarder and delegated actions to open and close positions against prices of their own choosing. The canonical loop: open a Bitcoin long (pairIndex 0) at exactly $5,000, close it at ~$60,000, both inside one atomic transaction. The primary transaction deposited about 1,000 USDC and withdrew about $11.86M USDC. The pattern repeated across roughly 20 loops and finished by 14:23 UTC — a five-minute event.

The fabrication was not subtle and required no market: Bitcoin does not move twelvefold within a single transaction, and the prices are plainly readable in the trade events. What was missing was any control that would object — no deviation bound against the previous accepted price, no effective freshness validation (the reports were future-dated), and no per-block or per-account cap on what the vault could pay out.

Ostium identified the incident within minutes and coordinated a trading pause within the hour, stating that all trader funds and open positions were preserved as-is and that funds in the trading storage contract were paused. Blockaid assessed the drain at roughly $18M, about 28% of the protocol's $63M TVL; subsequent analysis circulated figures approaching $23.7M. Proceeds moved quickly: within a few hours the receiving wallet held no USDC, only ~99.6 ETH.

As of 2026-07-17, Ostium has published no post-mortem, no final loss accounting, and no root cause, and has not indicated a timeline for resuming trading. It has stated it is still working out whether a signer key was compromised, an authorised operator acted maliciously, or another privileged path was abused.

Timeline (UTC)

When Event OAK ref
2024 Zellic audit reviews Ostium; key custody and infrastructure explicitly out of scope (audit-scope gap)
2025-09 Further audits cover the trading engines but not OstiumPrivatePriceUpKeep (audit-scope gap)
2026-07-15 14:18:48 First loop: BTC long (pairIndex 0) opened at $5,000 and closed at ~$60,000 in one atomic transaction via a registered PriceUpKeep forwarder; ~1,000 USDC in, ~$11.86M USDC out T9.001
2026-07-15 14:18–14:23 ~20 trading loops repeat the pattern through delegated actions; additional unquantified extraction in sibling batches T9.001
2026-07-15 (within minutes) Ostium identifies the incident (detection)
2026-07-15 (within the hour) Trading paused; trader funds and open positions frozen as-is; trading-storage contract paused M34
2026-07-15 (+ hours) Receiving EOA holds no USDC — ~99.6 ETH and spoofed token airdrops only; onward movement not publicly traced (laundering, undocumented)
2026-07-15 20:32 Blockaid's assessment published: ~$18M, ~28% of $63M TVL (third-party analysis)
2026-07-16 – 07-17 Loss estimates up to ~$23.7M circulate; no Ostium post-mortem, no root cause, no restart timeline (open)

What defenders observed

  • Pre-event (the failed component was never in an audit scope). Zellic's 2024 review put key custody and infrastructure out of scope, and the September 2025 audits covered trading engines but not OstiumPrivatePriceUpKeep. Both scoping decisions are individually defensible and jointly left the price-report path unreviewed. The control is scope reconciliation across audits over time — the question "which of our components has no audit that covered it?" is answerable, and the answer here would have named the component that failed (M16).
  • At-event (no bound on settlement-price deviation). A BTC long opening at $5,000 and closing at $60,000 in one transaction is a twelvefold move that no market produced. A deviation circuit breaker against the previous accepted price rejects that report no matter how validly it is signed, and is the single control that most cleanly closes this incident. It also does not depend on knowing how the attacker got authorised — which matters, because nobody knows yet (M09).
  • At-event (future-dated reports settled). The reports carried timestamps from the future and settled anyway. Freshness validation — a report may not settle a trade at a time that has not happened — is elementary and was either absent or bypassable.
  • At-event (no per-block or per-account payout cap). ~1,000 USDC deposited against ~$11.86M withdrawn, repeated across ~20 loops in five minutes. Vault payout caps convert this from a total drain into a partial, observable one and buy the response window that Ostium's within-the-hour pause could not (M11).
  • At-event (the evidence was in plain sight, with no consumer). The fabricated prices are readable directly in the trade events; no privileged telemetry was needed to see them. As one analysis put it, you do not need anyone's alert to read this. The five-minute execution against a within-the-hour human response is the standard shape — the attacker's timing exploited incident-response lag by design, and the only controls fast enough are automatic ones inside the contract.
  • Response (fast, competent, and too late by construction). Identification within minutes and a pause within the hour is a good operational showing. It protected everything after 14:23 and nothing before it. This is the same pattern as the Summer.fi case in the same month: where extraction is atomic, detection speed is a containment metric, not a prevention one.
  • Open (mechanism unestablished two days on). Ostium has not distinguished between a compromised signer key, a malicious authorised operator, and an abused privileged path. Those imply materially different mitigations — key rotation and HSM/MPC custody, operator separation and multi-party signing, or code-level authorisation fixes — so the absence of a post-mortem is itself the outstanding finding.

Public references

Discussion

Ostium enters OAK as a provisional entry and should be read as one. The outcome is documented well enough to be useful — the trade events are public, the loops are countable, the $11.86M single-transaction floor is solid — but the mechanism that produced the authorisation is unknown, and Ostium says so itself. That is why the mapping carries T9.001 alone. Blockaid's signer-key-compromise assessment is the most likely explanation and would pull in the T11 custody family, but Ostium has not confirmed it and has explicitly left open that an authorised operator acted maliciously, which is a different incident with different mitigations and different attribution. Adding a custody technique on a third-party assessment the protocol has not endorsed would be asserting a mechanism OAK does not have, so the honest entry names the confirmed outcome, records the candidates, and flags itself for revision.

What makes the case worth documenting now, unfinished, is that the three missing controls do not depend on resolving the mechanism. Deviation bounds, freshness validation, and payout caps each independently blunt this drain whether the reports came from a stolen key, a rogue operator, or a verification gap, because all three operate on the content and consequence of the report rather than on its provenance. This is the generalisable point for any protocol where a signed report settles a position: provenance controls (who may sign, is the key safe) protect the reporting path, and they are necessary — but they are single points of failure, and the compensating controls that survive their failure are the ones that ask whether the number is plausible and whether the payout is bounded. Ostium's signing path failed, somehow, and there was nothing behind it.

The audit-scope finding is the part most likely to generalise beyond this protocol. Two reputable review efforts each drew a reasonable boundary — Zellic excluded key custody and infrastructure in 2024; the 2025 work covered the trading engines — and the union of those boundaries left OstiumPrivatePriceUpKeep and the custody surface unexamined. No individual decision was wrong. The gap was that nobody reconciled the scopes against the system as a whole and asked what remained uncovered, which is a question a protocol can answer about itself in an afternoon and which, here, would have pointed directly at the component that broke. Contributors updating this entry when a post-mortem lands should add the custody-side technique against a confirmed source, replace the loss range with final accounting, and preserve the scope-reconciliation lesson regardless of what the root cause turns out to be.

Techniques demonstrated (1)