Dreamcash | 24/7 Equity Perpetual Markets Using Session-Aware Oracle Infrastructure
Session-aware and self-referencing oracle architecture enabling 24/7 equity perpetual markets over 23/5 futures reference assets.
TL;DR
Dreamcash operates equity index perpetual markets that trade continuously.
The underlying reference futures trade 23/5 with maintenance pauses.
Static oracle feeds would freeze, drift, or create liquidation discontinuities.
SEDA implemented session-aware, self-referencing, and cost-of-carry–normalized oracle logic.
Result: Continuous, deterministic, spot-equivalent pricing suitable for 24/7 perpetual infrastructure.
The Structural Problem
Perpetual markets operate continuously.
Traditional equity futures markets do not.
CME index futures (e.g., ES, NQ) trade nearly 23 hours per day but:
Pause for daily maintenance.
Close over weekends.
Encode time-to-expiry drift.
Dreamcash required:
Continuous mark pricing.
Stable funding calculations.
Predictable liquidation behavior.
No reopen gap clustering.
No artificial drift from futures expiry.
A static price feed could not satisfy these requirements.
The problem was not data access.
It was oracle behavior.
Why Static Oracle Feeds Fail in This Context
A static oracle answers one question:
What is the latest reported price?
For 24/7 equity perpetuals, this is insufficient.
Without contextual logic:
Prices freeze during reference market closures.
Reopen gaps cluster liquidations.
Futures contracts drift mechanically due to cost-of-carry.
Mark prices diverge from spot-equivalent exposure.
Funding calculations distort during inactive sessions.
Perpetual contracts assume continuous price evolution.
Futures markets provide discontinuous and time-bound inputs.
The oracle must reconcile this mismatch.
Required Oracle Architecture
Dreamcash required programmable oracle logic that could:
Detect session state.
Normalize futures to spot-equivalent values.
Maintain continuity during inactive sessions.
Transition deterministically across reopen boundaries.
Provide a single stable mark price to the perpetual contract.
This required more than a feed.
It required an Oracle Program.
Oracle Architecture Implemented by SEDA
SEDA deployed a custom Oracle Program encoding two core behaviors:
1. Session-Aware Pricing
The oracle detects whether the reference futures market is:
Open
In daily maintenance
Closed for the weekend
During active sessions:
External futures prices dominate.
During inactive sessions:
The oracle transitions into deterministic fallback logic.
Session-awareness ensures:
No hard price freezes.
No implicit assumptions in contract code.
Explicit handling of market state at the data layer.
This is a foundational requirement for 24/7 equity perpetual markets.
2. Self-Referencing EMA During Inactive Sessions
When reference markets pause, the oracle cannot freeze.
It must evolve deterministically.
SEDA implements a time-aware Exponential Moving Average (EMA) using prior oracle state:
This ensures:
Smooth continuity across session boundaries.
No sudden reopen liquidation cascades.
Predictable mark evolution during thin liquidity.
This is not synthetic price discovery.
It is bounded continuity logic.
Resulting Market Behavior
With this architecture:
Dreamcash markets operate 24/7.
Mark prices remain continuous.
Futures drift is normalized.
Funding calculations remain stable.
Liquidation clustering is reduced.
Session transitions are deterministic.
The perpetual contract consumes one stable endpoint.
All complexity remains encoded at the oracle layer.
Why This Matters
This case demonstrates a broader principle:
Continuous markets referencing discontinuous assets require programmable oracle infrastructure.
Static feeds compress the design space.
Programmable oracles expand it.
Dreamcash is not an isolated example.
This pattern applies to:
24/7 equity exposure.
Volatility perpetuals.
Composite index markets.
Synthetic baskets.
Structured onchain derivatives.
When oracle logic encodes policy, new financial instruments become possible.
Architectural Takeaways
This implementation proves:
Session-aware pricing is infrastructure, not a feature.
Cost-of-carry normalization belongs in the oracle layer.
Self-referencing state prevents discontinuity.
Application contracts should consume stable marks, not implement risk logic.
Programmable Oracle Programs enable non-trivial perpetual markets.
Related Concepts
Session-Aware Oracles
Self-Referencing Oracle Logic
Oracles for Perpetual Markets
24/7 Equity Markets Infrastructure
Programmable Oracle Programs
Broader Implication
Dreamcash did not simply integrate a price feed.
It integrated an executable pricing policy.
This is the difference between:
Listing a market and Designing a financial instrument.
Programmable oracle infrastructure determines what markets can exist.
Last updated
Was this helpful?