arrow_back Back to Blog
24/7 Pricing

Session-Aware Oracles for 24/7 Markets


Introduction

Equity markets close at 4 PM Eastern. Perpetual markets on Hyperliquid do not. The oracle responsible for pricing must bridge that gap — or trading stops.

Traditional oracle infrastructure freezes when reference markets close. Prices remain static until reopening. Perpetual markets built on frozen feeds face two options: halt trading during off-hours or accept clustered liquidations when prices gap at market open. Neither is suitable.

SEDA's session-aware oracles are designed to solve this by encoding market-session logic directly at the data layer. A single continuous feed adjusts pricing behavior based on whether the underlying reference market is actively trading.

Why Traditional Oracles Fail for 24/7 Markets

Most blockchain oracle networks treat data feeds as always-active streams. They fetch a price from an external source, verify it through consensus, and push it onchain. This works for assets that trade around the clock — BTC, ETH, major forex pairs.

It breaks for everything else.

US equities trade 9:30 AM to 4 PM Eastern, Monday through Friday. Commodity futures have maintenance windows. Forex markets close on weekends. When the reference market closes, the external data source stops updating. The oracle has nothing new to fetch.

The Price Freeze Problem

If the oracle simply reports the last known price, the perpetual market becomes misaligned with reality. On-venue trading continues. Basis widens. Mark price diverges from then-current market conditions. Traders may get liquidated not because of market movement, but because of stale data.

The Reopening Gap Problem

When the reference market reopens, prices often gap. A stock closes at $100 on Friday and opens at $97 on Monday due to weekend news. If the oracle instantly updates to $97, every long position leveraged above a certain threshold may get liquidated simultaneously. Cascading liquidation may follow.

For a detailed breakdown of these failure modes and the architectural approaches builders use to address them, see Pricing Assets 24/7 Onchain.

What Session-Aware Oracles Are

A session-aware oracle is an oracle program that encodes market-session logic — open, closed, maintenance — directly at the data layer. It adjusts its pricing behavior based on the state of the underlying reference market.

During regular trading hours, the oracle fetches prices from external feeds. During off-hours, it switches to alternative pricing logic. The transition is programmatic, deterministic, and auditable.

How Do Session-Aware Oracles Work?

Session-aware oracles operate in distinct modes based on market state.

In-session mode: The oracle fetches data from one or more external sources (price feeds, exchange APIs, premium data providers). It applies aggregation logic if multiple sources are configured. It outputs the result onchain.

Off-session mode: The oracle stops fetching external prices. It computes pricing internally using self-referential logic — typically an exponentially weighted moving average (EWMA) derived from on-venue activity. Mark price continues to move, but more slowly than top-of-book, which may reduce liquidation volatility.

Transition mode: During market open and close, the oracle may apply smoothing to reduce the likelihood of concentrated liquidation events. This can include median-based blending, basis adjustment, or phased weighting shifts between sources.

Session state is determined by the oracle program itself. It encodes the reference market's schedule — trading hours, holidays, maintenance windows — and transitions modes accordingly. No external coordination required.

What Happens During Off-Hours?

During off-hours, the oracle program derives pricing from the perpetual market's own activity rather than an external reference.

The most common approach is self-referential EMA. The oracle tracks the impact-weighted mid-price of trades on the perpetual venue itself. It computes an exponentially weighted moving average of the difference between on-venue price and the last known reference price.

This allows mark price to respond to real trading activity while limiting sensitivity to liquidation volatility that may result from using raw top-of-book prices. The EMA period — often 150 seconds to 5 minutes — determines how quickly the oracle adapts to on-venue movement.

If on-venue trading is thin, mark price moves slowly. If a large imbalance develops, mark price adjusts gradually. The oracle program can provide continuous pricing without requiring an external data source.

How Is Off-Hours Pricing Calculated?

Off-hours pricing depends on the oracle program's configuration. The protocol operator defines the logic when deploying the oracle program.

Common patterns include:

How SEDA Implements Session-Aware Oracle Programs

SEDA is a programmable oracle infrastructure protocol. Developers write custom oracle programs — logic that determines how external data is sourced, aggregated, blended, and delivered onchain.

Session-aware pricing is a core capability. Oracle programs deployed through SEDA can encode market-session rules, switch data sources based on time of day, apply smoothing during transitions, and compute self-referential pricing when reference markets are closed.

Architecture

The SEDA pipeline separates data sourcing, logic application, and onchain delivery.

Data sourcing layer: Raw data providers (e.g., Pyth, dxFeed, Hyperliquid mark prices, API endpoints) supply inputs. SEDA integrates with 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 layer: The oracle program applies configured session rules, aggregation formulas, and blending logic. This is where session-aware behavior is encoded. Developers define in-session sources, off-session fallback methods, transition smoothing, and output formatting.

Delivery layer: Either a SEDA based solver, relayer or external relayer pushes the computed result onchain.

Production Implementations

Dreamcash (CASH) operates perpetual equity index markets including US500. During regular hours, the SEDA 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 on-venue price. This is designed to avoid price freezes and may reduce reopening gap risk.

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. The oracle fetches prices from Pyth and Hyperliquid, applies weighted blending (e.g., 95% Hyperliquid / 5% Pyth during normal hours), and outputs composite rates. Different products use different session policies. T-Bill yield perps use session-selected oracles with distinct on-hours, off-hours, and weekend rules. Funding rate perps use always-in-session 24/7 oracles.

Outcome Market runs prediction markets for financial events and sports. SEDA Fast (an offchain execution layer optimized for low-latency workflows) delivers onchain data typically within seconds (e.g., under five seconds). Custom oracle programs fetch data from external APIs, executor nodes reach consensus, and results are delivered onchain. Session-aware logic handles resolution during off-hours without requiring centralized intervention.

What This Means for Builders

Session-aware oracles can support perpetual market designs for any asset class, regardless of reference market hours.

Asset Classes This Enables

Integration Considerations

Builders define oracle logic when deploying through SEDA. Key configuration decisions include:

Oracle programs are permissionless. No approval required to deploy. Developers post data requests to SEDA from any EVM network and receive onchain-verified results.

Frequently Asked Questions

What is a session-aware oracle?

A session-aware oracle is an oracle program that can be configured to encode market-session logic (open, closed, maintenance) at the data layer. It adjusts pricing behavior based on whether the underlying reference market is actively trading. During regular hours it processes external feeds. During off-hours it switches to alternative pricing methods.

Why do perpetual markets need session-aware oracles?

Perpetual markets trade 24/7. Reference markets for most assets do not. Traditional oracles freeze when reference markets close, creating price staleness and reopening gap risk. Session-aware oracles provide continuous pricing by switching to self-referential logic during off-hours, which can avoid price freezes and may reduce liquidation clustering.

How does self-referential EMA work?

Self-referential EMA (exponentially weighted moving average) derives off-hours pricing from the perpetual market's own activity. The oracle tracks the impact-weighted mid-price of on-venue trades and computes an EWMA of the difference between on-venue price and the last known reference price. Mark price moves gradually in response to observed trading activity which may reduce sensitivity to volatility compared to raw top-of-book prices.

What asset classes can use session-aware oracles?

Any asset whose reference market operates on a limited schedule. This includes equity perpetuals, commodity perpetuals, fixed income perpetuals, volatility indices, interest rate derivatives, and alternative assets. Session-aware oracles can support 24/7 trading for assets that traditionally required market hours.

Can oracle programs switch between multiple data sources?

Oracle programs can be configured to fetch data from multiple providers and apply custom blending logic. Weighting can shift dynamically based on session state, data quality, or time of day. A program might use one source during regular hours, switch to a different source during off-hours, and apply weighted blending during transitions.

How is off-hours pricing validated?

Off-hours pricing is computed deterministically according to the configured logic in the oracle program based on on-venue activity. For price-based oracles, the logic is transparent and auditable — typically self-referential EMA or multi-source blending with published weights. For non-price data, executor nodes independently fetch data and reach consensus before onchain delivery.

About SEDA

SEDA is a programmable oracle infrastructure protocol. Developers write oracle programs that define how data is sourced, transformed, and delivered onchain. Session-aware pricing is a core pattern available to builders deploying oracle programs through SEDA. Production implementations are live on Hyperliquid's HyperEVM and HyperCore, Ethereum mainnet, and Base.

For implementation details, see the SEDA documentation. Network activity is visible at explorer.seda.xyz.


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 sources or resulting outputs, including price data. For important information, please refer to the Content Disclaimer.