A perpetual market for USA500 futures trades around the clock. The S&P 500 index it tracks does not. The oracle that provides data inputs to the perpetual market has to bridge that gap continuously — through evenings, weekends, and holidays — or the market may face stale data.
This is the core infrastructure problem for any protocol trading perpetual contracts on assets with limited reference market hours. It is not unique to equities. It applies to commodity futures, fixed income instruments, volatility indices, and any other asset whose authoritative price source operates on a schedule.
The problem has three failure modes. Each has an architectural cause. And each has a solution — but not all solutions are equivalent.
Why Pricing Non-Crypto Assets Onchain Is Structurally Different
Most blockchain oracle infrastructure was designed for crypto assets. BTC, ETH, and major trading pairs generate continuous price data around the clock, across many exchanges, with no scheduled closures.
That assumption breaks when the underlying asset has reference market hours.
US equity markets trade from 9:30 AM to 4 PM Eastern, Monday through Friday. Commodity futures markets have maintenance windows. Forex markets close on weekends. When the reference market closes, the authoritative external data source stops updating. A standard oracle has nothing new to fetch.
On its own, this would not be a problem if trading also stopped. But perpetual markets are designed to trade continuously. Position holders can enter, exit, and be liquidated at any hour. The mark price used to calculate unrealized PnL and liquidation thresholds needs to be valid at 2 AM on a Saturday, not just during New York business hours.
The mismatch between the trading environment (24/7) and the oracle's data source (limited hours) creates three distinct failure modes.
Three Things That Break When Reference Markets Close
The price freeze
When an oracle has no new data to fetch, it has two choices: stop publishing, or keep publishing the last known price data.
Most oracle infrastructure defaults to the latter. The oracle continues to report the price data from the moment the reference market closed. This creates a frozen data input.
While the mark price is frozen, on-venue trading on the perpetual continues. Traders buy and sell based on their own views of market value — which may differ significantly from Friday's close by Sunday evening. The perpetual's on-venue price diverges from the oracle's stale data input. Basis widens.
The consequences compound over time. Traders with leveraged positions are measured against a mark price that no longer reflects current venue conditions. Some face liquidation not because of current market movement, but because of the gap between on-venue activity and a frozen oracle input. Conversely, traders who should be liquidated are not, because the mark price has not moved to reflect a genuinely deteriorating position.
The reopening gap
The price freeze creates a second, compounding problem at market open.
Equity markets frequently gap at the open. A stock that closed at $100 on Friday may open at $94 on Monday following a weekend earnings announcement. Commodity prices move on geopolitical events during exchange closures. Fixed income rates shift on macroeconomic data published outside of trading hours.
When the reference market reopens and the oracle begins publishing live data again, it transitions from the last-known price to the current market price. If that gap is significant — from $100 to $94, for example — every long position leveraged beyond a certain threshold may get liquidated simultaneously.
Cascading liquidations may follow. Positions that were adequately collateralized against the frozen mark price are suddenly underwater. Liquidation bots execute simultaneously. Liquidity is consumed at the worst possible moment.
This is not an edge case. It can be a predictable structural risk for any perpetual market using standard oracle infrastructure with reference markets that close.
Off-hours pricing uncertainty
The third failure mode is less acute but more persistent.
When reference markets are closed, on-venue trading on the perpetual continues without an external pricing anchor. The mark price has to come from somewhere. If it comes from raw on-venue order flow — the mid-price of the perpetual's own order book — it becomes susceptible to manipulation by actors who can move a thin market during low-liquidity hours.
A large participant can shift the on-venue mid-price with relatively modest capital during off-hours, potentially triggering liquidations at artificially moved mark prices. This risk can be particularly acute for smaller or newer perpetual markets where off-hours liquidity is thin.
Three Approaches Builders Use
These are the architectural approaches protocols have used to address the pricing problem. Each has genuine trade-offs.
Halt trading during off-hours
The simplest approach. When the reference market closes, the protocol pauses trading. When it reopens, trading resumes.
This eliminates all three failure modes by removing the situation in which they occur. No off-hours trading means no frozen mark price problem, no reopening gap liquidations, and no off-hours manipulation risk.
The trade-off is user experience and competitive positioning. Traders cannot manage positions during closures. They cannot enter or exit at news-driven price changes. A market that is unavailable for sixteen hours out of every twenty-four is not a 24/7 perpetual market in any meaningful sense.
Manual or centralized override
Some protocols address off-hours pricing through direct team intervention — manually adjusting mark price parameters, activating pause mechanisms, or applying internal models to keep mark price aligned with fair value during closures.
This can work at small scale. It introduces operational requirements: someone has to be available at 3 AM on a Sunday to respond to market events. It introduces centralization risk: the mark price is now dependent on the judgment and availability of the protocol team, not deterministic infrastructure. It does not scale across multiple markets or asset classes.
Session-aware oracle programs
The third approach addresses the pricing problem at the infrastructure layer rather than the application layer.
A session-aware oracle program encodes market-session logic — open, closed, maintenance windows, transitions — directly into the oracle. The oracle can be configured to adjust its data processing behavior based on the state of the underlying reference market. During regular hours, it fetches data from external sources. During off-hours, it switches to alternative data processing logic that derives data feed values from on-venue activity rather than an external feed.
The transition between modes is programmatic, not manual. The oracle program handles it automatically based on the session schedule encoded into the program.
This one approach is designed to mitigate all three failure modes without halting trading or introducing centralized decision-making.
| Approach | Mitigates price freeze | Mitigates reopening gap risk | Preserves 24/7 trading | Avoids centralization |
|---|---|---|---|---|
| Halt trading | Yes | Yes | No | Yes |
| Manual override | Partially | Partially | Yes | No |
| Session-aware oracle programs | Yes | Yes | Yes | Yes |
How Session-Aware Oracle Programs Work
A session-aware oracle program operates in distinct modes based on a defined session schedule.
In-session mode. When the reference market is open, the oracle program fetches data from external sources — price feeds, exchange APIs, premium data providers. It applies any configured aggregation logic and publishes the result onchain. This is standard oracle behavior.
Off-session mode. When the reference market is closed, the oracle program stops fetching from external sources. Instead, it computes data feed values using on-venue activity — typically through a self-referential method that derives data feed values from the perpetual's own trading data rather than an absent external feed.
The most common off-session approach is a form of exponentially weighted moving average derived from on-venue impact prices. Mark price moves in response to observed trading activity but more slowly than raw top-of-book, reducing the risk of mark price manipulation through thin off-hours order flow. The oracle program anchors to the last known reference price and adjusts gradually based on on-venue conditions.
Transition handling. At market open and close, the oracle program may apply smoothing logic to mitigate abrupt mark price changes. A market that closed at $100 and reopens at $94 does not necessarily need to update the mark price instantly. The session-aware program can phase the transition over a defined interval — reducing the concentration of liquidations that would otherwise occur at the exact moment of reopening.
Off-Hours Methodologies
When the oracle program switches to off-session mode, it needs a way to continue computing data feed values that can support the protocol's mark price methodology. Three patterns are used in production.
Self-referential pricing. The oracle program uses its own previous output as the pricing anchor and adjusts based on on-venue activity. Specifically, it tracks the impact-weighted mid-price of trades on the perpetual itself and computes an exponentially weighted moving average of the difference between on-venue price and the last known reference price. Mark price responds to observed real trading without becoming susceptible to manipulation through raw order-book prices.
This is the most widely used off-hours pricing approach for equity and commodity perpetuals. The EMA period — often between 150 seconds and several minutes — determines how quickly mark price adapts to on-venue movement. Longer periods provide more stability. Shorter periods are more responsive but increase manipulation risk in thin markets.
Multi-source blending. For some asset classes, alternative data sources are available even when the primary reference market is closed. A tokenized equity perpetual might fall back to a 24/7 trading venue that provides a continuous price — even if that venue has different liquidity characteristics than the primary exchange. The oracle program fetches from multiple sources and applies weighted blending logic, shifting weights based on session state.
During regular hours, the oracle program might weight the primary exchange price data at 95% and a secondary source at 5% for calibration. During off-hours, those weights might invert — or the oracle might shift entirely to the secondary source until the primary reopens.
Session-selected oracles. Some products use different oracle configurations for different sessions. A T-Bill yield perpetual might use one oracle program for weekdays, a different configuration for weekends, and a third for US market holidays. Each session configuration specifies its own data sources, aggregation logic, and output parameters. This approach is more complex to configure but provides more precise control for products where session-specific behavior matters.
How SEDA Implements This
SEDA is a layer-one blockchain protocol for programmable oracle infrastructure. Developers write oracle programs — logic that defines how external data is sourced, transformed, and delivered onchain.
Session-aware pricing logic is a core pattern within this model. Oracle programs deployed through SEDA can encode market-session rules, switch data sources based on time and session state, apply transition smoothing, and compute self-referential data feeds during off-hours. The logic is defined by the developer. SEDA executes it across the network.
The architecture separates three concerns:
- Data sourcing. Raw data providers — Pyth, dxFeed, Hyperliquid mark prices, proprietary data APIs — supply inputs. SEDA provides access to 11M+ symbols across equities, commodities, crypto, forex, and alternative assets through partners including dxFeed (3.5M+ instruments), Caplight (370+ symbols), Nobi Labs (1,862+ symbols). Availability depends on data provider licensing and network conditions.
- Logic application. The oracle program applies session rules, aggregation formulas, and pricing methodology. This is where session-aware behavior is encoded — which sources to use during regular hours, which pricing method to apply during off-hours, how to handle transitions.
- Onchain delivery. A relayer pushes the computed result onchain. SEDA operates across any chain.
Each stage can be audited independently. The session logic is encoded in the oracle program itself — not managed manually by the protocol team after deployment.
Production implementations:
Dreamcash (CASH) runs perpetual equity index markets including US500. During regular hours, the oracle program processes Pyth price feeds. During off-hours, it switches to self-referential EMA pricing derived from on-venue activity. Mark price is computed as the median of three inputs: oracle price, oracle price plus smoothed basis (150-second EWMA), and robust on-venue price. The approach is designed to mitigate price freezes and reduces reopening gap risks.
Nunchi (YEX Perps) offers exotic perpetuals on Hyperliquid including volatility (VXX), T-Bill yields, and funding rates. SEDA acts as the aggregation and logic layer across these products. Different products use different session policies: T-Bill yield perps use session-selected oracles with distinct rules for on-hours, off-hours, and weekends. Funding rate perps use always-in-session 24/7 oracles. The oracle program fetches from Pyth and Hyperliquid and applies weighted blending, with weights shifting based on session state.
What This Means for Builders
Session-aware oracle infrastructure enables perpetual markets for any asset class, regardless of reference market hours, by providing configurable data feed logic.
Asset classes this unlocks:
- Equity perpetuals. Individual stocks and indices whose reference markets operate on exchange hours. US equities, international equities, and sector-specific indices.
- Commodity perpetuals. Oil, natural gas, gold, agricultural products — assets with futures market sessions and maintenance windows.
- Fixed income perpetuals. T-Bill yields, bond spreads, interest rate derivatives — products that reference scheduled fixings or exchange-traded instruments.
- Volatility and alternative assets. VXX, interest rate derivatives, and other instruments whose reference data is generated on a limited schedule.
Key configuration decisions when deploying:
- In-session data sources. Which feeds or APIs to use during regular market hours. Multiple sources can be configured for redundancy.
- Off-session pricing methodology. Self-referential EMA, multi-source blending, or session-selected oracle. The choice depends on the asset class, available alternative sources, and acceptable mark price volatility during off-hours.
- Transition handling. Whether to apply smoothing at market open and close, and over what interval. Longer transition windows may reduce reopening gap liquidations. Shorter windows may keep mark price more responsive.
- Output format. Mark price, index price, funding rate, or custom fields, as defined by the deployer.
Oracle programs are permissionless. No approval is required to deploy. Developers post data requests to SEDA Core from any EVM network and receive onchain-verified results.
Frequently Asked Questions
What does providing data for pricing assets 24/7 onchain mean?
24/7 onchain data support means providing continuously updating data outputs that can be used by protocols in their configured pricing logic — including for instruments whose reference markets operate on limited schedules — so that onchain perpetual markets can function at any hour without halting or depending on manual intervention.
Why can't standard oracle infrastructure support assets 24/7?
Standard oracle infrastructure fetches price data from external sources. When the reference market closes — equity markets after 4 PM Eastern, commodity futures during maintenance windows, forex on weekends — those sources stop updating. The oracle has nothing new to report. It either freezes the last known price or stops publishing. Neither is adequate for a perpetual market that continues trading through off-hours.
What is the price freeze problem?
A price freeze occurs when an oracle continues to report the last known price after the reference market has closed. The frozen mark price diverges from on-venue trading activity. Traders may face liquidations based on stale data. The mark price no longer reflects current venue conditions, but it is still used to calculate unrealized PnL and liquidation thresholds.
What is the reopening gap problem?
The reopening gap problem occurs when an oracle transitions from a frozen off-hours price to a live market price at open, and that transition is a significant price jump. A stock that closed at $100 on Friday and opens at $94 on Monday forces an instant oracle update. Every long position leveraged above a certain threshold may be liquidated simultaneously. The problem is structural — the frozen price during off-hours creates a compressed risk that releases all at once when the reference market reopens.
How do perpetual markets price assets when the reference market is closed?
The two main approaches are self-referential pricing and multi-source blending. Self-referential pricing derives mark price from the perpetual market's own on-venue activity, using an exponentially weighted moving average to limit mark price volatility. Multi-source blending uses alternative data sources — such as 24/7 trading venues — that continue to generate prices even when the primary reference market is closed. Session-aware oracle programs can be configured to implement these approaches programmatically, without manual intervention.
What asset classes can trade 24/7 with session-aware oracle programs?
Any asset whose reference market operates on a limited schedule can use session-aware oracle infrastructure. This includes equity perpetuals (stocks, indices), commodity perpetuals (oil, gold, agricultural products), fixed income perpetuals (T-Bill yields, bond spreads), and alternative assets (volatility indices, interest rate derivatives). The oracle program encodes the specific session schedule and data behavior for each asset.
Disclaimer: This article is provided for informational purposes only and does not constitute legal, financial, tax, investment, or other professional advice. All information is provided on an "as is" basis, without warranties or representations of any kind. SEDA provides infrastructure only and may rely on third parties for data feeds; SEDA makes no representations or guarantees regarding the availability, accuracy, completeness, reliability, or timeliness of any data, including price data. For important information, please refer to the Content Disclaimer.