In the design space of RWA protocols, tradeoffs typically include permissioned usage, trust assumptions, mandatory KYC, and lack of composability — all posing limitations hindering usage and adoption in the crypto space.
Naturally, protocols have started tackling these issues but only with partial success. Examples like MakerDAO or Flux Finance introduced a permissionless aspect: by issuing stablecoins against tokenized assets as collateral, users are able to earn yield (i.e. borrow interest) from accredited investors holding tokenized RWAs. As we highlighted in our The Year Ahead for DeFi 2024 report, there’s one major drawback: the borrow rate is not a function of the underlying yield. As a result, the interest rate earned by retail will never exceed the underlying yield. Meaning, this design is an unattractive solution in a rising rate environment and only useful for increasing the collateral pool.
In the Year Ahead report, we also mentioned two projects ambitiously tackling the aforementioned issues: Backed Finance and Superstate. Backed Finance offers tokenized fixed income and equities with permissionless transferability on-chain, while Superstate focuses on tokenizing treasuries for the US market, catering to accredited investors to gain a strong foothold in the tokenized treasuries market. Following up on this, I’d like to highlight a third RWA protocol that stands out — Ostium.
Ostium is a DEX built on Arbitrum offering synthetic perps for RWAs and crypto. The protocol is backed by $3.5m in funding raised in October, 2023. Live on the Sepolia testnet, users can get exposure in a fully permissionless and non-custodial manner to commodities, crypto, forex, and indices. The following perp markets are currently available:
Such a diverse suite of RWAs perps poses two main questions:
- How are price feeds for RWAs efficiently sourced and maintained?
- How is liquidity provided?
Ostium’s Architecture
The answers to both questions lie in the trading infrastructure Ostium has developed. At a higher level, the trading engine consists of a custom oracle for RWAs, an automated keeper system, a dual pool liquidity solution, and a dynamic fee structure. Each component has unique trade-offs and solves specific challenges faced by a perp DEX aiming to bring perps for RWAs on-chain.
Price Feeds
Ostium is sourcing price feeds from two providers: Stork & Chainlink. Using Chainlink for data streams to price crypto assets is pretty common, but the partnership with Stork is where things get interesting.
Due to the nature of RWAs, unique challenges arise. To name a few, you have to account for out-of-market hours, price gaps at market opens, and expiry of future contracts. To tackle this, Ostium decided to implement a custom oracle solution and developed an in-house pull-based RWA oracle system. Market hours data, price feed aggregation, and data sourcing is all handled by Ostium’s own software. For this custom oracle, the node infrastructure itself is managed and operated by Stork.
Stork is a decentralized open data marketplace providing on and off-chain price feeds for perps. At a higher level, Stork is running a network of data publishers capable of signing verifications on blockchains while performing initial processing off-chain. Meaning, price updates are only pushed on-chain when needed for the respective asset. As a result, performance and speed are more competitive with TradFi achieving latency of ~50ms on the testnet.
Using push-based oracles for high-throughput protocols that constantly update prices across countless markets would be extremely expensive. Therefore, Ostium’s pull-based RWA oracle harmonizes well with Storks infra by only pushing price updates on-chain when needed for trade execution.
On top of this, Ostium uses an automated keeper system, Gelato Functions, for RWAs. To execute automated orders, an entity must monitor price requests and open orders – both responsibilities are assumed by Gelato functions. They are specifically developed to trigger liquidations and limit orders (i.e. stop losses, take profits, and stop limit orders). Chainlink automations inherit the same role to enable seamless trading for crypto perps.
The sequence of operations is as follows:
Source: Ostium Gitbook
Shared Liquidity Layer
In the traditional perp DEX design utilizing pools instead of orderbooks, liquidity providers and traders are direct counterparties: When traders profit, LPs incur losses, and vice versa, when traders lose, LPs profit. During periods of sustained market trends or high volatility, LPs typically end up on the short end of the stick. Of course, there’s usually a fee structure in place that primarily benefits LPs, but they still bear all the counterparty risk, creating an adversarial dynamic between traders and LPs.
In DYDX Valuation Analysis & DEX Perps Comparison”, our DeFi team examined the protocol designs of Synthetix, GMX, dYdX, Vertex, and others, dissecting their various approaches and how they address this issue. Ostium takes a novel approach using a unique fee structure in conjunction with a design they have dubbed the “Shared Liquidity Layer”, short SLL.
At a higher level, the SLL is Ostium’s infra for pooled trade settlement and liquidity aggregation. Trade settlement can be prioritized between two settlement layers: The “Liquidity Buffer” and the “Market Making Vault”. In other words, there are two distinct liquidity pools.
The Liquidity Buffer stands at the vanguard of settling trades and is by default first in line to provide liquidity over the Market Making Vault. It extends capital to traders closing profitable trades and accrues capital from traders closing losing trades.
Simply put, the Liquidity Buffer takes loses first and only when it is fully depleted, capital from the Market Making Vault is used to settle trades. Bottom line: There are two settlement layers and the first layer, the Liquidity Buffer, is always prioritized unless its fully drained and can no longer extend liquidity. LPs cannot deposit into the Liquidity Buffer and it does not accrue any trading fees.
This design has one major benefit — you can take trades without the need for a direct counterparty. For example, you can punt soybean perps using max leverage without the need for a dedicated LP pool. This makes Ostium more scalable and allows the protocol to make markets for niche long-tail and illiquid assets.
Unlike the Liquidity Buffer, users have the option to supply liquidity to the Market Making Vault and, in exchange, receive the protocols’ LP tokens, OLP. These tokens represent their proportional share within the vault. In the case that the Liquidity Buffer is depleted, the Market Making Vault provides liquidity to traders and in return for taking on this risk, LPs receive a share of Ostium’s protocol fees. In particular, LPs receive 50% of the opening fees collected for each trade and 100% of liquidation rewards. Generated fees are accrued directly to OLP token holders.
To bootstrap their mainnet vault, Ostium is running the “Deposit Derby” campaign ending on August 1, 2024. Users can deposit USDC in the Market Making Vault for the scheduled mainnet launch. And as a reward for being early supporters and liquidity providers, Ostium offers boosted yields. The minimum lockup period is 45 days and the maximum is 365 days. The longer users lock their tokens, the higher the OLP token boost they receive.
Fee Structure
Ostium’s fee structure can be broken down as follows:
- Opening Fees
By default, Ostium charges a fee for each trade that is being opened. This opening fee is a function of the position size, leverage, and asset on the trader’s side and based on skew and utilization on the protocol’s side. Any trade that increases delta exposure for the Liquidity Buffer has a higher base fee due to its skew-increasing nature. Additionally, Ostium charges a flat oracle fee of $0.50 for each opened trade covering price fetching and order costs.
2. Live Fees
There are two fees that may be charged while a trade is open: Funding fees & volatility fees. Ostium’s funding fee is designed to be zero-sum and compounds with each block on Arbitrum. At a higher level, it is calculated based on the OI skew. For example, if the total open interest for long positions is greater than the total open interest for short positions on a specific asset, the OI skew favors longs. Accruing to or depleting a trader’s PnL, the funding rate is settled upon position closure, making it the key driver behind equilibrium of short OI and long OI.
The volatility fee accounts for the effects of an asset’s volatility on the Liquidity Buffer. Similar to the funding fee, it compounds with each block and is synthetically charged on a trader’s entire position size. This sounds confusing, but when simplified it’s pretty straightforward: The higher an asset’s volatility, the higher the risk for the Liquidity Buffer to be depleted — To negate this risk during volatile periods, a fee is charged that increases with the average volatility of an asset.
3. Closing Fees
Lastly, Ostium only charges a closing fee when a position is liquidated. Meaning, when a take profit or stop loss is hit or the trader manually closes a position, no fees are charged.
For liquidations, Ostium has decided to charge a liquidation fee that triggers when a trader’s collateral has decreased by 90%. If a DEX offering perps fails to liquidate a position in time and the collateral value becomes negative, all excess losses are incurred as bad debt by the protocol itself. Additionally, liquidation fees must account for and cover variable costs associated with price feed latency, execution delays, and asset volatility. Hence, positions are liquidated before their “actual liquidation price”, a standard practice for pool-based DEXes but disadvantageous for traders.
The keeper bots that automatically liquidate positions transfer the remaining 10% of the position’s collateral to the Market Making Vault. As mentioned earlier, LPs receive 100% of liquidations rewards, the keeper bots do not earn a share. Instead, they are compensated by the oracle fee charged when a trade is opened.
In my opinion, the liquidation threshold for less volatile and fairly liquid markets could be set to single digits to better accommodate traders while still accounting for the associated risks. For what it’s worth, I have shared this feedback with the team, who indicated that adjusting the threshold on a per-asset basis would be strongly considered based on where it ranks in trader feedback.
Putting it All Together
Source: Ostium Gitbook
To reiterate, Ostium’s infrastructure minimizes the adversarial relationship between traders and LPs with beneficial downstream effects. The Liquidity Buffer acts as the first instance to extend liquidity, and the Market Making Vault as the second. As such, LPs of the Market Making Vault are not always immediate counterparties, which reduces the net directional exposure of trades taken.
To complete the incentive mechanisms for the protocol’s trading engine, Ostium has a dynamic fee structure. Different fees are in place to help Ostium move OI skew towards equilibrium, reward counterparties for the risks they assume, generate protocol revenue, and ensure perps track the price of the underlying asset.
For the past two weeks, I’ve been testing the dApp by participating in the trading competition. Despite being on testnet, Ostium’s UI and UX are surprisingly smooth. The interface closely resembles that of a CEX featuring clean, customizable widgets that allow for a personalized trading dashboard.
Although the protocol is fully on-chain, the UX is nearly completely abstracted away from the typical tedious on-chain experience. Orders are executed seamlessly, with a standard order confirmation pop-up providing an overview of all essential trade details before entering a position.
Since the collapse of FTX, I’ve transitioned almost entirely to trading on DEXes. Being a strong advocate for permissionless and decentralized trading, I believe DEXes will continue to close the competitive gap to CEXes in terms of speed, efficiency, liquidity, and overall UX. Combined with my bullishness on the potential of tokenized assets, I’m excited to see how Ostium’s RWA perps fare once the protocol is live on the Arbitrum mainnet.