# Table of Contents

- [Glossary | Ostium Documentation](#glossary-ostium-documentation)
- [Overview | Ostium Documentation](#overview-ostium-documentation)
- [Introduction: Our Thesis | Ostium Documentation](#introduction-our-thesis-ostium-documentation)
- [Holding Trades | Ostium Documentation](#holding-trades-ostium-documentation)
- [Overview | Ostium Documentation](#overview-ostium-documentation)
- [Opening Trades | Ostium Documentation](#opening-trades-ostium-documentation)
- [Closing Trades | Ostium Documentation](#closing-trades-ostium-documentation)
- [Order Types | Ostium Documentation](#order-types-ostium-documentation)
- [Step-By-Step Tutorial | Ostium Documentation](#step-by-step-tutorial-ostium-documentation)
- [Referral Score | Ostium Documentation](#referral-score-ostium-documentation)
- [Market Making Vault | Ostium Documentation](#market-making-vault-ostium-documentation)
- [Overview | Ostium Documentation](#overview-ostium-documentation)
- [Liquidity Buffer | Ostium Documentation](#liquidity-buffer-ostium-documentation)
- [OLP token | Ostium Documentation](#olp-token-ostium-documentation)
- [Risks | Ostium Documentation](#risks-ostium-documentation)
- [Withdraw | Ostium Documentation](#withdraw-ostium-documentation)
- [Automations | Ostium Documentation](#automations-ostium-documentation)
- [Overview | Ostium Documentation](#overview-ostium-documentation)
- [Deposit | Ostium Documentation](#deposit-ostium-documentation)
- [Price Oracle | Ostium Documentation](#price-oracle-ostium-documentation)
- [Smart Contract Audits | Ostium Documentation](#smart-contract-audits-ostium-documentation)
- [API & SDK | Ostium Documentation](#api-sdk-ostium-documentation)
- [Economic Audit | Ostium Documentation](#economic-audit-ostium-documentation)
- [Terms of Use | Ostium Documentation](#terms-of-use-ostium-documentation)
- [Disclaimer | Ostium Documentation](#disclaimer-ostium-documentation)
- [Welcome to Ostium | Ostium Documentation](#welcome-to-ostium-ostium-documentation)

---

# Glossary | Ostium Documentation

*   **Liquidity Providers ("LPs").** Users providing liquidity to the protocol as peer-to-pool market makers and acting as counterparties to traders' net PnL.
    
*   **Open Interest ("OI").** The total cumulative position size across traders allowed for a particular side (long/short) on a particular asset.
    
*   **Open Interest Imbalance ("OI Imbalance")**. The difference between long and short OI.
    
*   **Open Interest Skew ("OI Skew")**. OI skew can either be long (OI long>OI short) or short (OI long<OI short).
    
*   **Ostium Liquidity Provider token ("OLP token")**. An LP's share in the LP Market Making Vault, which accrues rewards directly into the token value.
    
*   **Perpetuals ("Perps").** An onchain primitive enabling price exposure to an asset without underlying ownership thereof. Stated otherwise, a non-expiring future who's cost of holding is governed by a funding rate.
    
*   **Position Size.** The total notional exposure of a trader's position: Collateral x Leverage.
    
*   **Profit and Loss ("PnL")**. Total gains and losses incurred by the position over a specific period. A positive or negative PnL yield a profit or a loss, respectively.
    
*   **Real World Assets ("RWAs").** A catch-all term used by crypto natives to refer to the universe of tradable assets not native to the blockchain.
    
*   **Shared Liquidity Layer ("SLL").** The combined liquidity across both vault structures (buffer and vault) that serves to settle trader PnL and accrues trading fee rewards.
    

[PreviousIntroduction: Our Thesis](/ostium-docs/getting-started/introduction-our-thesis)
[NextOverview](/ostium-docs/ostium-trading-engine/overview)

Last updated 9 months ago

💾

---

# Overview | Ostium Documentation

[PreviousWelcome to Ostium](/ostium-docs)
[NextIntroduction: Our Thesis](/ostium-docs/getting-started/introduction-our-thesis)

Last updated 6 months ago

### 

[](#at-a-high-level-the-ostium-protocol-features)

**At a high level, the Ostium protocol features:**

**Virtual Exposure.** The Ostium Protocol enables onchain price exposure to a suite of Real World Assets, beginning with forex, commodities, indices, and blue-chip crypto assets. Ostium is not a tokenization protocol minting off-chain backed equivalents of non-crypto assets (e.g., ERC-20 tokens representing treasury bonds) but rather an application enabling virtual price exposure, entirely onchain, to these assets. This system is facilitated by the exchange of stablecoins between traders and liquidity providers and the use of high-speed oracles for asset pricing.

**Shared Liquidity Layer & Dual Vault Structure.** A Liquidity Buffer settles trades, accruing value when net trader PnL is negative and depleting in value with net trader PnL is positive. Market Making Vault Liquidity Providers ("LPs") act as counterparties during periods of imbalance in Long and Short trader Open Interest ("OI") and/or depletion in the value of the Liquidity Buffer. In contrast to standard Automated Market Makers, in which LPs take on [Impermanent Loss](https://docs.uniswap.org/contracts/v2/concepts/advanced-topics/understanding-returns)
 risk, LPs in Ostium's liquidity layer provide capital that, under certain circumstances, takes on [temporary](/ostium-docs/shared-liquidity-layer/market-making-vault#temporary-settlement)
 trader PnL risk. Protocol fee structure, however, in particular a non-linear Funding Fee that increases convexly as utilized OI nears its limits (see [here](/ostium-docs/ostium-trading-engine/holding-trades)
), is designed to minimize both the duration and magnitude of LP risk exposure resulting from OI imbalance. LPs are rewarded for this risk through a portion of [trading fees](/ostium-docs/shared-liquidity-layer/market-making-vault/olp-token#rewards)
 accrued from trading activity. Together, these two capital pools (Liquidity Buffer + Market Making Vault) compose a Shared Liquidity Layer ("SLL").

**Oracle Pricing at Position Open.** Pricing at trader position opening is determined via [Ostium's RWA oracle infrastructure](/ostium-docs/supporting-infrastructure/price-oracle)
 (operated by Stork Network) or [Chainlink low-latency oracle feeds](https://blog.chain.link/low-latency-oracle-solution/)
, depending on the asset (RWA vs. crypto). Both feed networks update on a roughly sub-second basis, reporting prices pulled via a combination of sources from the traditional markets for off-chain assets.

**Automations: Liquidations, Stop and Limit Orders.** Asset price tracking required to determine when Liquidations, Stop and Limit orders should be executed, as well as the execution of these transactions themselves, are performed by either [Chainlink Automations](https://docs.chain.link/chainlink-automation/introduction)
 and [Gelato Functions](https://docs.gelato.network/developer-services/web3-functions)
, depending on the asset. In contrast to protocol-run automations, these services allow for more decentralized and reliable execution, as well as more predictable pricing for users.

**Risk-Adjusted Fee Structure.** To capture and minimize the risk an open position poses to the Shared Liquidity Layer (SLL) via directional exposure, traders are subject to variable fees that compound per block.

*   **Funding Fees** vary as a function of the skew or imbalance in OI for a particular asset, which exposes the SLL to counterparty risk. This fee increases non-linearly with imbalance to encourage arbitrageurs to take the more "unpopular" side of a trade.
    
*   **Volatility Fees** vary as a function of the time-weighted recent volatility of the underlying asset, and are charged on a trader's entire position size to reflect the leverage levels of a trader's position. This fee captures the greater risk of future increases in OI imbalance, which scales with asset volatility.
    
*   **Conditional Opening Fees.** To further incentivize closing of Open Interest imbalances, traders are subject to differential opening fees depending on their categorization as virtual makers or takers. Low leverage (1-20x) “counter-trades” that decrease OI imbalance are subject to reduced maker fees; all other trade types (high leverage and/or increasing OI imbalance) are subject to higher taker fees.
    

👁️

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FFYgVfOPOUvNyg7q7SHnQ%252FOstium%2520Deck%25206.png%3Falt%3Dmedia%26token%3Dcd81dda6-74db-4503-a713-f79eff073f22&width=768&dpr=4&quality=100&sign=7d3f346a&sv=2)

---

# Introduction: Our Thesis | Ostium Documentation

### 

[](#a-changing-macro-paradigm)

A Changing Macro Paradigm

*   The pandemic and resulting massive liquidity injection, inflation shock, and aggressive Central Bank interest rate reaction ruptured the market trends of the prior 15 years. Supply chain disruptions, geopolitical uncertainty, and dramatic commodity price shocks further cemented that change. The infinite-money, zero interest rate, large tech stock market hyper-dominance days are over (for now).
    
*   This change has had several important impacts on non-institutional trading activity:
    

1.  Increased awareness and **trading of macro events like interest rate policy, CPI prints, and geopolitical events**, rather than near-exclusive focus on internal asset class or asset-specific dynamics.
    
2.  **Demand for diversification.** From multi-year highs in micro commodity contract volumes to fractionalized fine wines and Private Equity exposure, younger generations in particular are moving away from vanilla 60/40 stock/bond portfolio construction and driving demand for newer alternative asset classes.
    
3.  **More retail trading.** The first wave of market democratization, enabled by no-fee trades and fractional equity ownership on platforms like Robinhood, facilitated a rapid rise in individual stock ownership and trading, turbocharged by liquidity injections pumping asset prices.
    

*   We expect points 2) and 3) to act complementarily going forward, with the next wave of market participation driven on the demand side by appetite for alternative assets and on the supply side by technological advances enabling cheaper, faster, and more fractionalized access to these very assets.
    
*   These trends also appear fractal, mirrored in many ways within the onchain ecosystem. CPI print days consistently see outsized BTC & ETH volumes. There has been a rapid rise in infrastructural support for and onchain TVL into alternative, non-crypto native assets like tokenized Treasurys and gold.
    

### 

[](#on-chain-finance-recent-trends-and-a-return-to-fundamentals)

On-Chain Finance: Recent Trends & a Return to Fundamentals

*   **CEX vs. DEX.** If there's been one major takeaway and positive spillover effect from the 2023 turmoil in the centralized exchange space, it's the return to fundamentals. Our conviction has never been higher in the mandate for the decentralized, programmatic, and permissionless trading that DEXes enable.
    
    *   **Spot.** Price discovery is increasingly happening on DEXes. Swaps volume on Uniswap overtook Coinbase in daily volume in Q1 of 2023.
        
    *   **Perpetuals.** The past year has seen the first signs of this trend echoed in the perpetuals space. Leading perp DEXes have seen continued growth in volumes, with chains like Arbitrum emerging as a laboratory for DeFi innovation with a proliferation of new perpetuals protocols.
        
    
*   **Innovations in Perp DEX Architecture.** The growth in onchain perps has been turbocharged by innovations in both protocol architecture and in the infrastructure these exchanges are powered by (e.g. oracles, chains with improved throughput & transaction costs). While hybrid models are increasingly popular (e.g., Drift), perpetuals DEX models can be grouped into three main categories:
    
    *   **AMM/vAMMs.** At a high level, [AMMs](https://docs.uniswap.org/concepts/uniswap-protocol#order-book-vs-amm)
         use a liquidity pool of two assets valued relative to one another, with the price varying along a pricing curve (e.g., x\*y=k) as assets are traded in the pool. While initially designed for swaps, the model has been adapted to leveraged trading of perpetuals by protocols like Perp Protocol. However, pure AMM models face liquidity [constraints](https://insights.deribit.com/market-research/the-quest-for-perp-amms/)
         for leveraged products that have historically created a natural cap on leverage that can be offered and are best suited to the exchange of ERC-20 tokens representing the underlying assets. Overall, this makes the design less than ideal for Real World Assets that both currently have no tokenized onchain equivalent and are less volatile than most crypto assets and thus typically traded at high leverage levels.
        
    *   **Order Books.** Most traditional markets operate using an [order book](https://www.investopedia.com/terms/o/order-book.asp)
         to match buyers and sellers of an asset. However, few chains currently support the throughput required to conduct large-scale order matching entirely onchain. Due to these infrastructural constraints, the majority of order book-based DEXes conduct order-matching off-chain (e.g. dYdX). Running core components of DEX architecture off-chain both i) creates centralization risk and ii) creates excess reliance on a small number of market makers for good pricing and execution for users.
        
    *   **Pool-based perpetuals.** Much of the recent growth in onchain perpetuals has been driven by innovation in and adoption of this model. Pool-based perps aggregate liquidity, typically into a single pool, in which LPs act as counterparties to trader PnL during periods of imbalance in Open Interest. Pricing at position open is determined via oracles, which feed in spot reference price data, effectively outsourcing price discovery at open to markets with greater liquidity. Compounding fees accrued during the lifetime of a position minimize the risk traders pose to LPs. While this model faces drawbacks – LPs run the risk of directional exposure and oracle pricing under conditions of low reference market liquidity can create the opportunity for negative EV arbitrage – it has many advantages. In particular, pool-based perps i) minimize liquidity fragmentation and ii) have the potential to enable price exposure to off-chain assets with no tokenized onchain equivalent, given pricing is determined entirely via oracles. **To read more about our definition of this model, consult section 1.1 of our research article on pool-based perpetuals DEXes** [**here**](https://www.ostium.io/blog/the-imbalance-score-a-novel-metric-for-rwa-focused-perpetual-dexes)
        **.**
        
    

### 

[](#the-search-for-onchain-diversification)

The Search For Onchain Diversification

*   With the worst depths of the bear market behind us and a rise in institutional acceptance – and adoption – of crypto with recent spot ETF approvals, it's worth reflecting both on 1) what aspects of the stack showed resilience through the bear and 2) what crypto's increasing intertwinement with traditional markets means for the path ahead for DeFi.
    
    *   Stablecoins showed remarkable resilience throughout the bear market, with both increased adoption in emerging economies and a stable market cap during a tumultuous time.
        
    *   While recent focus has been on crypto integration into TradFi (e.g. Bitcoin ETF on Fidelity), we expect integration to grow dramatically in both directions through increased TradFi integration into crypto rails (e.g. stablecoins, tokenized equities). Fulfilling crypto’s promise as a technology will mean using blockchains as a financial settlement layer for [all sorts of assets](https://blog.chain.link/tokenized-real-world-assets/)
         – not just crypto-native assets.
        
    *   In general, this means capital has and will increasingly remain onchain through market cycles, even when token holders de-risk into less volatile assets, propelled by stablecoin adoption, improved crypto UX, and onchain diversification opportunities into un- or less-correlated Real World Assets.
        
    
*   While the direction the space is going is clear, opportunities to diversify onchain into a broader set of assets not native to the blockchain still remain few and far between today.
    
    *   Tokenization has made inroads, particularly in the Treasury space as demand for stable yields has risen through the bear market. Aside from Treasurys, however, asset tokenization remains in its early days as legal and technical tokenization standards remain in flux.
        
    *   Further, a majority of tokenized assets – in particular yield-bearing government bonds – naturally cater to a user base of long-term holders, rather than traders.
        
    *   This is despite the popularity and generally greater prevalence of short-and mid-term trading behavior in crypto through e.g. leveraged perps than in most traditional asset classes. In other words: while crypto trading infrastructure disproportionately serves traders rather than long-term holders, the RWAs currently being onboarded into our ecosystem via tokenization disproportionately serve holders rather than traders.
        
    
*   Thus: **the space for a trader-focused Real World Asset platform is wide open.**
    

### 

[](#enter-ostium)

Enter Ostium

*   The Ostium Protocol is a set of smart contracts enabling onchain price exposure to off-chain Real World Assets via synthetic perps.
    
*   We contend the best way to serve demand today among onchain traders for leveraged, short- and mid-term price exposure to RWAs is via oracle-based perpetuals.
    
*   These can be onboarded onchain directly with fewer upfront logistical hurdles and more nimble technical infrastructure than tokenized assets. RWA perpetuals require a high-fidelity, low-latency oracle price feed for the asset and a liquid exchange venue designed to safely and programmatically support the unique features of most RWAs (e.g., market closures, contract rollovers).
    
*   While at genesis the protocol will only support stablecoin deposits and trading collateral, our vision is to ultimately act as a nexus, uniting the "holder" and "trader" RWA user base by supporting collateral and vault deposits of the tokenized equivalents of listed perpetuals.
    
    *   For instance, the XAU/USD (gold) perpetuals market would support PAXG (Paxos Gold), XAUT (Tether Gold) or equivalent collateral deposits; the XAG/USD (silver) perpetuals market tokenized silver, etc.
        
    

[PreviousOverview](/ostium-docs/getting-started/overview)
[NextGlossary](/ostium-docs/getting-started/glossary)

Last updated 12 months ago

🎯

---

# Holding Trades | Ostium Documentation

[](#dynamic-user-interactions)

**Dynamic User interactions**


-----------------------------------------------------------------

Users can update certain aspects of their open trades:

*   **Update Take Profit:** Traders can update the value of or add a Take Profit order.
    
*   **Update Stop Loss:** Traders can update the value of or add a Stop Loss order.
    
*   **Add Collateral:** Traders can top up collateral on their position to reduce leverage and minimize liquidation risk.
    

In all three cases, no additional fee is charged by the protocol because no price is requested.

[](#monitoring-of-trade-state)

**Monitoring of Trade State**


-----------------------------------------------------------------

*   Ostium uses Gelato Functions to continuously track price changes and determine the need for automated order execution (liquidations, stop losses, take profit orders).
    
*   Trade state simulation runs frequenlty, radically minimizing the risk of would-be liquidations or other automated orders from being executed outside of an acceptable time frame or of bad debt accruing for the liquidity buffer.
    

[](#compounding-fees)

**Compounding Fees**


-----------------------------------------------

During the lifetime of a trade, compounding fees play one of the most important roles in driving the protocol towards equilibrium ([funding fee](/ostium-docs/ostium-trading-engine/holding-trades#funding-fee)
) and mitigating LP directional risk exposure in periods of high volatility ([volatility fee](/ostium-docs/ostium-trading-engine/holding-trades#volatility-fee)
).

### 

[](#funding-fee)

**Funding Fee**

Captures the externality of changes in Open Interest skew. This is a zero-sum fee that compounds per block, is charged synthetically on the entire position value of the “popular” side, and injected into the PnL of the “unpopular” side (e.g. if the OI skew is long, the long side "popular" pays to the short side "unpopular"). Fee payments cannot be "claimed" as on centralized exchanges but rather are injected into calculations of a trader's returns and thus realized at position close, amplifying or reducing PnL.

_The funding fee focuses on closing the gap between long and short Open Interest, driving the protocol towards an equilibrium and minimizing delta risk for the vault._

We designed our funding fee to be gas-efficient (hyperbolic rather than exponential function) as well as velocity-based. Without such a velocity parameter, arbitrageurs would never be incentivized to fully close imbalances, as an imbalance of zero would also lead to result in a fee of zero. Instead, this funding fee model accounts for both the length and magnitude of prior imbalances, compensating arbitrage behavior longer and more strongly if the negative externality from a prior state was greater.

The formula is expressed as the velocity of change, which is constant between orders, of the funding fee. The funding fee is applied to the side with a positive skew and expressed as a percentage per day:

fL\=∫0tRvel(kvelC(kvel−1)kvelC−(L−S)−kvel+1) dt f\_L =\\int\_{0}^{t} R\_{vel}\\left(\\frac{k\_{vel}C(k\_{vel}-1)}{k\_{vel}C-(L-S)}-k\_{vel}+1\\right) \\,dtfL​\=∫0t​Rvel​(kvel​C−(L−S)kvel​C(kvel​−1)​−kvel​+1)dt

Where these variables stand for:

*   **f\_L**: The funding rate applied to the larger side, expressed as a percentage per day. For example, if _f\_L_ = 2, it means that the larger side will be charged 2% of their position size daily.
    
*   **C**: The open interest cap for both sides, expressed in millions of USD. For instance, _C_ = 3 means the open interest cap on each side is $3 million.
    
*   **R\_vel**: The maximum potential funding rate velocity. This maximum velocity is applied when the open interest difference between the two sides reaches the cap, i.e., when _L - S = C_ (one side has full open interest, while the other is empty).
    
*   **k\_vel**: The slope parameter (dimensionless), controlling the steepness of the funding rate curve. As _k_ approaches infinity, the funding rate function approximates a linear relationship.
    

The formula above describes a linear velocity-based funding rate which could lead to large values. Therefore, the funding rate is capped to the _maxFundingRate_ parameter.

### 

[](#volatility-fee)

**Volatility Fee**

Captures the externality to Liquidity Buffer of asset volatility. This fee compounds per block and is charged synthetically on a trader's entire position size, subtracted from position PnL. A Gelato automation keeps track of the _Average True Range Volatility_ values on a per-asset basis programmatically updates daily with volatility data inputs from Ostium's oracle.

_The volatility fee prices the risk of a greater probability of large swings in directional exposure resulting from periods of high volatility or sustained greater volatility on certain pairs._

This hyperbolic volatility fee formula is as follows:

fvol\=Rvol(kvolV(kvol−1)kvolV−v−kvol+1)f\_{vol} = R\_{vol}\\left(\\frac{k\_{vol}V(k\_{vol}-1)}{k\_{vol}V-v}-k\_{vol}+1\\right)fvol​\=Rvol​(kvol​V−vkvol​V(kvol​−1)​−kvol​+1)

*   **V**: The maximum allowable volatility in the protocol. Once this threshold is reached, all trading on the corresponding pair must be halted to ensure market stability.
    
*   **R\_vol**: The maximum rollover fee, expressed as a percentage per hour, day, or any other time unit. This fee applies to unrealized PnL when volatility is at its maximum level, ensuring that participants pay the highest rollover costs under extreme conditions.
    
*   **k\_vol**: The slope parameter, akin to funding fees, (dimensionless) that controls the behavior of the volatility function.
    

[PreviousOpening Trades](/ostium-docs/ostium-trading-engine/opening-trades)
[NextClosing Trades](/ostium-docs/ostium-trading-engine/closing-trades)

Last updated 5 months ago

🥅

---

# Overview | Ostium Documentation

[PreviousGlossary](/ostium-docs/getting-started/glossary)
[NextOpening Trades](/ostium-docs/ostium-trading-engine/opening-trades)

Last updated 3 months ago

Ostium enables traders to take on long or short, leveraged, virtual price exposure to a variety of underlying assets. The protocol enables this by coordinating interaction between Traders, Liquidity Providers, and Protocol Services:

*   **Traders,** who are exposed to price variation and PnL changes as a function of their positions;
    
*   **Liquidity Providers,** who supply capital to the Market Making Vault, ensuring the ability to settle any positive PnL trades if the liquidity buffer is depleted;
    
*   **Protocol Services,** including pull oracle and automation services operated by partner networks to fetch asset prices and trigger automated orders (e.g., liquidations, limit orders).
    

The following diagram provides a high-level understanding of how these interactions occur:

[](#fees)

Fees


-------------------

The protocol charges one-time and compounding fees, on opening and holding a trades, respectively. At closing, no fee is charged, except in cases of liquidation. Variable fees seek to mitigate risks, and can change based on position size, OI Imbalance, volatility, and more. Fixed fees are used to pay for associated infrastructure costs (e.g., Oracle Price Service, Automation Keeper System, etc...).

We break down fees by action as follows:

*   [Opening Trades](/ostium-docs/ostium-trading-engine/opening-trades)
    
*   [Holding Trades](/ostium-docs/ostium-trading-engine/holding-trades)
    
*   [Closing Trades](/ostium-docs/ostium-trading-engine/closing-trades)
    

_Fees nudge the protocol towards equilibrium and reward counterparties for the risks they take on._

🏍️

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252F4e4qAnCowrj9YTd53TWH%252FTrader%2520Vault%2520LP%2520%2814%29.png%3Falt%3Dmedia%26token%3D649b7427-8b5c-454a-8d96-f6422bb4cbcd&width=768&dpr=4&quality=100&sign=c595b419&sv=2)

---

# Opening Trades | Ostium Documentation

[](#user-flow)

**User Flow**


---------------------------------

*   Traders have the option to select collateral, exposure, leverage, as well as stop losses and take profits. The protocol supports market, limit, and stop orders at open.
    
*   Prices are called on-demand, either via Chainlink low-latency oracles or Ostium's custom oracle solution, depending on the asset. Chainlink Automations or Gelato Functions respectively monitor emitted price request events and trigger price retrieval when requests are initiated.
    
*   At position open, a trader's collateral is deposited into Ostium's trading contract, which stores the collateral of outstanding open trades until further action is taken (liquidation, closure).
    

[](#trade-settings)

Trade Settings


---------------------------------------

*   **Side:** traders first select the side of their trade – long or short.
    
*   **Order Type:** the protocol supports three open order types at genesis – market, limit, and stop orders. Traders set limit and stop prices for the latter two trade types.
    
*   **Collateral:** the minimum amount is as low as 7 USDC on some assets.
    
*   **Leverage:** traders can select between 1x-200x leverage, depending on the asset. More volatile or lower liquidity assets (e.g., Copper) have lower leverage limits than less volatile and/or highly liquid assets (e.g. GBP/USD).
    
*   **Position Size:** traders can also determine total exposure by first adjusting position size, denominated in the notional asset, and inferring desired leverage or collateral amount.
    
*   **Take Profit & Stop Loss:** traders can optionally set and/or adjust TP and SL orders at open. TP orders at 10x (900%) profit are automatically set to reduce tail event risk for LPs. (_Please note: maximum and mandatory TPs of 10x is enforced; over time the protocol may increase this threshold or eliminate it entirely should risk management analysis determine this protection no longer be necessary)._
    

[](#opening-fee-breakdown)

**Opening Fee Breakdown**


---------------------------------------------------------

A fee is applied to all trades at open. Ostium's opening fee system aims to price externalities of trader behavior resulting from changes in the skew and utilization of Open Interest, thereby nudging traders towards the activity with the fewest negative externalities to the Liquidity Buffer and downstream Liquidity Providers.

### 

[](#protocol-opening-fee)

**Protoco**l Opening Fee

This fee is a function of three trader-determined variables – asset, leverage and position size – and two protocol condition-dependent variables, skew and utilization. Combining these variables aims to price all externalities of a specific trade. Trades increasing skew generate greater delta exposure for the Liquidity Buffer; as a result, skew-increasing trades are charged a higher baseline fee. Additionally, utilization charges are considered if the consumption of Open Interest is above a defined threshold during periods of high OI utilization. To avoid discouraging would-be arbitrageurs from balancing the protocol, this fee is only charged to “takers.”

The fee charges change according to trade characteristics:

*   **Maker charge**: a trader is charged a “maker” fee if the amount of leverage is below 20x **and** OI skew reduces with this trade;
    
*   **Taker charge**: a trader is charged a “taker” fee if the amount of leverage is above 20x **or** if OI skew increases with this trade;
    
*   **Utilization charge:** is additionally applied to takers whose trade increases consumption of Open Interest above a defined threshold (80% of OI) during periods of high OI utilization.
    

\*_For mixed trades (e.g. closing a long OI imbalance, but overshooting and generating a short OI imbalance), maker fees are charged on the portion of the position that is balancing and taker fees on the portion that generates a new directional imbalance. The same goes for utilization charges._

Thus we define the **Protocol Opening Fee** as:

feeprotocolOpen\=makerCharge+takerCharge+utilizationChargefee\_{protocolOpen}= makerCharge+takerCharge+utilizationChargefeeprotocolOpen​\=makerCharge+takerCharge+utilizationCharge

### 

[](#oracle-fee)

**Oracle Fee**

This fee covers the cost of trade opening using Chainlink or Ostium's custom oracle feeds, as well as the automation cost for price fetching. A **fixed fee** of $1, independent of trade size, is charged to the user to pay for costs associated with price fetching and order triggering.

[](#open-price-and-price-impact)

Open Price & Price Impact


---------------------------------------------------------------

To prevent front-running risk and approximate the true price of entering a position, Ostium's oracle includes a measure of the liquidity constraints of the underlying market. This helps mitigate oracle extractable value and negative externalities to Liquidity Providers.

*   **Bid/Ask Price**: instead of using the mid-price to open or close positions, we incorporate real market dynamics where a long position open price is the ask price and closing price is the bid price. See table below:
    

Buy (Long)

Sell (Short)

Open Trade

Ask price

Bid Price

Close Trade

Bid price

Ask Price

*   **Linear Scaled Bid/Ask Spread**: simulating the order-book dynamics involves creating a simplified model that captures how the spread behaves in the real market. The spread increases with position size linearly, meaning that a big trade has a larger spread than a small trade. The formula for the price impact (K represents a constant):
    

Spreadopen\=kopen⋅PositionSizeSpreadclose\=kclose⋅PositionSizeSpread\_{open}=k\_{open} \\cdot PositionSize\\\\ Spread\_{close}=k\_{close} \\cdot PositionSizeSpreadopen​\=kopen​⋅PositionSizeSpreadclose​\=kclose​⋅PositionSize

We dramatically minimize exploit opportunities resulting from underlying market liquidity or increased spreads during market events by simulating real market dynamics and incorporating resulting liquidity information into the price at which a trader can enter a position.

[PreviousOverview](/ostium-docs/ostium-trading-engine/overview)
[NextHolding Trades](/ostium-docs/ostium-trading-engine/holding-trades)

Last updated 5 months ago

---

# Closing Trades | Ostium Documentation

[](#not-liquidated)

Not Liquidated


---------------------------------------

Manually closed or Automations-triggered (Take Profit, Stop Loss) trades can be triggered when positions have a negative or positive trader PnL.

*   **Negative trader PnL:** Triggered by either a manual close or a SL (or a TP) reaching the designated value. A trader's collateral + PnL is transferred back to the trader's wallet (i.e. collateral - losses). The absolute value of the trader's negative PnL (remaining collateral) is transferred to the protocol's [Liquidity Buffer](/ostium-docs/shared-liquidity-layer/liquidity-buffer)
    .
    
*   **Positive trader PnL:** Triggered by either a manual close or a TP (or a SL) reaching the designated value. A trader's initial collateral + positive PnL (from Liquidity Buffer) is transferred back to the trader's wallet.
    

### 

[](#no-closing-fee)

No Closing Fee

Ostium's trading engine does not have a closing fee.

Why? Most exchanges display a misleading unrealized PnL value for traders. While a trader may believe themselves to be in profit, dynamic closing fees and hefty spreads often result in positions closing with meaningfully lower gains than a reading of the interface would suggest (the case for a majority of perpetuals protocols today).

Instead, on Ostium, what you see is what you get: the value of a trader's unrealized PnL represents realized PnL if the trader were to close the open position at market price. This increases transparency and removes the poor user experience of unpredictability resulting from the gap between displayed unrealized and actual realized PnL.

[](#liquidation)

Liquidation


---------------------------------

When a trader uses leverage, the actual position size is larger than the collateral used to open the position. As a result, there exists a price at which a trader's losses equal the initial collateral used to open the position, at which a trader must be liquidated. However, due to asset volatility (particularly with high leverage), execution time, and potential price feed latency, liquidations must occur before collateral value (- PnL) has declined to zero, instead occurring when collateral value has fallen to 10% of original collateral deposited.

Keeper bots deployed via [Gelato Functions](https://docs.gelato.network/web3-services/web3-functions)
 are set to trigger liquidation when the value of a trader's collateral has decreased by 90%. The remaining collateral (10%) is transferred to the Market Making Vault (liquidation reward).

Unlike in protocols where liquidator bots require direct incentivization on a per-liquidation basis by allocating a portion of trader collateral to bot rewards, Ostium's integration with external network-operated liquidation bots (Gelato Functions) means there is no need to allocate additional rewards to incentivize liquidation at a protocol level. The fee required to pay these Automations to monitor the need for and trigger liquidations is already collected at the opening through the [oracle fee](/ostium-docs/ostium-trading-engine/opening-trades#oracle-fee)
.

### 

[](#liquidation-reward-fee)

Liquidation Reward (fee)

The liquidation reward is charged to the trader's remaining collateral in the event of a liquidation and routed to Market Making Vault.

Traders do not receive the remaining collateral if their position is liquidated.

[PreviousHolding Trades](/ostium-docs/ostium-trading-engine/holding-trades)
[NextStep-By-Step Tutorial](/ostium-docs/ostium-trading-engine/step-by-step-tutorial)

Last updated 5 months ago

📘

---

# Order Types | Ostium Documentation

### 

[](#overview)

Overview

Ostium supports seven distinct order types designed to provide traders with execution experiences similar to traditional markets. These order types are categorized into two fundamental execution mechanisms:

1.  **Market Orders** — Triggered by the mid-price and executed at the bid or ask price
    
2.  **Limit Orders** — Triggered and executed at the bid or ask price selected by the user
    

### 

[](#open-trade-orders)

Open Trade Orders

Ostium supports three types of orders for opening positions:

#### 

[](#open-market)

Open Market

*   **Trigger**: Most recent mid-price (immediate execution)
    
*   **Execution**: At bid/ask price
    
*   **Classification**: Market order
    
*   **Behavior**: Order is triggered immediately after the request is received onchain
    
*   **Rationale**: This is a textbook market order, providing immediate execution at the current market conditions
    

#### 

[](#open-limit)

Open Limit

*   **Trigger**: Execution price (bid/ask) crossing user's limit price
    
*   **Execution**: At the execution price that crossed the limit
    
*   **Classification**: Limit order
    
*   **Behavior**: Ensures execution only occurs when the trade can be filled at the limit price chosen by user or better
    
*   **Rationale**: The mid-price crossing the limit is insufficient; execution only occurs when the actual trade price (bid/ask) reaches the limit, ensuring the user gets their desired price or better
    

#### 

[](#open-stop)

Open Stop

*   **Trigger**: Mid-price crossing user's stop price
    
*   **Execution**: At bid/ask price
    
*   **Classification**: Market order
    
*   **Behavior**: Functions as a market order once triggered
    
*   **Rationale**: Follows market conventions where traders expect stop orders to be triggered as market orders. Traders can use limit orders instead if they want to ensure execution at specific prices
    

### 

[](#close-trade-orders)

Close Trade Orders

Ostium supports four types of orders for closing positions:

#### 

[](#close-market)

Close Market

*   **Trigger**: Most recent mid-price (immediate execution)
    
*   **Execution**: At bid/ask price
    
*   **Classification**: Market order
    
*   **Behavior**: Equivalent to Open Market order
    
*   **Rationale**: Provides immediate position closure at current market conditions
    

#### 

[](#take-profit-tp)

Take-Profit (TP)

*   **Trigger**: Execution price (bid/ask) crossing user's TP price
    
*   **Execution**: At the execution price that crossed the TP
    
*   **Classification**: Limit order
    
*   **Behavior**: Ensures that execution only occurs when the expected gains can be realized
    
*   **Rationale**: Limit order architecture is ideal for TP orders as it ensures execution only occurs when the trader's expected profit can be guaranteed, aligning with market conventions
    

#### 

[](#stop-loss-sl)

Stop-Loss (SL)

*   **Trigger**: Mid-price crossing user's SL price
    
*   **Execution**: At bid/ask price
    
*   **Classification**: Market order
    
*   **Behavior**: Optimized for filling during rapid price movements, may result in greater losses than anticipated
    
*   **Rationale**: Market orders are used because stop losses need to fill reliably during volatile price movements when spreads widen. Using limit orders could cause premature triggering during price wicks since bid-ask volatility typically exceeds mid-price volatility
    

#### 

[](#liquidation)

Liquidation

*   **Trigger**: Mid-price crossing the calculated liquidation price
    
*   **Execution**: At bid/ask price
    
*   **Classification**: Market order
    
*   **Behavior**: Calculated internally based on margin requirements
    
*   **Rationale**: Similar to SL orders, using market orders for liquidations prevents premature liquidations during price volatility. Margin requirements in Ostium's liquidation backstop mechanisms already account for the risk of this approach
    

### 

[](#summary)

Summary

Order Type

Classification

Trigger

Execution

Open Market

Market Order

Mid-price (immediate)

Bid/Ask

Open Limit

Limit Order

Execution price crossing limit

Execution price

Open Stop

Market Order

Mid-price crossing stop

Bid/Ask

Close Market

Market Order

Mid-price (immediate)

Bid/Ask

Take-Profit

Limit Order

Execution price crossing TP

Execution price

Stop-Loss

Market Order

Mid-price crossing SL

Bid/Ask

Liquidation

Market Order

Mid-price crossing liquidation price

Bid/Ask

[PreviousStep-By-Step Tutorial](/ostium-docs/ostium-trading-engine/step-by-step-tutorial)
[NextReferral Score](/ostium-docs/ostium-trading-engine/referral-score)

Last updated 7 days ago

📁

---

# Step-By-Step Tutorial | Ostium Documentation

[PreviousClosing Trades](/ostium-docs/ostium-trading-engine/closing-trades)
[NextOrder Types](/ostium-docs/ostium-trading-engine/order-types)

Last updated 5 months ago

[](#opening-a-trade)

Opening a Trade


-----------------------------------------

1.  First, connect your wallet to Ostium's interface:
    

1.  For testnet users, claim ETH via Alchemy's faucet and USDC via Ostium's faucet, directly in-app:
    

1.  Select your desired market from the drop-down menu in the trade form:
    

1.  Select **Side** (long, short), **Order Type** (market, limit, stop), **Collateral Amount**, and **Leverage** (1-200x, depending on the asset). Traders can also input **Estimated Size** (in units of the asset traded), backing out leverage or collateral:
    

1.  Optionally set **Take Profit** or **Stop Loss** conditions. Take profit orders at 10x (900%) gain are automatically set to reduce tail event risk for LPs. _(Please note: maximum and mandatory TPs of 10x is enforced; over time the protocol may increase this threshold or eliminate it entirely should risk management analysis determine they no longer be necessary)._
    

1.  Optionally check fee breakdown by clicking into fee section and hovering over tooltips detailing your precise fee breakdown:
    

1.  Select buy (or sell, for shorts):
    

1.  Confirm trade conditions. Traders can optionally choose to bypass this confirmation step in the future by selecting "hide order confirmation":
    

1.  Confirm order in browser wallet extension (smart wallet is not supported yet, but soon users will bypass this step and proceed directly to order execution through one-click-trading):
    

1.  That's it! Monitor your trades in real-time in the "Trades" tab beneath the asset chart.
    

[](#closing-a-trade)

Closing a Trade


-----------------------------------------

1.  Find the trade you'd like to close under the "Trades" tab beneath the chart or in the "Positions" section on the Portfolio page:
    

1.  Approve the transaction in your browser wallet extension:
    

1.  That's it! See a summary of your remaining open positions as well as your historical (closed) positions under the Portfolio page:
    

📹

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252Fiqfv3unS5q1hEP0dWtLY%252FScreenshot%25202024-04-03%2520at%252001.23.22.png%3Falt%3Dmedia%26token%3D95b4f6f5-71fe-434d-9b08-3e78a08951d8&width=768&dpr=4&quality=100&sign=185a0826&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252Fha3AiZMWJK9Wgjdpmgkk%252FScreenshot%25202024-04-03%2520at%252001.22.46.png%3Falt%3Dmedia%26token%3D86a23a7e-8c73-4d71-9cf5-03052d342fa8&width=768&dpr=4&quality=100&sign=868e8f3a&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FQ2L3bzRw3mM3sTOva7RC%252FScreenshot%25202024-04-03%2520at%252001.26.33.png%3Falt%3Dmedia%26token%3D3391d40a-d7b5-47cf-aab1-48d923b298fc&width=768&dpr=4&quality=100&sign=71b395f&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FlpDV2t5m4lwR2i9ywm9I%252FScreenshot%25202024-04-03%2520at%252001.28.43.png%3Falt%3Dmedia%26token%3D1f8c96aa-7286-4d20-a11f-e60331aff02e&width=768&dpr=4&quality=100&sign=a003e47f&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252F6ktC72FY5PiLBNZmWn9S%252FScreenshot%25202024-04-03%2520at%252001.34.29.png%3Falt%3Dmedia%26token%3D27079f78-f615-4bca-aafd-9a0b402a8b9e&width=768&dpr=4&quality=100&sign=bbb0e524&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FEe5iwn91660oONIMDo4N%252FScreenshot%25202024-10-09%2520at%252015.32.51.png%3Falt%3Dmedia%26token%3D2d291a7b-68f9-4b0f-87c7-e925ed532a24&width=768&dpr=4&quality=100&sign=4c0f034d&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252Flg1760imjgDkAAKokkJW%252FScreenshot%25202024-04-03%2520at%252002.19.29.png%3Falt%3Dmedia%26token%3Db0b08d87-57da-4da7-938e-7ff0caa526fd&width=768&dpr=4&quality=100&sign=e8ca635b&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FxvpgAdpIGiXMEw5XzcUi%252FScreenshot%25202024-04-03%2520at%252002.21.14.png%3Falt%3Dmedia%26token%3D9940f28f-ff1d-4f58-a176-cd1489c5a2e9&width=768&dpr=4&quality=100&sign=a6bb7457&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FGObq7V6ST5fh9EhBhq04%252FScreenshot%25202024-04-03%2520at%252002.29.16.png%3Falt%3Dmedia%26token%3D6538527f-ab1f-4c49-93f0-4093b3190c9a&width=768&dpr=4&quality=100&sign=d7457a49&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FKDHlMPi76nypMVRMiadi%252FScreenshot%25202024-04-03%2520at%252002.31.55.png%3Falt%3Dmedia%26token%3Ded8add42-be08-4c51-95be-b1f383ffdfdf&width=768&dpr=4&quality=100&sign=15d0e45e&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FrMklf9LY8rIBVMl03Ql6%252FScreenshot%25202024-04-03%2520at%252002.33.19.png%3Falt%3Dmedia%26token%3Df69f33ad-2200-428f-8c32-8d7b1f4a6824&width=768&dpr=4&quality=100&sign=2bb6d7f5&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252Fk2tP627x3nbESC6wcRmO%252FScreenshot%25202024-04-03%2520at%252002.36.01.png%3Falt%3Dmedia%26token%3D10e6324e-d98b-4f59-9d72-9d22e8bf43fd&width=768&dpr=4&quality=100&sign=3d42415c&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252F2y5YckE3NHAszSXIfTat%252FScreenshot%25202024-04-03%2520at%252002.37.43.png%3Falt%3Dmedia%26token%3D224e5c1a-31bd-4e11-b60f-c24b08ea109c&width=768&dpr=4&quality=100&sign=44ce9177&sv=2)

---

# Referral Score | Ostium Documentation

### 

[](#what-are-referral-scores)

What Are Referral Scores?

Referral Scores track and reward you for inviting friends to Ostium. By growing the Ostium community, you climb the **Referral Leaderboard** and become eligible for exclusive rewards during referral contests.

* * *

### 

[](#how-it-works)

How It Works

Your Referral Score is calculated using the formula:

Referral Score\=3users+0.01volume+0.1deposits\\text{Referral Score}=3\\sqrt{users}+0.01\\sqrt{volume}+0.1\\sqrt{deposits}Referral Score\=3users​+0.01volume​+0.1deposits​

**Example:** Referring **2 users** and generating **~$10.7M in volume** gives you a **Referral Score** of **37**.

*   **Users:** The number of referred users.
    
*   **Volume:** The trading volume from your referrals.
    
*   **Deposits:** Deposits made by referred users.
    

You can track your activity and score directly in the **referral popup**.

* * *

### 

[](#get-started)

Get Started

1.  Invite friends using your **referral link** or **code**.
    
2.  Your referrees can now copy and use your code directly.
    
    *   **Note:** You can only enter a referral code once (you cannot override a referral code you previously used).
        
    

Start referring, track your score, and compete for rewards during referral contests!

[PreviousOrder Types](/ostium-docs/ostium-trading-engine/order-types)
[NextOverview](/ostium-docs/shared-liquidity-layer/overview)

Last updated 3 months ago

💯

---

# Market Making Vault | Ostium Documentation

Ostium's trading engine is designed to minimize net trader directional exposure and the Liquidity Buffer to absorb such exposure if and when it occurs. However, in the early stages of the protocol (before any incidence of sustained trader losses has the chance to accrue to the Buffer) and in the event of positive trader PnL, the LP Market Making Vault extends this liquidity debts.

LPs deposit their capital in the LP MM Vault to mint OLP tokens, representing their share in the Vault. Moreover, they receive rewards from trading fees for incurring the risk of potential delta exposure.

LPs **deposit** capital in the LP MM Vault, extending protocol liquidity. In return, they are rewarded with a share of trading and liquidation fees.

[](#trading-fee-rewards)

Trading Fee Rewards


-------------------------------------------------

Market Making Vault depositors are rewarded with a share of trading fees:

*   **Opening Fee:** 100% of opening fees collected
    
*   **Liquidation Rewards:** 100% of liquidation rewards (10% of liquidated trader collateral)
    

For a limited time beginning Oct 3rd, 2024, 100% of opening fees are directed to the Market Making Vault.

While the total percentage of collected fees this represents varies as a function of the average size of the opening fee relative to other fees, depositors can expect to earn 70-100% of all fees collected by the protocol.

LP fee returns scale with the implied risks they face. Should the opening fee and funding fee work effectively to incentivize balanced trades and optimal OI utilization, total opening fees collected would decline relative to another revenue source like liquidation rewards, which do not vary as a function of imbalance. The inverse is also true (greater risk leads to higher fees leads to higher LP rewards).

[](#olp-ostium-liquidity-provider-token)

OLP (Ostium Liquidity Provider) Token


-----------------------------------------------------------------------------------

LPs participate in the LP MM Vault by depositing USDC and receiving fungible OLP tokens. These **tokens represent their share in the pool**, acting as proof of ownership and the right to a portion of the vault's assets and earnings. Trading fee rewards are accrued directly into the value of the OLP token, which increases over time should rewards exceed any losses from MM settlement.

Deposits can also be locked for a period of up to 365 days. Locked deposits receive a Lock Boost, receiving a greater share of OLP tokens for the same number of USDC tokens deposited, and thus a greater proportion of trading fees. Lock boosts depend on vault collateralization (more details [here](/ostium-docs/shared-liquidity-layer/market-making-vault/deposit)
) and scale with locking period relative to 365 days: e.g., if the 1-year lock boost is 5%, a 6-month lock will yield a 2.5% boost.

[](#lps-and-counterparty-risk)

LPs and Counterparty Risk


-------------------------------------------------------------

A crucial aspect of the LP MM Vault is that **LPs are not the immediate counterparties to traders**, meaning they aren't exposed by default to individual trade outcomes (which is the role of Liquidity Buffer). Instead, they act as counterparties if and only if the Liquidity Buffer's funds are insufficient to cover trader gains.

[](#collateralization-ratio)

Collateralization Ratio


---------------------------------------------------------

The collateralization ratio identifies whether the buffer is depleted or not. The vault has two states:

*   **overcollateralized**: ratio >= 100% -> buffer settles traders' gains, LPs collect X % of the opening fee and liquidation rewards
    
*   **undercollateralized**: ratio < 100% -> LPs settle traders' gains & losses and collect 100% of the opening fees, liquidation rewards, and rollover fee
    

Ostium's collateral ratio is defined differently from the traditional loan collateral ratio commonly used in TradFi. Instead of evaluating your LP profitability, this ratio determines whether a buffer exists. To assess profitability, LPs must consider the OLP price variation.

[PreviousLiquidity Buffer](/ostium-docs/shared-liquidity-layer/liquidity-buffer)
[NextDeposit](/ostium-docs/shared-liquidity-layer/market-making-vault/deposit)

Last updated 3 months ago

---

# Overview | Ostium Documentation

The **Shared Liquidity Layer (SLL)** is the protocol structure responsible for aggregating liquidity and settling trades, and contains two distinct components:

*   **Liquidity Buffer**: settlement layer for trader PnL, accumulating value during periods of net trader losses and shrinking during periods of sustained trader gains. Accumulates volatility fee and cannot be deposited directly or withdrawn from by LPs;
    
*   **Market Making Vault**: settlement in the event the Liquidity Buffer is depleted. LPs deposit capital into the Market Making Vault and are rewarded for the risk they take on of potentially needing to act as counterparties with liquidation rewards and a portion of trading fees.
    

_Ostium is designed not as central limit orderbook, which relies on order matching and requires an immediate seller for every buyer, but rather as a virtual pool-based DEX able to sustain imbalances in Open Interest, the net delta risk of which is taken on by the Shared Liquidity Layer. The fee design seeks to mitigate both the magnitude and frequency of these imbalances to minimize exposure risk for the vault. Market Making Vault depositors take on the potential risk of delta exposure, including loss resulting from sustained trader gains, when depositing on Ostium._

The **Liquidity Buffer** is primarily funded by negative PnL trades and serves as the first line of settlement for positive PnL trades, while the **LP Market Making Vault** acts as a backup.

[](#liquidity-buffer-and-lp-market-making-vault)

Liquidity Buffer and LP Market Making Vault


-------------------------------------------------------------------------------------------------

Given our design, you may be asking yourself: _Why does Ostium's SLL have two different sub-structures instead of just one?_

To begin, let's consider the standard way pool-based perpetuals protocols structure LP rewards and trader counterparty risk. Generally, LPs benefit from and bet directly on trader losses. This leads to an adversarial relationship between traders and LPs, who stand to benefit most from traders losing money.

However, by dividing the vault into two isolated structures (Liquidity Buffer and LP Market Making Vault, or "MMV") and strategically defining fee flows, Ostium is able to shift fund distribution such that LPs – who can only deposit and withdraw funds into the MMV – benefit primarily from volume and Open Interest growth, rather than trader losses. The Liquidity Buffer is designed to be able to absorb trader PnL in the majority of cases, minimizing APY volatility for MMV LPs in the event of sustained trader gains. This reduces the adversarial nature of the relationship between LPs and traders and aligns interests towards overall protocol growth.

_LPs are thus not always traders' immediate counterparties but rather extend maker liquidity if and when the buffer is unable to. LPs in return are rewarded with liquidation rewards and trading fees._

To summarize, Ostium's dual vault structure is designed to:

*   Shift the adversarial **relationship** between traders and LPs to a **positive-sum** one, whereby LPs benefit primarily from protocol volume growth, not trader losses;
    
*   **Reduce APY variability**, with the Liquidity Buffer acting as the first and primary settlement layer;
    
*   Remain simple and user-friendly, abstracting complexity with only one pool – the LP Market Making Vault – to deposit into.
    

[](#vault-interactions-and-fee-distribution)

Vault interactions and fee distribution


-----------------------------------------------------------------------------------------

_So how does this work, practically?_

At a high level, the Liquidity Buffer accrues trader PnL, whether positive or negative, and volatility fee, while the LP Market Making Vault accrues fees (liquidation reward and 50% of the opening fee) and acts as settlement for trader PnL _if and only if_ (IFF) the Liquidity Buffer is depleted. Over time, assuming small net trader losses, the Liquidity Buffer grows in value, enabling more rapid expansion of Open Interest caps due to Buffer capital's stickiness and reducing APY variability for LPs, whose risk of needing to act as a trader counterparty goes down.

The following diagram provides an overview of capital flows:

Let's break down the capital flows for each trade lifecycle step:

1.  **Opening trades**: a % of the initial collateral is reserved for the `protocol opening fee` and distributed to the Shared Liquidity Layer (SLL);
    
2.  **Holding trades**: `volatility fee` is accrued from period to period on the open positions and goes directly to the Liquidity Buffer;
    
3.  **Closing trades**:
    
    1.  Profit (positive PnL):
        
        1.  _Liquidity Buffer > 0_: Liquidity Buffer settles trades;
            
        2.  _Liquidity Buffer = 0_: LP MM Vault settles trades, if and only if the Liquidity Buffer is depleted (further details [here](/ostium-docs/shared-liquidity-layer/market-making-vault)
            );
            
        
    2.  Loss (negative PnL):
        
        1.  _Not Liquidated_: Liquidity Buffer receives traders losses;
            
        2.  _Liquidation_: 90% of initial collateral (traders loss) goes to the Liquidity Buffer and the remaining 10% goes to the LP MM Vault (`liquidation reward`).
            
        
    

[PreviousReferral Score](/ostium-docs/ostium-trading-engine/referral-score)
[NextLiquidity Buffer](/ostium-docs/shared-liquidity-layer/liquidity-buffer)

Last updated 3 months ago

🏦

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252Ffm1dUzcxIagNu691kAqM%252FTrader-Vault-LP.png%3Falt%3Dmedia%26token%3Dce04f0e0-5e67-491f-8468-c68e0f214b95&width=768&dpr=4&quality=100&sign=11f15a02&sv=2)

---

# Liquidity Buffer | Ostium Documentation

LPs can **not** deposit or withdraw from the Buffer.

_If the Ostium trading engine is designed to mitigate risk, why does the protocol need a Liquidity Buffer?_ For two reasons:

*   **Settle trades**: when a trade is closed, the Liquidity Buffer provides capital to profitable trades and accumulates value from trade losses;
    
*   **Support traders' directional exposure risk**: when the OI Imbalance differs from 0, the Liquidity Buffer buffers this risk (no pun intended), minimizing variability in LP rewards.
    

[](#scaling-assets-and-facilitating-delta-exposure)

Scaling Assets & Facilitating Delta Exposure


-----------------------------------------------------------------------------------------------------

While Ostium's fee structure is designed to push the protocol towards equilibrium, the function of the pool is to enable traders to take on directional exposure on an asset, even in the absence of a direct trading counterparty. This is particularly important for scaling to long-tail or low-liquidity assets, which may see periods of few or no traders in a particular direction. To facilitate listing such assets – listing diversity and novelty being core to the protocol's value proposition – Ostium features a shared liquidity model. This pooled liquidity enables the accrual of directional exposure, or Open Interest imbalance, while preserving a buffer of capital to ensure trade settlement.

If the Liquidity Buffer is depleted, the LP Market Making Vault settles trades, acting as a Market Maker to extend liquidity to traders.

There are three possible states of Delta Exposure in the protocol. Considering only one asset, the following protocol agents are active in each state:

1.  Only **traders**: long and short OI is perfectly balanced
    
2.  **Traders** and **Liquidity Buffer**: OI imbalance differs from 0
    
3.  Only **Liquidity Buffer**: either long or short OI is 0
    

Ideally 1) all trades are perfectly balanced, however, the most common scenario is 2), with some OI Imbalance, where the counterparties to the "skewed" side are those traders on the opposite side (short to a skewed long, and the inverse) and the Liquidity Buffer.

[](#usage-of-lp-mm-vault)

Usage of LP MM Vault


---------------------------------------------------

If and only if the Liquidity Buffer gets depleted, the LP MM Vault is used to settle trades. If, for instance, large, highly profitable trades are closed consecutively, there is potential for the Liquidity Buffer to be drained. This event activates temporary utilization of the LP MM Vault to cover potential trader gains.

[PreviousOverview](/ostium-docs/shared-liquidity-layer/overview)
[NextMarket Making Vault](/ostium-docs/shared-liquidity-layer/market-making-vault)

Last updated 8 months ago

💦

---

# OLP token | Ostium Documentation

[](#minting)

Minting


-------------------------

LPs deposit USDC into the LP MM Vault. The protocol **mints** the equivalent number of OLP tokens, at the deposit entry time price, and sends tokens to the same wallet used to deposit. However, if the user deposits with a lockup period, they receive an NFT representing the OLP tokens, which are held in the vault until the lockup period ends and the user unlocks the tokens.

[](#burning)

Burning


-------------------------

Once the withdrawal process is completed, the protocol burns OLP tokens and sends the equivalent USDC amount to the LP.

[](#rewards)

Rewards


-------------------------

The MM Vault accumulates these fees from trading activity (diagram [here](/ostium-docs/shared-liquidity-layer/overview#vault-interactions-and-fee-distribution)
):

*   100% of [protocol opening fee](/ostium-docs/ostium-trading-engine/opening-trades#protocol-opening-fee)
    
*   100% of [liquidation reward](/ostium-docs/ostium-trading-engine/closing-trades#liquidation-reward)
    

For a limited time beginning Oct 3rd, 2024, 100% of opening fees are directed to the Market Making Vault.

By depositing capital into the MM Vault, LPs earn rewards, with fees generated from trading activity. Depositors can estimate their potential earnings through the projected APY displayed on the User Interface or manually derivation through observed protocol flows.

[](#pricing-and-example)

Pricing & Example


-----------------------------------------------

Fee flows are compounded directly into the vault, and as a result, any OLP token holdings. Sample flow:

*   Alice deposits 100 USDC into the MM Vault at time t, at which time 1 OLP = 1 USDC. She now has 100 OLP in her wallet.
    
*   At time t+1, the value of the MM Vault has grown programmatically as a result of compounding trading and liquidation fees. Now, 1 OLP = 1.10 USDC.
    
*   Alice requests to withdraw from the vault at time t+1, which in practice means burning her 100 OLP and redeeming them for their USDC value.
    
*   Alice receives 110 USDC, effectively posting a gain of 10%. Alice does not lock in her conversion price when she requests a withdrawal; she receives 110 USDC based on the conversion rate at the actual time of withdrawal itself.
    

[PreviousWithdraw](/ostium-docs/shared-liquidity-layer/market-making-vault/withdraw)
[NextRisks](/ostium-docs/shared-liquidity-layer/risks)

Last updated 3 months ago

📊

---

# Risks | Ostium Documentation

As discussed in the Ostium Trading Engine [section](/ostium-docs/ostium-trading-engine/overview)
, fees attempt to minimize OI Imbalance, in order to maintain delta neutrality. However, if a high OI Imbalance and volatility periods happen simultaneously, this can result in directional exposure for LPs\*.

[](#directional-exposure-risk)

Directional Exposure Risk


-------------------------------------------------------------

Directional exposure risk occurs when LPs are exposed to price changes in the underlying market. Our understanding of this risk is that 1) OI Imbalance creates the possibility of 2) price movements (volatility) driving uncertainty to LP returns\*.

The following Volatility-OI Imbalance matrix illustrates how directional exposure risk changes accordingly:

\[Directional Exposure\]

Low Volatility

High Volatility

Low OI Imbalance

low

medium

High OI Imbalance

medium

high

The [Imbalance Score](https://www.ostium.io/blog/the-imbalance-score-a-novel-metric-for-rwa-focused-perpetual-dexes)
 is a metric developed by Ostium to measure the current overall directional exposure risk experienced by the protocol.

_\*assuming the Liquidity Buffer is empty_

### 

[](#mitigation)

Mitigation

Mitigating the directional exposure risk is fundamental to increasing the protocol's robustness. Ostium minimizes LP exposure through:

*   **Liquidity Buffer**: first settlement layer for profitable trade and supports the directional exposure risk, unless the Buffer is depleted;
    
*   **Trading Fees**: which have two purposes: 1) reward LPs for putting their funds at risk in service of protocol liquidity, with the possibility of being exposed to directional risk, and 2) drive the protocol towards equilibrium (closing the OI Imbalance or charging more in periods of high volatility).
    

_Minimizing risks for LPs and traders is at the core of Ostium's protocol design._

### 

[](#monitoring-and-improvements)

Monitoring & Improvements

[Chaos Labs](https://www.ostium.io/blog/ostium-partners-with-chaos-labs)
 will actively monitor metrics assessing the protocol's variable directional exposure risk (e.g. Imbalance Score), and make parameter recommendations as needed to optimize risk mitigation. Their team works carefully in concert with the Ostium protocol to ensure this information leads to improvements in both user experience and risk reduction, pushing the protocol towards greater safety and robustness.

[PreviousOLP token](/ostium-docs/shared-liquidity-layer/market-making-vault/olp-token)
[NextOverview](/ostium-docs/supporting-infrastructure/overview)

Last updated 12 months ago

⁉️

---

# Withdraw | Ostium Documentation

[PreviousDeposit](/ostium-docs/shared-liquidity-layer/market-making-vault/deposit)
[NextOLP token](/ostium-docs/shared-liquidity-layer/market-making-vault/olp-token)

Last updated 5 months ago

Before withdrawing their USDC (deposited assets + rewards), LPs must submit a **request** to withdraw (approvals are programmatic). This initiates a "cooling off" period to prevent potential front-running of withdrawal immediately before the realization of large outstanding trader gains that could negatively impact the value of the LP MM Vault under certain conditions.

While the LP request is pending, OLP tokens are **locked** inside the user's wallet, and that length depends on the collateralization ratio of the vault. Users must wait a variable number of epochs (between one and three) to withdraw their capital. The more undercollateralized the vault, the more epochs users must wait, up to a maximum of three 3-day epochs.

Once the waiting time has elapsed, an LP can withdraw during the first half of that epoch. If that window is missed, LPs must wait until the start of the next epoch.

[](#withdraw-request)

Withdraw Request


-------------------------------------------

Unlocked deposits can request a withdrawal at any time, subject to a variable cooling-off period of between one and three 3-day epochs:

*   if _collateralization > 120_: 1 epoch (3 days)
    
*   if _110 < collateralization <= 120_: 2 epochs (6 days)
    
*   if _collateralization <= 110_: 3 epochs (9 days)
    

Withdraw requests must be made within the first 48H of any epoch, and can be withdrawn at the start of the corresponding epoch. The length of the cooling-off period varies entirely programmatically, depending on the collateralization ratio of the Market Making Vault.

If interfacing directly with the user interface rather than smart contracts directly, depositors will see:

*   **Time Remaining:** A countdown clock illustrating the time remaining to request a withdrawal in the current epoch.
    
*   **You Will Receive:** The number of USDC for which your selected OLP withdraw amount is redeemable for.
    
*   **Current Wait Period:** The current number of epochs a depositor must wait to withdraw their funds (always between 1 and 3 epochs).
    
*   **Redeemable On:** The exact date and time at which a user's OLP will be redeemable for USDC, based on the current request and cooling off period length.
    

[](#withdrawing)

Withdrawing


---------------------------------

After a withdrawal request has been made, a user will see that pending request appear under the "LP History" tab beneath the LP deposit/withdraw/unlock form. A user will see both the epoch number at which the request was created as well as the epoch number at which the amount is redeemable. When the required cooling-off period has elapsed, the button at the top right of the history form will become clickable. Clicking will initiate a request in a user's wallet to sign a transaction to redeem OLP for USDC.

[](#unlocking)

Unlocking


-----------------------------

Users who lock their OLP tokens receive an NFT representing their locked OLP allocation (deposit + bonus). The OLP tokens are stored into the vault until unlocked by the depositor. He may do so, once the locking period has elapsed, by burning his NFT to receive his OLP including the bonus. Locked deposits must first be unlocked before they can be withdrawn.

Depositors can do so through interactions with the smart contracts directly or via the existing user interface by navigating to the "Unlock" tab within the vault page. An "unlock" button located on the right hand portion of the screen can be clicked, which triggers an approval request in a user's wallet. Once initiated, funds are immediately unlocked and appear under the adjacent "Withdraw" tab.

📊

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FDH3jBTU7tbMAQ87zVZ0a%252FScreenshot%25202024-10-10%2520at%252023.52.06.png%3Falt%3Dmedia%26token%3D73b2c79f-caa9-49df-9dca-08156f87a8cc&width=768&dpr=4&quality=100&sign=7fd322e6&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252F280tlEfmA3UuKdj4Y21Z%252FScreenshot%25202024-10-10%2520at%252023.55.50.png%3Falt%3Dmedia%26token%3De39bcd6b-694e-40c1-a23a-370cafae9690&width=768&dpr=4&quality=100&sign=a4369793&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252FB1SMFzAbY5Eug1B5zMS2%252FScreenshot%25202024-10-10%2520at%252023.57.10.png%3Falt%3Dmedia%26token%3Dd6f2b151-2fcd-4573-b5ed-aa3a2531ae2e&width=768&dpr=4&quality=100&sign=af5da4f&sv=2)

---

# Automations | Ostium Documentation

[](#gelato-functions)

Gelato Functions


-------------------------------------------

Gelato functions are an Automation Keeper System that both listens to price requests emitted onchain and monitors existing open trades for conditions necessary to trigger automated orders (liquidations, stop loss, take profit, limit orders).

_High-leverage trading requires both a low-latency Oracle and an Automation Keeper System to ensure stellar UX and secure trading._

Gelato functions are programmed to trigger the following actions:

*   Limit Orders
    
*   Stop Limit Orders
    
*   Take Profits
    
*   Stop Losses
    
*   Liquidations
    
*   Price Request
    

See Gelato functions [documentation](https://docs.gelato.network/web3-services/web3-functions/understanding-web3-functions)
 for more details.

[PreviousPrice Oracle](/ostium-docs/supporting-infrastructure/price-oracle)
[NextAPI & SDK](/ostium-docs/api-and-sdk)

Last updated 5 months ago

💻

---

# Overview | Ostium Documentation

As mentioned in the Ostium Trading Engine [section](/ostium-docs/ostium-trading-engine/overview)
, **Off-Chain Services** are one of Ostium's three pillars. Those include a pull oracle and automation services operated by partner networks to fetch asset prices and trigger automated orders (e.g., liquidations, limit orders).

_Any high-speed perp DEX needs off-chain infrastructure to support it, custom-built in this case by the development company behind the Ostium Protocol to service the unique complexities of traditional asset markets (commodities, FX, indices and more). However, in the spirit of disintermediation and maximal decentralization, Ostium ensures minimal operational involvement through partner network operation._

[](#infrastructure-partners)

Infrastructure Partners


---------------------------------------------------------

Ostium relies on complex external systems requiring near-perfect uptime and substantial redundancy. Partnerships with two core networks facilitate this:

*   **Oracle**: [Stork](https://www.stork.network/)
     nodes for Ostium's in-house RWA feeds, [Chainlink](https://docs.chain.link/data-streams)
     for crypto feeds
    
*   **Automated Keeper System**: [Gelato](https://gelato.network)
    

The following items represent the up-stream interactions of this infrastructure before interacting with Ostium's smart contracts:

1.  **Data Providers**: multiple exchanges offer real-time price feeds, ensuring that traders on our platform always have access to the latest market prices for every listed trading pair, delivering accuracy and reliability in every trade;
    
2.  **Stork**: Oracle price services, developed by Ostium Labs and operated by partners, optimizing decentralization by distributing responsibilities while maintaining secure and reliable price feeds;
    
3.  **Gelato**: Automation services monitor onchain price requests and respond by providing the requested price report onchain. Additionally, Gelato automates the conditional orders for SL, TP, Liquidation and Limit;
    
4.  **Ostium Protocol:** Our smart contracts ensure that all open and close orders are executed using the latest price, guaranteeing up-to-date accuracy in every trade.
    

[PreviousRisks](/ostium-docs/shared-liquidity-layer/risks)
[NextPrice Oracle](/ostium-docs/supporting-infrastructure/price-oracle)

Last updated 25 days ago

---

# Deposit | Ostium Documentation

[PreviousMarket Making Vault](/ostium-docs/shared-liquidity-layer/market-making-vault)
[NextWithdraw](/ostium-docs/shared-liquidity-layer/market-making-vault/withdraw)

Last updated 5 months ago

[](#depositing)

Depositing


-------------------------------

LPs can deposit USDC at any time into the LP Market Making Vault and receive the equivalent value in OLP tokens, representing a claim on the pool's assets and rewards. OLP tokens can be freely transferred or traded on prospective secondary markets. Liquidity pool tokens accrue rewards directly into the token value, rather than requiring a separate claiming module for rewards.

Prospective users may deposit through direct interaction with the protocol's smart contracts or through an existing user interface. The existing UI displays:

*   The current conversion ratio between USDC and OLP
    
*   The option to select an amount of USDC to deposit
    
*   The option to select a locking period
    
*   **You will receive:** The number of OLP tokens a user's given USDC deposit will convert to at the time of deposit
    
*   **Lock boost:** The boost in USDC <> OLP conversion on a user's deposits, given the user's locking length and vault collateralization. Non-locked deposits have a lock boost of 0.
    

[](#locking)

Locking


-------------------------

LPs can optionally choose to lock their deposits for up to 365 days, boosting their rewards in the process through a discount on OLP price at mint. Locked deposits are represented through an NFT in the user's wallet and can be redeemed at unlock for the corresponding number of OLP tokens (deposit + bonus).

The boost is influenced by both the locking period and the vault's collateralization. If the vault is undercollateralized (<100%) and the locking period is 365 days, the boost provides an additional 6% OLP. When the collateralization is between 100 and 120, the boost scales linearly. No boost is applied if collateralization is 120 or higher.

For instance, imagine this scenario where the maximum annualized boost is 6% and the Market Making's collateralization is 110%:

*   Alice deposits 1,000 USDC when the OLP token value is 1 USDC, locking for 365 days
    
*   She receives an NFT representing her allocation of 1,030 OLP (3% boost)
    
*   Bob deposits 1,000 USDC with no lock to maintain flexibility to withdraw at anytime, but maintains his funds in the protocol for 365 days
    
*   He receives 1,000 OLP tokens (no boost)
    
*   After a year, baseline APY from trading + liquidation fees is 10%, which accrues directly to the OLP token
    
*   Alice unlocks and withdraws her OLP and receives 1,030 \* 1.1 = 1,133 USDC
    
*   Bob withdraws his OLP and receives 1,000 \* 1.1 = 1,100 USDC
    
*   This means Alice’s net APY is 13.3%, while Bob’s is 10%. Alice’s yield was 33% higher than that of Bob’s.
    

Users visiting the existing user interface will see the value "Lock Boost" vary as a function of the locking period selected. This value scales linearly to a year (365 days) according to the amount of time a user selects to lock their deposits.

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252Fr8TcrzLJlTEhtDg4F3IJ%252FScreenshot%25202024-10-10%2520at%252023.58.09.png%3Falt%3Dmedia%26token%3Dfef2011e-d5a5-4598-a7cb-91b3f0fe6275&width=768&dpr=4&quality=100&sign=690ab611&sv=2)

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252F5FOaPQ1jJIEgJm5HOtWL%252FScreenshot%25202024-10-11%2520at%252000.03.21.png%3Falt%3Dmedia%26token%3De0d45466-50c9-4697-bc48-6f9ef5fe5685&width=768&dpr=4&quality=100&sign=da31f306&sv=2)

---

# Price Oracle | Ostium Documentation

[PreviousOverview](/ostium-docs/supporting-infrastructure/overview)
[NextAutomations](/ostium-docs/supporting-infrastructure/automations)

Last updated 20 days ago

1.  In-house built Real World Asset feeds, with node and aggregator infrastructure operated by Stork Network
    
2.  Chainlink Data Streams for crypto feeds.
    

[](#real-world-asset-oracle-ostium-x-stork)

Real World Asset Oracle: Ostium x Stork


----------------------------------------------------------------------------------------

Ostium uses a pull-based RWA oracle system architected in-house from the ground up for the unique complexities of Real World Assets.

The existence of out-of-market hours, future contract rolls, price gaps at market open, and more for RWAs meant secure, trust minimized, scalable price feeds – in particular for long-tail assets – could only be achieved through a custom oracle solution.

Data partnerships and sourcing, market hours data, and asset-specific node price feed aggregation logic are built by the development company behind the Ostium Protocol.

A majority of node infrastructure is then managed and operated by Stork & their decentralized network of nodes.

Unlike cryptocurrencies which trade continuously, real-world assets (RWAs) such as commodities and forex pairs operate on defined weekly trading schedules. You can access these schedules through the [API & SDK documentation section](https://ostium-labs.gitbook.io/ostium-docs/api-and-sdk)
 or by clicking the colored dot in the top-left corner of the Trading View chart, adjacent to the asset name.

Although orders cannot be executed during market closures, you may still place Limit and Stop orders when markets are closed. These orders will automatically execute when markets reopen and the specified price conditions are met. Note that Market orders cannot be placed during non-trading hours.

Supplementing the standard weekly schedule, feeds include holiday session data that specifies dates when markets are closed for trading.

[](#crypto-oracle-chainlink-data-streams)

Crypto Oracle: Chainlink Data Streams


------------------------------------------------------------------------------------

Ostium uses Chainlink [Data Streams](https://docs.chain.link/data-streams)
 for its crypto feeds. Chainlink's reliability and track record of security are paramount to ensuring secure feeds for high-volatility crypto assets.

[](#pull-vs.-push-oracles)

Pull vs. Push Oracles


-----------------------------------------------------

Because of the costs involved in writing prices onchain for high-throughput (1sec price updates across dozens of assets) applications, prices in a pull-based system are only written onchain when explicitly required for trade execution.

To ensure appropriate pricing, market open/close data and bid/ask prices (order book depth) are passed directly into the price report's metadata, and consumed programmatically by Ostium's smart contracts to eliminate human intervention in spread setting and market hour adaptations.

See Stork [documentation](https://docs.stork.network/)
 for more details.

_**Further details on our unique in-house oracle architecture coming soon.**_

🔮

![](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252Fu7Q550VSkjudG999hPj6%252FTV-Screenshot%25202025-03-12%2520at%252014.54.13.png%3Falt%3Dmedia%26token%3Da4fdc209-32b3-48d7-8abf-bab85b8bf52d&width=768&dpr=4&quality=100&sign=6ebbac45&sv=2)

---

# Smart Contract Audits | Ostium Documentation

The integrity of our code is paramount. We've conducted comprehensive audits to identify potential vulnerabilities, carried out by industry experts.

#### 

[](#smart-contracts-addresses)

Smart Contracts Addresses

Name

Contract Address

proxyAdminAddress

0x083F97BabF33D4abC03151B5DEc98170761f4025

registryAddress

0x799a139aE56e11F0476aCE2f6118CfcAed9608d2

vaultAddress

0x20D419a8e12C45f88fDA7c5760bb6923Cee27F98

lockedDepositNftAddress

0xb4f1123BE58f5d69E1cf565ED8756C7fcf31c8D3

tradingStorageAddress

0xccd5891083a8acd2074690f65d3024e7d13d66e7

pairInfosAddress

0x3890243a8fc091c626ed26c087a028b46bc9d66c

pairsStorageAddress

0x260E349F643f12797fDc6f8c9d3df211D5577823

tradingAddress

0x6D0bA1f9996DBD8885827e1b2e8f6593e7702411

tradingCallbacksAddress

0x7720fC8c8680bF4a1Af99d44c6c265a74e9742a9

openPnlFeedAddress

0xE607aC9FF58697c5978AfA1Fc1C5C437a6D1858c

tradesUpKeepAddress

0x959Da1452238F71F17f7DA5dbA2e9c04FEf57324

priceRouterAddress

0x4B0C3c77D398912491f192d265b237C8d4441AD7

priceUpKeepAddress

0x52B2a78E12b09B66C6c8ce291D653D40bAb77f0c

privatePriceUpKeepAddress

0xB71ec9eBD8145daCaCF6724363143cb5667A3d36

verifierAddress

0xcCF233920e8cc9415ecF503b992881d69b6c47Ad

#### 

[](#audit-1-zellic)

Audit 1: Zellic

We conducted a first audit with Zellic. Report below.

#### 

[](#audit-2-threesigma)

Audit 2: ThreeSigma

We conducted a second audit with ThreeSigma. Report below.

[PreviousAPI & SDK](/ostium-docs/api-and-sdk)
[NextEconomic Audit](/ostium-docs/security/economic-audit)

Last updated 2 months ago

🔐

[1MB\
\
Ostium - Zellic Audit Report (1).pdf\
\
pdf](https://1263702948-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCEDPLHGTrrpP1i2dbe3d%2Fuploads%2FaMgw1k5iR4SvbYWRcs7q%2FOstium%20-%20Zellic%20Audit%20Report%20(1).pdf?alt=media&token=771b25d4-be83-4a49-b1b5-8a9184d2b3f6)

[7MB\
\
OstiumAudit.pdf\
\
pdf](https://1263702948-files.gitbook.io/~/files/v0/b/gitbook-x-prod.appspot.com/o/spaces%2FCEDPLHGTrrpP1i2dbe3d%2Fuploads%2FMpYIMzIusmebDMScUlYB%2FOstiumAudit.pdf?alt=media&token=7043d99e-ba05-4ad1-8505-d3cf9e2a6415)

---

# API & SDK | Ostium Documentation

Ostium Labs offers an SDK built in Python (v3.10) that allows for reading of the platform's state: a list of trading pairs, rolling fees, and open interest caps for each. It also allows for placing of new Orders (Market, Limit and Stop), reading their state, such as open PnL and fees paid, as well as editing them and deleting them. It also allows for reading the entire history of orders. All of this can be done in an entirely programatic way by using python as the programing language.

Ostium also provides a REST endpoint that serves the purpose of exposing platform metrics and state in an easy manner for anyone to read.

*   Reading latest prices for all feeds:
    
    Copy
    
        curl  -X 'GET' 'https://listener.ostium.io/PricePublish/latest-prices' 
         -H 'Content-Type: application/json'  | jq
    
    This is useful when placing an order on the platform, allowing a user to see the latest price before placing a trade.
    
*   Reading the trading hours for RWA assets:
    

Copy

    curl "https://backend.ostium.io/asset-schedule?asset=EURUSD" | jq

This endpoint returns a response showing the trading pair trading schedule and the current trading status, in a human readable format, e.g:

Copy

    {
      "timezone": "America/New_York",
      "openingHours": [\
        "Mo-Fr 04:00-17:00,18:00-20:00"\
      ],
      "nextPublicHoliday": "2025-04-18",
      "isOpenNow": false
    }

*   Reading liquidity providers' exposure:
    

Copy

    curl -X POST https://backend.ostium.io/lp-exposure  -H 
    "Content-Type: application/json" -d 
    '{"address": "0x605920C7A289af4891C824602ad0E3449F8676B9"}'  | jq

If you have deposited liquidity to the vault, you can use the above REST end-point by supplying your depositing address to retrieve insights into your exposure to different assets based on the current imbalance state of the platform.

[](#dune-analytics)

Dune Analytics


---------------------------------------

Below is the Dune analytics dashboard showing the platform's main metrics:

[](#chaos-labs-dashboard)

Chaos Labs dashboard


---------------------------------------------------

Below is the platform's risk analysis dashboard from Chaos Labs:

[https://community.chaoslabs.xyz/ostium/risk/overview](https://community.chaoslabs.xyz/ostium/risk/overview)

[](#python-sdk)

Python SDK


-------------------------------

Ostium's PyPi module is located [here](https://pypi.org/project/ostium-python-sdk)
. The codebase for the SDK is publicly available [here](https://github.com/0xOstium/ostium-python-sdk)
.

#### 

[](#installing-the-sdk)

Installing the SDK

Copy

    pip install ostium-python-sdk

If you wish to contribute code or report of any issue, please contact us via Github repository page.

The SDK works both on mainnet (Arbitrum One) and on testnet (Arbitrum Sepolia).

In order to instantiate the SDK you merely need a RPC URL for one of the above networks you wish to interact with. You can obtain an RPC freely from Alchemy; consult the README for more information.

In order to place trades you need to instantiate the SDK with a private key or to supply a private key to relevant methods. Consult the README for more information and basic related security issues.

To place trades on testnet, you must obtain testnet USDC, which you can do from our faucet. The SDK has a special set of actions that enable this.

To start performing any write operation (e.g. interact with the platform on testnet or mainnet using the instantiated private key), you must have some native token for gas. For Arbitrum Sepolia gas, you may use [Alchemy's Arbitrum Sepolia Faucet](https://www.alchemy.com/faucets/arbitrum-sepolia)
.

[PreviousAutomations](/ostium-docs/supporting-infrastructure/automations)
[NextSmart Contract Audits](/ostium-docs/security/smart-contract-audits)

Last updated 8 days ago

💾

[![Logo](https://dune.com/assets/glyph-1024w.png)Ostium StatsDuneAnalytics](https://dune.com/ostium_app/stats)

---

# Economic Audit | Ostium Documentation

In addition to Smart Contract audits, we conducted extensive mechanism design research, parameter testing, and a full economic audit with DeFi risk management firm [Chaos Labs](https://www.ostium.io/blog/ostium-partners-with-chaos-labs)
.

#### 

[](#risk-research)

Risk Research

Our research on the [Imbalance Score](https://www.ostium.io/blog/the-imbalance-score-a-novel-metric-for-rwa-focused-perpetual-dexes)
 with Chaos Labs helped build a framework for measuring cumulative pool delta risk for use in risk monitoring and parameter adjustment (e.g., OI caps).

#### 

[](#economic-audit-chaos-labs)

Economic Audit: Chaos Labs

We are in the process of conducting an economic audit with Chaos, which will be shared in the weeks leading up to trading launch.

[PreviousSmart Contract Audits](/ostium-docs/security/smart-contract-audits)
[NextTerms of Use](/ostium-docs/legal/terms-of-use)

Last updated 9 months ago

💰

---

# Terms of Use | Ostium Documentation

[PreviousEconomic Audit](/ostium-docs/security/economic-audit)
[NextDisclaimer](/ostium-docs/legal/disclaimer)

---

# Disclaimer | Ostium Documentation

[PreviousTerms of Use](/ostium-docs/legal/terms-of-use)

---

# Welcome to Ostium | Ostium Documentation

[](#protocol-interface-labs)

What is Ostium?


-------------------------------------------------

The Ostium Protocol is an open-sourced, decentralised exchange on Ethereum Layer 2 Arbitrum, enabling transparent and non-custodial perpetuals exposure to Real World Assets. More specifically, Ostium is building decentralized trading infrastructure to allow you to trade _any asset_ like a perp – all fully onchain.

Users of the Ostium Protocol can:

*   Trade perpetuals on Forex, Commodities, Indices, and blue-chip Crypto assets
    
*   Deposit stablecoins to provide liquidity to the protocol
    
*   Contribute to our community and provide product feedback through our open forums
    

[](#protocol-interface-labs-1)

Protocol, Interface, Labs[​](https://docs.uniswap.org/concepts/overview#protocol-interface-labs)



-------------------------------------------------------------------------------------------------------------------------------------

As others have done, we'll begin by clarifying the distinctions between the different areas of "Ostium."

*   **Ostium Labs**: The company developing the Ostium protocol.
    
*   **The Ostium Protocol**: A suite of smart contracts that together enable synthetic on-chain price exposure to off-chain assets via oracle price feeds, facilitate peer-to-peer market making.
    
*   **The Ostium Interface**: A web interface that allows for easy interaction with the Ostium protocol. The interface is only one of many ways one may interact with the Ostium protocol.
    
*   **Ostium Governance**: While Ostium has yet to formally launch governance, community participation is paramount to the protocol's success and efforts are underway to enable a gradual transition towards increasingly community-led governance. This governance will play a critical role in the long-term development and success of the Ostium protocol.
    

[](#a-guide-to-our-documentation)

A Guide to Our Documentation


-------------------------------------------------------------------

We invite existing and prospective users to read our documentation here to gain an intuitive understanding of the protocol's mission, features, and underlying architecture. This hub will continue to evolve as further technical detail is shared in the coming months, containing a more detailed guide to our mechanism design, the assumptions underlying that design, and our smart contract architecture.

[NextOverview](/ostium-docs/getting-started/overview)

Last updated 5 months ago

![Page cover image](https://ostium-labs.gitbook.io/~gitbook/image?url=https%3A%2F%2F1263702948-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FCEDPLHGTrrpP1i2dbe3d%252Fuploads%252F5FMQ1OG41j8PjtKb8Bku%252FDocumentation%2520image%25202.png%3Falt%3Dmedia%26token%3D9e8364ff-0e1a-40db-94af-b2e00f125fcb&width=1248&dpr=4&quality=100&sign=78c5c7ea&sv=2)

---