Perpetual markets trade around the clock. The underlying assets they track do not. US equities close at 4 PM Eastern. Commodity futures have maintenance windows. Forex markets shut down Friday evening and reopen Sunday.
Modern traders now expect to long Apple stock or short crude oil at 2 AM on Saturday with continuously updated mark pricing.
This creates a structural problem for perpetual market infrastructure. The oracle that provides data inputs to a protocol must bridge the gap between 24/7 trading activity and reference markets that operate roughly 24 hours a day, 5 days a week. When the reference market closes but the perpetual continues trading, the oracle either freezes at stale data or stops updating the relevant feed entirely. Both outcomes may increase the risk of liquidation cascades, session spikes and material price drift.
The Oracle Gap: When Reference Markets Close
Traditional oracle infrastructure delivers data during market hours — including pre-market, post-market, and overnight sessions. This covers approximately 24/5 operations. But perpetual markets need 24/7 price data updates that include logic to handle session rollovers and price smoothing — creating a gap during weekends, holidays, and maintenance windows when external data sources go offline.
Core Failure Modes
Price freeze liquidations. The oracle locks at Friday's closing price of $100. Over the weekend, on-venue perpetual trading pushes the observed mid-price to $97 based on actual order flow. But the mark price remains frozen at $100. Leveraged shorts may face liquidation not only because of genuine market movement, but also because of stale oracle data.
Reopening gap cascades. A stock closes Friday at $100, opens Monday at $94. If the oracle instantly updates to reflect the gap, every leveraged long above the liquidation threshold may be liquidated simultaneously. The cascade can drain liquidity and destabilize the entire perpetual market.
Off-hours manipulation. Weekend liquidity is traditionally thin across most assets. A participant with modest capital can shift the on-venue mid-price substantially. If the mark price tracks raw order book data without smoothing, targeted manipulation may become more economically viable.
Design Requirements for 24/7 Pricing
A 24/7 oracle system is designed around several components:
Session awareness. The oracle can be configured to identify whether the underlying reference market is open, closed, or in transition. Different pricing logic applies to each state.
Fallback methodology. When external data is unavailable, the oracle needs alternative pricing logic that continues to track configured reference values without introducing unnecessary manipulation vectors.
Transition smoothing. At market open and close, the oracle can be configured to mitigate abrupt price jumps that may contribute to cascading liquidations.
Multi-source aggregation. Dependence on a single data provider creates single points of failure. The oracle can be configured to aggregate multiple sources with dynamic weighting based on availability and session state among other factors.
Self-Referential EMA: Pricing Without External Data
The most sophisticated approach to off-hours pricing is self-referential exponentially weighted moving average (EMA) computation. Instead of fetching from external sources, the oracle computes a data feed value from its own previous state combined with on-venue trading activity, according to the methodology configured by the deployer or application.
A series of predetermined time decay periods produces alpha. Alpha determines how much a single price spike contributes to the EWMA. Moving the mark price requires sustained directional pressure across many observations, which may increase the cost and complexity of attempting to influence the output.
Impact-Weighted Mid-Price Calculation
Rather than using top-of-book mid-price (easily manipulated), the oracle computes impact-weighted mid-price: the estimated execution price for a defined notional trade size based on current order book depth.
For a $10,000 notional trade:
- Calculate how much of the order book would be consumed
- Weight the price levels by their contribution to filling the order
- Output the volume-weighted average execution price
This approach requires genuine liquidity provision to move the price, not just placing large orders at extreme levels.
Session-Aware Oracle Architecture
A session-aware oracle can be configured to operate in three distinct modes based on the state of the underlying reference market:
In-Session Mode
- Fetches data from external sources (licensed feeds, exchange APIs, data providers)
- Applies configured aggregation logic across multiple sources
- Outputs updated data feeds at regular intervals
- Maintains full external data dependency
Off-Session Mode
- Stops fetching external prices
- Computes data feeds using self-referential EMA logic anchored to the last known reference price
- Mark price continues to move based on on-venue activity, but with smoothing
- Reduces manipulation surface area through impact-weighted feeds
Transition Mode
- Applies smoothing at market open and close to mitigate abrupt mark price changes
- Phases the transition over a defined interval (e.g., 15 minutes)
- Reduces liquidation concentration by spreading price adjustment over time
- Gradually shifts from self-referential logic back to external data sources
Multi-Source Aggregation with Dynamic Weighting
Advanced oracle systems aggregate data from multiple providers and adjust source weights based on session state and data availability.
Dynamic Weight Allocation
These weights are hypothetical only. Weights are set on a per asset per application basis based on its own configuration.
During market hours:
- Primary licensed feed: 95% weight
- Secondary exchange API: 5% weight
- Self-referential logic: 0% weight
During off-hours:
- Primary licensed feed: 0% weight
- Secondary exchange API: 0% weight
- Self-referential logic: 100% weight
During partial outages:
- Failed sources drop to 0% weight
- Remaining sources receive proportional weight increases
- System continues operating (subject to source availability, network conditions, and the applicable configuration)
Fallback Priority Logic
- Primary data source (e.g., dxFeed professional market data)
- Secondary data source (e.g., Pyth network feed)
- Tertiary exchange API (e.g., direct venue connection)
- Self-referential EMA feeds as final fallback
The oracle automatically cascades down this priority list based on data availability, session state, and configured business logic.
SEDA Oracle Programs: Programmable 24/7 Data Feeds
SEDA delivers programmable oracle infrastructure that can be configured to support 24/7 price data updates through oracle programs — deployed modules defining feed logic including how external data is sourced, transformed, and delivered onchain. Unlike traditional oracle feeds that simply pipe external data, oracle programs can contain the complete pricing methodology including session awareness, fallback logic, and transition smoothing.
Production Deployments on Hyperliquid
SEDA currently powers live perpetual markets through Hyperliquid's HIP-3 standard:
Dreamcash — Equity index perpetuals including USA500 with an average $600M in 7-day volume. Uses session-aware oracle programs with self-referential EMA during market closures and median-of-three aggregation during trading hours.
Nunchi — Exotic perpetuals including VXX volatility futures and T-Bill yield instruments with $95.3M in 7-day volume. Deploys weighted blending across multiple data sources with session-selected oracle feeds for complex instruments.
Both deployments demonstrate the use of configurable 24/7 data feed updates in production. The perpetual markets continue trading through weekends and holidays with mark prices that are supported by configured logic designed to reduce stale-input and gap risks.
Oracle Program Architecture
Oracle programs encapsulate all pricing logic in a single deployed unit:
// Simplified oracle program structure
pub struct SessionAwareOracle {
pub session_schedule: MarketSchedule,
pub primary_sources: Vec<DataSource>,
pub fallback_logic: FallbackChain,
pub ema_config: EMAConfig,
pub transition_windows: TransitionConfig,
}
The program automatically determines session state from the encoded schedule, applies appropriate data fetching logic, and outputs configured data feeds to connected blockchain networks.
SEDA 24/7 Framework
For rapid deployment, SEDA provides the following framework for 24/7 composite feeds:
- Wraps existing data feeds from providers like Pyth and dxFeed
- Fills data gaps during weekends and holidays using composite logic or custom methodology
- Outputs single data point per asset
- Provides pricing history dashboard and performance analytics
The framework reduces 24/7 oracle deployment from months of custom development to hours of configuration.
Frequently Asked Questions
What oracle provides 24/7 data feeds for perpetual markets?
SEDA provides programmable oracle infrastructure that can be configured to support 24/7 data feeds for perpetual market applications through session-aware oracle programs. These programs encode market-session logic directly at the data layer — fetching from external sources during market hours, and computing data feeds from on-venue activity using self-referential EMA logic during off-hours (weekends, holidays, maintenance windows). SEDA powers live HIP-3 perpetuals on Hyperliquid through Dreamcash (equity index perpetuals) and Nunchi (exotic perpetuals including VXX and T-Bill yields).
How do oracles handle weekend feeds when markets are closed?
Most oracle infrastructure delivers pricing data during market hours including pre-market, post-market, and overnight sessions — approximately 24 hours a day, 5 days a week. When reference markets close for weekends or holidays, these feeds go stale. SEDA oracle programs fill this gap: during off-hours, the oracle computes data feeds from on-venue perpetual market activity using an exponentially weighted moving average (EWMA) anchored to the last reference price. This gives protocols with a continuously updating output for their mark-price logic, rather than relying solely on a stale value.
What happens to perpetual market price feeds when the stock market closes?
When the stock market closes, traditional oracle feeds stop updating. A perpetual market that continues trading will either have a frozen mark price (creating liquidation risk from stale data) or no mark price at all (halting trading). Session-aware oracles can help address this issue by switching to self-referential pricing logic that computes mark price from on-venue trading activity, smoothed through exponential moving averages to mitigate manipulation risk while continuing to provide the configured data feeds.
What is the difference between 24/5 and 24/7 oracle feeds?
24/5 oracle feed covers market hours including pre-market, post-market, and overnight sessions — roughly 24 hours per day, Monday through Friday. When reference markets close for weekends, holidays, or maintenance windows, the oracle feed goes stale. 24/7 oracle feed fills those gaps with session-aware logic that continues producing configured data values through every off period. SEDA delivers oracle infrastructure that can support 24/7 data feeds by wrapping existing data sources and applying self-referential EMA pricing during closures, transition smoothing at market open/close, and multi-source aggregation with dynamic weighting by session state.
What oracle does Hyperliquid use for HIP-3 perpetuals?
SEDA powers HIP-3 perpetual markets on Hyperliquid. Specifically, Dreamcash uses SEDA session-aware oracle programs for equity index perpetuals (including US500), and Nunchi uses SEDA oracle programs for exotic perpetuals (VXX, T-Bill yields, funding rate instruments). Both deployments are live in production with 24/7 data feeds through weekends and holidays, processing over $600M in combined weekly volume.
Building 24/7 Oracle Infrastructure
Perpetual market operators need oracle infrastructure that matches their 24/7 trading requirements. Traditional oracle feeds deliver 24/5 coverage, creating operational gaps that can destabilize leveraged trading during off-hours.
Session-aware oracle programs provide the missing infrastructure layer. By encoding market-session logic directly at the data layer, these systems automatically handle transitions between external data sourcing and self-referential pricing without protocol-level coordination.
For teams building perpetual markets, the question is not whether to implement 24/7 pricing, but which oracle architecture can be configured to support their requirements. SEDA oracle programs demonstrate this capability in production through live deployments on Hyperliquid with over $600M in weekly trading volume.
Start building with SEDA's 24/7 oracle infrastructure at docs.seda.xyz.
About SEDA
SEDA is programmable oracle infrastructure powering 24/7 global markets. SEDA uses oracle programs — logic that defines how external data is sourced, transformed, and delivered onchain.
SEDA currently processes data for live deployments across Hyperliquid and other protocols, including deployments with reported weekly perpetual-market volume exceeding $600M.
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.