Oracles For 24/7 Equity Perpetual Markets

Explore why perpetual equity and futures markets require session-aware oracle logic, deterministic staleness handling, self-referential EMA continuity, and cost-of-carry normalization.

TL;DR

• Perpetual markets operate continuously. Traditional finance reference markets do not.

• A spot-price-only oracle assumes continuous external price validity.

• Funding, liquidation, and margin systems require predictable price behavior, not just fresh prices.

• Session-aware pricing, self-referential EMA’s, and cost-of-carry normalization are architectural requirements for perpetual equity and futures markets.

• Programmable oracles define asset context. Static feeds do not.

The Structural Mismatch: Continuous Perpetuals vs Discontinuous Reference Markets

Perpetual markets trade 24/7.

Equities, equity index futures, and many traditional finance based instruments do not.

US equity markets operate across multiple sessions — pre-market, regular trading hours, post-market, overnight, and weekend closures. CME equity index futures trade nearly 24 hours per weekday but include a daily maintenance window and weekend closure.

Perpetual onchain contracts referencing these assets never stop.

If an oracle is bound only to referencing prices from exchange sessions, then all downstream applications are forced to pause.

Onchain frozen markets and closed sessions were once common practice. However, with the introduction of custom oracle logic, all reference assets powering perpetual markets can be priced onchain 24/7.

What Fails When Oracles Only Publish Exchange Prices?

A static oracle answers one question:

What is the latest reported external price?

Perpetual markets require a different question:

How should price behave under changing market conditions?

When the oracle only publishes exchange derived prices, common system failures emerge:

1. Price Freezes During Closed Sessions

If the reference feed stops updating, the oracle pauses updates. Perpetual markets continue trading against a frozen mark. Funding diverges from economic reality. Risk accumulates silently. Price swings become inevitable as exchange sessions reopen.

2. Reopening Gaps

When markets reopen, external prices jump. Liquidations cluster. Insurance mechanisms absorb discontinuities.

The issue is not volatility. It is discontinuity.

3. Funding Distortion

Funding rates depend on a continuously evolving mark price.

If the mark stalls for hours and then jumps, funding calculations become distorted relative to actual trading behavior.

4. Futures Drift and Contract Roll Effects

Dated futures encode:

• Time-to-expiry

• Interest rates

• Dividend yield

• Cost of carry

Without normalization, futures-based perpetuals drift mechanically over time, even if spot value remains constant.

A raw futures feed is not equivalent to a spot reference.

Perpetual Markets Require Asset Context, Not Just Asset Price

Static oracles define asset price. Programmable oracles define asset context.

Asset context includes:

• Whether the reference market is OPEN, CLOSED, or in maintenance

• How stale data is handled (e.g., ≤15s fresh, 15–60s stale fallback, >60s EMA)

• How prices evolve when no external prints exist

• How session transitions are buffered

• Whether dated futures require discount normalization

• How internal venue signals influence off-hours pricing

Without encoding this at the oracle layer, applications must:

• Manage session calendars

• Detect staleness

• Store historical state

• Implement smoothing logic

• Normalize futures pricing

• Coordinate transitions

That complexity fragments across markets and contracts, and introduces unnecessary risk at the application level.

Required Oracle Behaviors for Perpetual Equity and Futures Markets

Custom Oracle behaviors are no longer optional optimizations. They are now structural requirements.

1. Session-Aware Pricing

A session-aware oracle encodes market session logic directly at the data layer.

For US equities, this may include:

• PreMarket

• Normal

• PostMarket

• Overnight

• Weekend (EMA fallback)

For futures:

• Open

• Close (maintenance and weekends)

As well as including logic as one session rolls into another.

Session detection is deterministic and timezone-aware (e.g., Eastern Time for US assets).

During active sessions:

• External feeds are processed.

• Freshness thresholds are enforced.

During inactive sessions:

• The oracle switches to alternative logic (e.g., Time-Decay, Stateful, EMA’s).

Applications consume one continuous feed. They do not manage session boundaries.

This pattern is used in production equity and futures perpetual markets, including Injective and Dreamcash built with SEDA’s Programmable Oracle Logic.

2. Self-Referential EMA During Off-Hours

When no external prints exist, price must evolve deterministically.

Self-referential EMA uses the oracle’s own prior state (via LAST_RESULT) as the base.

LAST_RESULT enables stateful computation inside an otherwise stateless execution environment.

Example Dreamcash Logic: https://docs.dreamcash.xyz/trading/oracles-and-pricing-methodology Example Nunchi Logic: https://docs.nunchi.trade/hip-3-yex-perps-specifications/volatility-perpetuals

Key properties:

• Short gaps → small alpha → minimal movement

• Long gaps → large alpha → faster convergence

• After session breaks → EMA naturally reanchors

This logic creates controlled continuity across all sessions.

3. Multi-Tier Staleness Handling

Binary fresh/stale logic is insufficient for equities.

A typical structure:

• ≤15s → Fresh

• 15–60s → Stale fallback (use freshest session)

• 60s → EMA fallback

This helps prevent brief network latency from triggering synthetic pricing.

For futures, the model may simplify to:

• ≤60s → Use Pyth with discount

• 60s → EMA fallback

The oracle enforces degradation logic. Applications do not.

This logic helps ensure that the application constantly receives asset-context-aware pricing when offchain systems fail or pause momentarily.

5. Controlled Session Transitions

Session transitions are not instantaneous events.

Best practice includes:

• Transition buffers (e.g., 15-second boundary guard)

• Gradual blending where applicable

• EMA anchoring to last in-session price

The goal is deterministic transition, not abrupt switching. Programmable Oracles don’t just stitch feeds together, but blend them together.

How Programmable Oracles Enable Continuous Markets Over Discontinuous Data

A programmable oracle treats pricing as a function.

Inputs may include:

• Multiple external feeds

• On-venue impact prices

• Prior oracle state

• Session metadata

• Discount parameters

• Freshness thresholds

• Last known Oracle price

The output is:

• A single composite mark price

• With explicit session state

• With deterministic fallback behavior

• One endpoint for applications to consume

This separation of concerns matters:

• Data providers source raw prices.

• Oracle programs define policy.

• Relayers deliver onchain.

• Perpetual contracts consume a stable interface.

Applications integrate one endpoint.

Not four feeds. Not custom session calendars. Not duplicated EMA logic.

Live Implementations

Dreamcash — 24/7 Equity Index Futures

Dreamcash operates perpetual equity, commodity and equity index markets using session-aware logic, self-referential EMA, and automatic cost-of-carry normalization.

For Equity Index:

• Processes Pyth futures during OPEN

• Switches to SEDA EMA during CLOSE

• Applies discount to convert futures to spot-equivalent price

• Uses time-weighted smoothing

The perpetual contract consumes a single normalized price output.

Dreamcash | 24/7 Equity Perpetual Markets Using Session-Aware Oracle Infrastructure

Injective — 24/5 US Equities

Injective integrated a session-aware oracle that consolidates multiple equity session feeds into one continuous price stream.

Instead of switching between:

• Pre-market

• Regular

• Post-market

• Overnight feeds

The oracle encodes session detection, session logic and fallback internally.

Application complexity is reduced to consuming a composite rate.

Injective | 24/5 US Equities Using Session-Aware Oracle Programs

Limitations and Design Assumptions

Programmable oracle logic is not universally required.

It may be unnecessary when:

• The asset trades continuously with deep liquidity.

• The application tolerates abrupt mark changes.

• Funding and liquidation logic are intentionally coarse.

Such as the case with traditional crypto assets.

It may be insufficient when:

• External reference markets are illiquid or unreliable.

• On-venue activity is too thin to inform EMA behavior.

• Regulatory constraints require strict official settlement prices.

In such cases, a different subset of oracle logic may be best suited.

FAQ

Why not pause perpetual markets during closed sessions?

Open positions remain exposed. Pausing trading does not pause risk. Additionally, external events affecting markets can take place at any time. 24/7 access to exposure allows market participants to react to events at any time.

Does self-referential EMA allow the oracle to control price?

No. It defines how price evolves when external data is unavailable, using deterministic logic and documented inputs.

Why normalize futures to spot at the oracle layer?

To prevent mechanical drift and rollover discontinuities from propagating into perpetual funding and liquidation logic.

Can session handling live in the perpetual contract instead?

It can, but that duplicates complexity across markets and fragments behavior.

Is this only relevant for equities?

No. Any asset with discontinuous reference markets requires session-aware pricing.

Is EMA price discovery?

No. It is continuity logic between external updates.

Closing

Perpetual markets are continuous by design. Reference markets are not. An oracle that only publishes spot prices assumes continuity where none exists.

Programmable oracles encode:

• Session-aware pricing

• Self-referential logic

• Cost-of-carry normalization

• Deterministic staleness handling

Price alone is not enough. Context determines whether funding, liquidation, and margin systems behave predictably.