Ostium Hack: $24M Oracle Exploit, Fund Movements, and AML Crypto Analysis

A detailed breakdown of the $24 million Ostium exploit: how the attacker manipulated the price oracle, where the stolen funds moved, why Tornado Cash was used, and what AML Crypto’s blockchain analysis revealed.
Get advice from AML Crypto experts
On July 15, 2026, Ostium—a decentralized protocol on Arbitrum for trading perpetual contracts on cryptocurrencies and traditional assets — was attacked. The target was not the user interface or individual traders’ wallets, but the public OLP Vault, a liquidity pool where capital providers deposited USDC. This vault serves as Ostium’s settlement layer: it is the source from which the protocol pays out traders’ profits when successful positions are closed.

According to Ostium co-founder Caledora, the incident occurred within a brief window, between 14:18 and 14:23 UTC. The team detected the issue within minutes and began pausing the trading contracts. All trading activity on the platform was suspended while the investigation was underway.

The AML Crypto team reconstructed the movement of the stolen funds using the Bholder tool:

What Exactly Happened

The attacker tricked Ostium’s system into believing that their trades had generated enormous profits. To do this, they used a registered PriceUpKeep Forwarder component to submit authorized but manipulated oracle price reports to the protocol, some of which contained timestamps from the future. Because the reports carried a valid signature and were delivered through a trusted forwarder, Ostium’s contracts accepted the reported prices as genuine.

In simplified terms, the attack worked as follows:
The attacker opened a trading position at the normal market price.
They then used the trusted infrastructure to submit a false price report indicating that the market had moved sharply in their favor.
The position was immediately closed with a massive artificial profit.
The smart contracts automatically paid out this “profit” in USDC from the OLP Vault.
The cycle was repeated several times, with the proceeds used to open increasingly larger positions.

Analyst Notes

1
Transfer of Funds from Arbitrum to Ethereum via the MetaMask Bridge Route
  • Observation
    After withdrawing the funds, the attacker began transferring assets from Arbitrum—the network on which the exploit occurred—to Ethereum. Some of the transactions used a route associated with MetaMask Bridge.
  • Analytical rationale
    The move to Ethereum was likely necessary to facilitate further asset swaps and transfers to Tornado Cash. Ethereum’s deeper liquidity makes it easier to convert large amounts and subsequently obscure the transaction trail.

    On-chain data confirms that the relevant bridge route was used. However, this alone does not prove that the attacker interacted directly with the MetaMask web interface. The transactions could have been created through the interface, via a third-party aggregator, or programmatically.

    If the official MetaMask Bridge interface was used, the service operator may retain technical data such as access timestamps, IP addresses, browser parameters, session identifiers, and other access logs, subject to the applicable data-retention policy.
  • Preliminary conclusion
    MetaMask and the bridge providers involved are potential sources of off-chain information that could help link the on-chain addresses to a specific user session.
  • Recommended next steps
    Необходимо как можно быстрее направить запрос на сохранение данных — preservation request. В запрос следует включить адреса, хеши транзакций и точные временные интервалы в UTC.

    Related addresses:
    0x3147a355D55755a30e0f2b86b15429ba1f5E191f
    0x541444685D56E37E2f6fbF95954910840f73f437
    0x647cb46a7aD236c259b6B81673F0cD50a5dC302a
    0x6d4095b62ef79CfeB6CaA28ac793659EE2aE94cB
    0xEa50Bacf90373ACb58f3e81A39576bAdd7FeB051
    0x13637946BB242C9532A310a40c2C1C7B9F2A7E95
    0xacE0536f2B00514b17b437110cbbe587F4b965F6
    0x6A755a2779E4e372909ccE7fDf0f7E765856af9a
    0x7646d24C3E17643DE75D276ed53Be36B88BDe7A6
    0xBf85676D35918cF2b793061958df81A5973538fe
    0x23A474365c47ad782a31477B2D77739d0ea27DbB
2
Three Temporary Holding Addresses Identified
  • Observation
    At the time of the analysis, three addresses had been identified where the funds remained stationary, with no subsequent movement:

    0x5209536357034c39E172161501761681aE170873
    0x43e62b876FB511E7Fc6654aEDD4b9c292D5Ccf60
    0xE494eEd9200385A39DC4038438171051984f518f
  • Analytical rationale
    These addresses may be serving as temporary holding wallets before the next stage of the laundering process. However, their purpose has not yet been established. They could be:
    • ordinary self-custodial wallets controlled by the attacker;
    • accumulation addresses used before funds are sent to a mixer;
    • deposit addresses belonging to an exchange or swap service;
    • intermediary bridge addresses;
    • addresses controlled by an over-the-counter intermediary.

    The absence of outgoing transactions creates a temporary window during which investigators may be able to determine who controls the addresses and notify the relevant service in advance.
  • Preliminary conclusion
    These three addresses should be treated as priority monitoring points because the funds have not yet moved and the likelihood of an effective operational response remains relatively high.
  • Recommended next steps
    Continuous, 24/7 alerts should be configured for all outgoing transactions, including token transfers, approvals, interactions with bridges, and calls to unidentified contracts. At the same time, investigators should review gas-funding history, first-hop counterparties, and any potential links to addresses associated with known exchanges.

    If any of the addresses is identified as a deposit address belonging to a centralized service, the service should immediately be provided with an indicators package containing the relevant addresses, transaction hashes, source-of-funds information, timestamps, and the grounds for freezing the assets or preserving associated data.
3
Deposits into Tornado Cash
  • Observation
    A significant portion of the funds was distributed across Tornado Cash pools with fixed denominations.
  • The attacker made no deposits into the 0.1 ETH pool. Most of the funds were directed to the 100 ETH pool.
  • Analytical rationale
    The use of larger denominations is consistent with the objective of rapidly concealing a substantial volume of funds. Using the 100 ETH pool reduces both the number of required transactions and the associated operational costs.

    Once funds enter Tornado Cash, directly matching a specific deposit to a specific withdrawal becomes significantly more difficult. The analysis should consider not only transaction amounts and timing, but also:
    • the source of funds used to pay gas fees;
    • the relayer operators used;
    • the time elapsed between deposits and potential withdrawals;
    • the reuse of recipient addresses;
    • subsequent transfers to exchanges, bridges, and swap services;
    • similarities in behavior across different addresses.
  • Preliminary conclusion
    The large number of deposits provides a substantial dataset for correlation analysis. However, the reliability of the findings will depend on the emergence of subsequent withdrawals. A longer observation period may reveal more overlaps and behavioral patterns, although simple temporal correlation may become less reliable over time.
Want to learn more and get expert advice? Leave your email and we will contact you promptly!
We also recommend