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

### 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:

1. Detect session state.
2. Normalize futures to spot-equivalent values.
3. Maintain continuity during inactive sessions.
4. Transition deterministically across reopen boundaries.
5. 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.