Perpetual markets trade 24/7, but their underlying reference assets — equities, commodities, and other traditional assets — only trade during market hours. This creates a structural mismatch. When stock markets close for weekends, holidays, or maintenance windows, equity perpetuals continue trading. Where does the mark price come from when the reference market goes dark?
The problem extends beyond weekends. Maintenance windows, early holiday closures, and unexpected market halts all create gaps where perpetual markets need data inputs for their pricing logic but reference data stops flowing. Traditional oracle infrastructure delivers data during market hours — approximately 24/5 coverage — but leaves builders to solve the off-hours gap, session changes and price smoothing themselves.
Hyperliquid's HIP-3 perpetual markets demonstrate one solution: session-aware oracle infrastructure that can be configured to switch between external reference data during market hours and self-referential computation during off-hours. This article examines how oracle infrastructure handles the 24/5 to 24/7 transition, the technical requirements for continuous data feeds, and production implementations supporting live perpetual markets.
The 24/5 to 24/7 Gap
Most financial markets operate on session schedules — specific hours when trading occurs, with defined closures for weekends, holidays, and maintenance. Equity markets typically trade Monday through Friday with some extended hours. Commodities markets have their own schedules. Fixed income markets vary by instrument type and geography.
Oracle infrastructure traditionally mirrors these schedules. When a reference market is active, the oracle fetches and relays pricing data. When the reference market closes, the oracle feed goes stale — either freezing at the last known price or stopping updates entirely. This works fine for applications that only need data inputs during market hours.
Perpetual markets break this model. A perpetual contract representing the S&P 500 doesn't stop trading when US equity markets close for the weekend. Traders continue taking positions, funding payments continue accruing, and liquidations may still occur. The market needs a mark price that reflects current trading conditions, not a frozen reference from Friday's close.
Failure Modes Without 24/7 Pricing
When perpetual markets operate with stale oracle feeds, several failure modes may arise:
Stale liquidations: A position that was healthy at market close may become liquidatable during off-hours if trading activity occurs on the perpetual venue itself. If the oracle price hasn't updated, the liquidation engine operates on outdated information.
Funding rate distortion: Funding rates typically depend on the difference between perpetual price and reference price. If the reference price is frozen while the perpetual continues trading, funding calculations become meaningless.
Arbitrage opportunities: Sophisticated traders can exploit the gap between stale oracle prices and live perpetual prices, extracting value from other market participants who assume pricing reflects current conditions.
Risk management blindness: Portfolio risk calculations, margin requirements, and position sizing all depend on current data inputs and the protocol's mark-price methodology. Stale pricing creates risk management blind spots during off-hours.
Technical Requirements for 24/7 Perpetual Pricing
Continuous pricing for perpetual markets requires oracle infrastructure that goes beyond simple data relay. The system must intelligently handle session transitions, maintain data feed continuity, and help mitigate manipulation during low-liquidity periods.
Session-Aware Logic
The oracle program must encode knowledge of when reference markets are open or closed. This isn't simply a matter of time zones — market schedules include early closures, holiday schedules, maintenance windows, and trading halts that vary by asset and jurisdiction.
Session-aware logic switches behavior based on market state:
- Open sessions: Fetch data from external reference sources
- Closed sessions: Compute data feeds from on-venue perpetual activity
- Transition periods: Apply smoothing to help mitigate mark price gaps at open/close
Self-Referential Computation During Off-Hours
When reference markets are closed, the oracle program must generate data feeds from the perpetual market's own trading activity or create composite data feeds from multiple venues. This requires careful methodology to mitigate manipulation and maintain reasonable data-output behavior.
Common approaches include:
- Time-weighted averaging: Smooth recent perpetual trading activity over a defined window
- Exponential moving averages: Weight recent activity more heavily while maintaining data-output continuity
- Bid-ask midpoint tracking: Use the best bid/offer on the perpetual market as a data anchor
- Volume-weighted computation: Weight data inputs by trading volume to reduce manipulation risk
Multi-Source Aggregation with Dynamic Weighting
24/7 data feed logic often combines multiple methodologies and sources, adjusting weights based on session state and data quality. During market hours, external reference feeds receive high weight. During off-hours, on-venue activity receives higher weight. During transition periods, the system blends between methodologies.
The aggregation must handle:
- Source reliability scoring: Automatic detection and down-weighting of stale or suspicious feeds
- Outlier detection: Filtering price spikes or gaps that appear inconsistent with the configured methodology
- Cross-validation: Comparing different pricing methodologies to identify potential issues
Transition Smoothing
Market opens and closes create potential for abrupt mark price changes as the oracle switches between methodologies. If the perpetual market has drifted significantly from reference pricing during off-hours, an instantaneous switch could create artificial liquidations or funding rate spikes.
Smoothing mechanisms include:
- Gradual weight transitions: Slowly shifting from off-hours methodology to reference data over several minutes after market open
- Maximum change limits: Capping how much the mark price can change in a single oracle update
- Convergence incentives: Designing funding rates to gradually pull perpetual prices toward reference levels after market reopening
Oracle Programs: Programmable Session Logic
Session-aware 24/7 data feeds require more sophisticated oracle infrastructure than simple data relay. The oracle must execute custom logic, maintain state across updates, and make decisions based on market conditions and timing.
Oracle programs provide this capability. Unlike traditional oracle feeds that transport pre-existing prices, oracle programs are deployed code that defines how external data should be sourced, transformed, and aggregated into output data feeds. The oracle network executes these programs and reaches consensus on the results.
For perpetual markets, oracle programs encode the complete data feed methodology:
- External data source selection and weighting
- Session detection logic for each reference market
- Self-referential computation during off-hours
- Transition smoothing parameters
- Outlier detection and filtering rules
SEDA Implementation for HIP-3 Perpetuals
SEDA provides oracle infrastructure used by live HIP-3 perpetual markets on Hyperliquid through session-aware oracle programs deployed by Dreamcash and Nunchi. These implementations demonstrate 24/7 data feeds in production.
Dreamcash Equity Index Perpetuals Dreamcash operates equity index perpetuals including USA500 (S&P 500 proxy) using SEDA oracle programs. The implementation sources reference pricing from futures markets during trading hours and applies self-referential EMA logic during weekends and holidays. Trading volume for Dreamcash perpetuals reached $700.7 million over the past seven days, demonstrating market activity during both market hours and off-periods.
The oracle program uses a median-of-three aggregation model: it combines price data from three different methodologies and takes the median value to reduce single-source manipulation risk. During US equity market hours, the three inputs are futures-based reference prices from different providers. During off-hours, one input switches to time-weighted perpetual market activity while the other two continue providing futures-based anchoring where available.
Nunchi Exotic Perpetuals Nunchi operates exotic perpetual markets including VXX (volatility) and T-Bill yield instruments using SEDA oracle programs. These markets present additional challenges because the underlying reference instruments have limited trading hours and lower liquidity than major equity indices.
The oracle program applies weighted blending between multiple pricing methodologies, with dynamic weight adjustment based on session state and source reliability. During reference market hours, external feeds receive 70-80% weight. During off-hours, on-venue perpetual activity receives 60% weight with the remainder coming from time-decayed reference anchors. Nunchi perpetuals generated $267.4 million in trading volume over the past seven days.
Production Metrics and Proof Points
Hyperliquid HIP-3 perpetual markets using SEDA's oracle infrastructure have processed significant trading volume across market hours and off-periods:
- Combined 7-day volume: $979.9 million across 32 perpetual markets
- Dreamcash markets: $700.7 million in equity index perpetual volume
- Nunchi markets: $267.4 million in exotic perpetual volume
- Continuous operation: 24/7 pricing data through weekends, holidays, and maintenance windows
The oracle programs have maintained data feed continuity through multiple weekend periods, holiday closures, and reference market maintenance windows without requiring manual intervention or emergency procedures.
Technical Architecture Considerations
Building oracle infrastructure for 24/7 perpetual markets requires careful attention to several technical factors that don't apply to simpler price relay systems.
Latency and Update Frequency
Perpetual markets may require different update frequencies during market hours versus off-hours. During active trading sessions, frequent oracle updates may provide better data freshness and risk management. During off-hours with limited activity, less frequent updates may be acceptable and more cost-effective.
Oracle programs can implement dynamic update scheduling:
- High-frequency updates during market hours: Sub-second for active reference markets
- Medium-frequency updates during off-hours: Every 1-2 seconds based on perpetual market activity
- Event-triggered updates: Immediate updates when significant price movements or volume spikes occur
Data Source Reliability and Failover
24/7 operation requires robust handling of data source failures, maintenance windows, and degraded data quality. Oracle programs must detect these conditions and adjust methodology accordingly.
Reliability mechanisms include:
- Health monitoring: Continuous assessment of each data source's update frequency, spread consistency, and deviation from consensus
- Automatic failover: Switching to backup data sources when primary feeds fail
- Graceful degradation: Maintaining data feed operation even when some data sources are unavailable
FAQ
What oracle infrastructure is available on Hyperliquid for HIP-3 perpetuals?
Hyperliquid HIP-3 perpetual markets can access SEDA oracle infrastructure for 24/7 data feed support. For example, Dreamcash deploys SEDA oracle programs for equity index perpetuals (including USA500), and Nunchi uses SEDA oracle programs for exotic perpetuals including VXX and T-Bill yield instruments. Both implementations are live in production, providing session-aware data feeds that continue through weekends, holidays, and maintenance windows.
How do oracle programs handle data feeds when reference markets are closed?
Oracle programs encode session-aware logic that automatically switches between external reference data during market hours and self-referential computation during off-hours. When reference markets close, the oracle program computes data feeds from on-venue perpetual trading activity using exponentially weighted moving averages anchored to the last known reference price. This maintains data feed continuity without relying on stale external feeds.
What happens during market transition periods at open and close?
Oracle programs can be configured to apply transition smoothing to help mitigate abrupt mark price changes when switching between methodologies. Rather than instantaneous switches that could create artificial liquidations, the programs gradually blend from off-hours methodology to reference data over several minutes after market reopening. Maximum change limits can limit excessive price jumps in a single oracle update.
How do session-aware oracles help mitigate manipulation during low-liquidity periods?
Session-aware oracle programs use several mechanisms designed to mitigate manipulation during off-hours when perpetual market liquidity may be limited: median-of-three aggregation takes the middle value from three different pricing methodologies; volume-weighted computation reduces the impact of low-volume trades; outlier detection automatically filters price spikes that don't reflect market conditions; and time-weighted averaging smooths short-term manipulation attempts over longer windows.
Building 24/7 Perpetual Markets
Oracle infrastructure that bridges the 24/5 to 24/7 gap enables perpetual markets to operate continuously without relying solely on stale reference data during off-hours. Session-aware oracle programs provide the programmable logic needed to handle complex timing requirements, source switching, and methodology transitions.
Production implementations on Hyperliquid demonstrate that sophisticated perpetual markets can use configurable oracle programs to support continuous data feed operation around the clock. The combination of external reference data during market hours and self-referential computation during off-hours maintains data feed continuity while helping mitigate stale-inputs and manipulation risks.
Builders developing perpetual markets should evaluate oracle infrastructure based on its ability to handle session logic, not just data transport capability. The technical requirements for 24/7 pricing extend far beyond simple price feeds.
Ready to implement 24/7 oracle infrastructure for your perpetual markets? Contact the team at seda.xyz/contact.
SEDA is programmable oracle infrastructure powering 24/7 global markets. The network executes oracle programs — deployed logic that defines how external data is sourced, transformed, and delivered onchain. SEDA oracle programs are used by live perpetual markets on Hyperliquid to support session-aware data feeds that continue through weekends, holidays, and maintenance windows. Learn more at 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 does not control or guarantee third-party data sources or event outcomes.