Ostium Labs

Introduction

Ostium is the first decentralized perpetuals exchange purpose-built for trading Real World Assets (RWAs). It introduces synthetic leveraged trading on assets like oil, natural gas, and soybeans via a stablecoin-settled engine, proprietary oracles, and a dynamically tuned fee structure.

Why Did They Need an Audit?

Ostium’s core contracts—vaults, trading storage, callbacks, oracles, and upkeep logic—coordinate high-value synthetic trades and price feeds. Improper logic around position management, liquidation, funding rate accounting, or vault access could expose the protocol to bad debt, oracle abuse, or user fund loss. Ostium engaged Three Sigma for a 10-person-week deep dive to secure its upcoming mainnet launch on Arbitrum.

Scope of the Engagement

Results and Findings

Key Critical Issue

Index collision in trading storage

• Description: If no open trade or limit slot is available, firstEmptyTradeIndex() and firstEmptyOpenLimitIndex() returned index 0, overwriting live trades in storeTrade(). A malicious sequence—Gov reducing maxTradesPerPair before a callback—could silently overwrite a live position, risking data loss or arbitrage.
• Resolution: Now reverts if no valid slot is found instead of defaulting to zero.

Notable High-Severity Issues

Funding fee calculation mismatch

• Description: When transitioning funding rates (e.g. from -5000 to +1000), getPendingAccFundingFees() misused absLastFundingRate instead of absNewFundingRate for square area calculation, violating the protocol’s defined integral logic.
• Resolution: Adjusted calculation to properly follow defined velocity-based update model.

Stop-loss timeout circumvents liquidation

• Description: Users could update their SL before the timeout expired, avoiding liquidation indefinitely. Due to internal constraints, SL-triggered limit orders would not fire if inside the cooldown.
• Resolution: Liquidation flow now bypasses SL timeouts when a trade is liquidatable.

Notable Medium-Severity Issues

Liquidation blocked for blacklisted USDC addresses

• Description: If a user was blacklisted by USDC (even with a 0-value transfer), their liquidation or trade closure would revert. This introduced bad debt risk.
• Resolution: Recommended pull-over-push model or blacklist check at loan origination. Acknowledged by the team.

Exposure bypass on top-up

• Description: topUpCollateral() skipped the groupMaxCollateral enforcement that is present during initial position opens, allowing users to exceed risk thresholds.
• Resolution: Check added to match open trade logic.

Frontrun protection missing on collateral/top-up flows

• Description: Trades could be topped up or closed after a liquidation trigger was already set, blocking the upkeep from executing and gaming the system.
• Resolution: Added checkNoPendingTrigger() to relevant functions.

Potential protocol griefing from unpaid oracle fees

• Description: Oracle fees were paid after trade finalization. In edge cases (timeout + upkeep execution), trades could revert while the protocol still incurred fees.
• Resolution: Suggested paying oracle fees upfront. Team acknowledged.

In conclusion

Three Sigma conducted a 10-person-week audit of Ostium’s 3,896 nSLOC codebase, covering perpetuals logic, funding fee flows, liquidation triggers, and oracle upkeeps. The review uncovered a critical overwrite issue, two high-severity economic flaws, and a broad surface of medium-level logic gaps and gas optimizations. With nearly all issues addressed and a few acknowledged for roadmap resolution, Ostium now enters launch with stronger guarantees around trade safety, funding accuracy, and onchain liquidations.