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


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.seda.xyz/home/learn/bespoke-pricing-methodologies/dreamcash-or-24-7-equity-perpetual-markets-using-session-aware-oracle-infrastructure.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
