skip to content

Ostium Left an Opening for Exploiters and $24m Went Out the Door

General-ChartGraph-3 Black

This article originally appeared in Galaxy Research's weekly newsletter. Subscribe to get the most timely insights delivered to your inbox every Friday morning.

Thieves made off with an estimated $23.75 million worth of the USDC stablecoin Wednesday after exploiting Ostium, a platform for synthetic trading of stocks, commodities, forex, and crypto onchain.

The exploit was carried out over a sequence of eight transactions in which funds left Ostium’s OLP vault:

All eight transactions paid out to the same wallet, 0x321Df1...8bfD9. The largest single payout transaction was executed in a single atomic batch that looped through open-and-close cycles. Every transaction routed through the same contract pair (Ostium: Trading → Ostium: Private PriceUpKeep).

Ostium, which runs on Arbitrum, lets users trade leveraged synthetic positions on forex, commodities, indices, stocks, and crypto. All activity is settled onchain in USDC. Users trade synthetic perpetual contracts that track the prices of underlying assets, and there is no delivery of the underlying or fixed expiries on user trades. The Ostium Liquidity Pool (OLP) is the vault side of all this. Liquidity providers deposit USDC and receive OLP tokens representing their pro-rata share of the pool, which is used to back perpetual positions and to provide liquidity for trader profit and loss (PnL) settlement.

The issue arises from how Ostium's oracle system authorizes price data. The verifier takes a price report, derives the signer from the signature, and checks that the signer is on an authorized list. It simply validates the signer's identity, not whether the price itself is accurate. An attacker who held both an authorized oracle-signer key and a registered PriceUpKeep forwarder (the keeper role responsible for fulfilling pending orders) used that combination to submit a future-dated, correctly signed price report and then repeatedly opened and closed positions against it. This allowed them to appear to generate trading profits from the view of the system without any real market exposure. Both the signer and forwarder roles are meant to be granted only by Ostium governance/timelock and are not supposed to be self-assignable; the exploit worked because the attacker obtained legitimate credentials for each, not because of a flaw in Ostium’s trading logic itself.

OUR TAKE

The Ostium incident is one of a number of major application exploits that have happened this year, including at Drift and KelpDAO’s rsETH. A common theme has been that smart contracts and the logic they contain have held up, and the main targets for exploiters have been operational infrastructure and human trust (the compromised signer credentials in Ostium's case, the socially engineered pre-signed admin takeover in Drift's case, and the poisoned RPC infrastructure behind KelpDAO's rsETH bridge).

After each of these high-profile exploits, some have called for safeguards around user funds on applications, such as throttled withdrawals, to disincentivize nefarious actors and limit the loss of funds in the event an exploit occurs. These proposals should be resisted.

Throttling withdrawals introduces censorship risk directly at the application layer. The moment a protocol can unilaterally delay or cap what a user can deposit or withdraw, self-custody becomes conditional instead of absolute. In this case, the app, not the user, decides when funds are accessible and how they can be used. It also collapses the distinction between the exploiter and the average user in the sense that a safeguard designed to slow down an attacker necessarily applies to everyone using the app at that moment. By design, apps would start treating ordinary users as suspects, with no way to distinguish intent in real time.

The slippery slope risk compounds this. Once a protocol builds in the technical capability to throttle or freeze deposits and withdrawals, that capability becomes precedent. Regulators can point to it as evidence that these applications already have the tool to comply with freeze orders, KYC gating, or other requirements and should therefore be required too. A safeguard built to stop attackers can become a hook that pulls a protocol toward obligations they would otherwise be incapable of meeting.

Moreover, innocent market actors will become incentivized to route around the frictions introduced by such measures. In this case, risk can become displaced rather than contained. Users locked behind a throttle will look for a way to exit their economic exposure anyway, which typically means a tradeable claim on the delayed deposit emerges to fill the gap (such as a receipt token, an IOU, a wrapped stand-in for "your funds, pending release"). That claim becomes a new dependency with its own risk surface at both the market level (a peg that can break, a discount that widens under panic) and the technical level (a new contract, a new oracle, a new thing that can be exploited independently of the application it's supposed to represent). The safeguard meant to contain one point of failure ends up compounding the very fragility it was built to prevent.

None of this means protocols shouldn’t harden the parts of the stack that actually failed here (e.g. signer key management, verifier redundancy, admin timelocks, social-engineering awareness). But the fix for weaknesses in operational infrastructure and human trust is hardening those things, not adding new discretionary controls over user funds that undermine the core value proposition of the thing being protected.

You are leaving Galaxy.com

You are leaving the Galaxy website and being directed to an external third-party website that we think might be of interest to you. Third-party websites are not under the control of Galaxy, and Galaxy is not responsible for the accuracy or completeness of the contents or the proper operation of any linked site. Please note the security and privacy policies on third-party websites differ from Galaxy policies, please read third-party privacy and security policies closely. If you do not wish to continue to the third-party site, click “Cancel”. The inclusion of any linked website does not imply Galaxy’s endorsement or adoption of the statements therein and is only provided for your convenience.