A static price feed does one thing: it publishes a number.
The oracle provider decides which assets are covered, how price data is calculated, and when the feed updates. The protocol accepts these decisions. There is no mechanism to adjust them for a specific asset, a specific market context, or a specific set of operating conditions.
An Oracle Program is different. It is logic deployed by the builder that defines the complete policy for how data should be sourced, processed, and delivered — for this specific asset, under all operating conditions.
What an Oracle Program Can Define
For a perpetual market on a tokenized equity, a single Oracle Program can specify all of the following:
Data sources. Which primary source to query during exchange hours — dxFeed for NYSE/Nasdaq data, Pyth, Hyperliquid mark prices, or any accessible API or websocket that builder is authorized to use. Which secondary sources to use for cross-validation. How to handle disagreement between sources: reject the outlier, blend at weighted ratios, apply a fallback hierarchy.
Session logic. What counts as a live market session vs a closed session. When to switch between states. How to record session state for downstream pricing decisions.
Off-hours formula. When the reference market closes, which formula to apply. The self-referential EMA anchored to the last session close with the EMA period configured by the builder based on the asset's off-hours liquidity characteristics.
Transition handling. At market open, how to interpolate between the off-hours formula value and the incoming live opening price data. Transition window length is a builder parameter. This is how reopening gap cascades are mitigated: the data output path at open is managed, not a hard single-step jump.
Corporate actions. How to handle stock splits, dividends, and index rebalances — as defined, programmatic behavior, not a manual correction after the fact.
Multi-oracle aggregation. How to combine outputs from Pyth, Chainlink, Hyperliquid mark prices, and dxFeed with custom weights that can shift based on session state — heavier on exchange data in-session, adjusted weighting off-session.
State recording. Oracle Programs can store state between updates: the running EMA value, the last session close price, the current session flag. This enables data-processing logic that is continuous across time, not just a function of the current observation.
Why This Matters for Tokenized Asset Markets
A static feed makes all of these decisions for you. The decisions it makes may be appropriate for BTC/USD. They are not necessarily appropriate for a tokenized equity perpetual, a private credit fund token, or an RWA-based structured product.
Every asset with structured market context — sessions, redemption mechanics, NAV calculation windows, corporate action schedules — needs data logic designed for its specific characteristics. A static feed cannot provide this. An Oracle Program can.
Three Production Examples
Dreamcash runs USA500 equity index perpetuals on Hyperliquid. Oracle Program design: dxFeed in-session, self-referential EMA with 150-second period off-hours, managed transition at NYSE open.
Nunchi runs exotic perpetuals — VXX (volatility exposure), T-Bill yields, funding rates as a perpetual. Oracle Program design: multi-source weighted blending with session-selected oracle configurations per product.
Outcome Market runs prediction markets for financial events and sports. Oracle Program design: SEDA Fast execution for as fast as sub-5-second resolutions.
Three different Oracle Program designs. Each defined for the specific requirements of its market. Each encoding logic that a static feed cannot implement.
The Design Space
A static oracle has one mode. An Oracle Program has as many modes as the application requires.
For builders evaluating oracle infrastructure: the question is not whether the oracle provider's list includes your asset. It is whether you can define the data policy your application actually requires. Static feeds constrain that policy to whatever the provider has already decided. Oracle Programs put the policy decision where it belongs — with the builder who understands the asset.
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 may rely on third parties for data feeds; SEDA makes no representations or guarantees regarding the availability, accuracy, completeness, reliability, or timeliness of any data, including price data. For important information, please refer to the Content Disclaimer.