Smart contracts execute the same way on every blockchain node. This deterministic execution is fundamental to consensus — every validator must reach identical results. But deterministic execution creates a data access problem. A smart contract cannot make HTTP requests, query APIs, or read external databases. Any external data call returns different results at different times, breaking the deterministic requirement that keeps the blockchain secure.
This constraint affects every onchain application that depends on real-world information. Prediction markets cannot resolve outcomes they cannot verify. DeFi protocols cannot price assets they cannot access. AI agents cannot act on market signals they cannot confirm. The application logic lives onchain, but the data it needs exists offchain.
Traditional oracles solve this by providing predetermined price feeds — ETH/USD, BTC/USD, and other standard pairs during market hours. But fixed price feeds only address a narrow slice of the external data problem.
What happens when you need price data for assets not covered by standard feeds? What about custom aggregation logic that weights different data sources based on market conditions? What about non-price data like sports outcomes, earnings results, or API responses from any external service?
A programmable oracle addresses these limitations through custom logic. Instead of subscribing to a fixed feed, builders access oracle programs that define exactly how external data should be fetched, transformed, and delivered onchain.
How Programmable Oracles Work
A programmable oracle executes custom code across multiple independent nodes, reaches consensus on the result, and delivers verified data onchain. The core difference from traditional oracles is control: builders define the data pipeline rather than consuming a predetermined feed.
The Three-Stage Pipeline
Every programmable oracle follows the same execution pattern:
1. Fetch — The oracle program queries configured external sources. This can be any HTTP-accessible API: financial data providers, sports APIs, weather services, or custom endpoints that the builder is authorized to use.
2. Transform — The program applies configured extraction and computation logic. This might involve parsing JSON responses, calculating weighted averages, applying smoothing algorithms, or implementing custom business rules.
3. Deliver — A consensus mechanism collects signed results from all nodes. The verified result is delivered onchain only when nodes reach agreement according to the defined threshold.
This pipeline is general-purpose. The same infrastructure that resolves a sports score can provide configured price data for an exotic derivative. The same infrastructure that processes an API response can coordinate multi-party settlement.
Design Requirements for Custom Oracle Logic
Building reliable oracle programs requires addressing several technical challenges that do not exist with fixed price feeds.
Source Selection and Fallback Logic
Traditional price feeds typically aggregate data from established financial data providers with high uptime and consistent APIs. Oracle programs might need to query sources with different reliability characteristics: government APIs that update sporadically, sports APIs that only provide data during active games, or financial APIs that go offline during market holidays.
Robust oracle programs can be configured to implement fallback cascades. If the primary source is unavailable, the program queries a secondary source with different API structure. If both fail, it might use cached data with a staleness threshold or mark the feed as temporarily unavailable.
The logic for source selection can be dynamic. An oracle program providing data inputs for a tokenized asset might weight different data sources based on trading volume, market session, or volatility conditions. During high-volatility periods, it might require agreement from more sources before delivery.
Session Awareness and Off-Hours Logic
Standard price feeds typically operate during market hours — roughly 24/5 for major assets. They go stale during weekends, holidays, and scheduled maintenance windows. Applications that need 24/7 price data cannot rely on feeds that stop updating for 60+ hours every weekend.
Session-aware oracle programs can be configured to implement custom logic for off-hours periods. This might involve:
- Carrying forward the last valid price data with a decay function
- Switching to futures-based data inputs when spot markets close
- Blending multiple time zones to maintain continuous coverage
- Applying volatility adjustments based on time-weighted factors
The session logic is programmable per asset. A tokenized equity might use different off-hours pricing methodology than a commodity future. The oracle program can encode these rules rather than forcing all assets to follow the same approach.
Custom Aggregation and Weighting
Price feeds typically use standard aggregation methods — volume-weighted averages, median pricing, or outlier exclusion. Oracle programs can be configured to implement any aggregation logic.
An oracle program might weight data sources based on:
- Real-time liquidity measurements
- Historical accuracy for the specific asset
- Geographic relevance for regional markets
- Source-specific reliability scores that update dynamically
The weighting can be configured to change based on market conditions. During volatile periods, the oracle program might favor sources with higher update frequencies. During low-volume periods, it might apply smoothing algorithms to reduce noise.
Non-Price Data and Event Resolution
While price feeds handle numerical data, oracle programs can process any external information that smart contracts need to verify.
Event Resolution for Prediction Markets
Prediction markets require oracles that can provide data outputs for binary and categorical outcomes: "Did the event happen?", "What was the final score?", "Which candidate won?" These questions cannot be resolved through price aggregation.
Oracle programs for event resolution can be configured to implement custom verification logic:
- Query multiple authoritative sources for the same event
- Apply parsing rules specific to each source's data format
- Implement tie-breaking logic for edge cases
- Handle delayed or disputed results with configurable settlement windows
The consensus mechanism for events often requires unanimous agreement among executor nodes. A single dissenting node can prevent settlement until the dispute is resolved or additional verification is performed.
API Data Integration
Smart contracts often need to use data about claims from external systems: "What did this API return at timestamp X?", "What is the current state of this off-chain process?", "Has this external condition been met?" Oracle programs can standardize this verification process.
The oracle program acts as a trust-minimized bridge between the smart contract and external APIs. Instead of requiring the smart contract to trust a single API response, it gets a consensus-verified result from multiple independent nodes that each queried the API directly.
SEDA Oracle Programs: Implementation Architecture
SEDA implements programmable oracle infrastructure through Oracle Programs — deployed code units that define custom data pipeline logic. Builders write programs that specify fetch sources, transformation rules, and delivery requirements. The SEDA network executes these programs across independent executor nodes and delivers consensus results to connected chains.
Oracle Program Development Model
SEDA supports three development approaches depending on builder requirements:
Prebuilt programs address common use cases with zero custom code. Builders can deploy existing programs for standard assets, major cryptocurrencies, or common event types. These programs are maintained and updated by the SEDA community.
Amended programs start from existing code and modify specific components. A builder might fork a standard data feed program and add custom off-hours logic, change source weights, or implement asset-specific rules. This approach reduces development time while maintaining customization.
Custom programs are built from scratch for unique requirements. These might handle proprietary assets, implement novel aggregation methods, or integrate with specialized APIs that require custom authentication or parsing logic.
The Fetch-Transform-Consensus-Deliver Pipeline
Every SEDA Oracle Program follows the same four-stage execution model, but the logic within each stage is fully programmable.
In the fetch stage, the program queries configured external sources using HTTP requests. The program defines which APIs to query, what authentication to use, and how to handle rate limiting or temporary failures. An oracle program providing data inputs for tokenized real estate might query multiple property data APIs, while a program resolving sports outcomes might query official league APIs and backup sports data providers.
The transform stage applies all computation logic. This includes JSON parsing, data extraction, mathematical operations, and business rule application. An oracle program might calculate volume-weighted data values, apply volatility adjustments, implement smoothing algorithms, or execute complex conditional logic based on market state.
Consensus occurs when independent executor nodes compare their results. Each node executes the same program against the same external sources but does so independently. The results are collected and verified before delivery. For price data, nodes must agree within a configurable tolerance. For binary outcomes, unanimous agreement is typically required.
Delivery pushes the consensus result to the consuming smart contract on the target blockchain. SEDA supports delivery to any connected chain, with the oracle program specifying delivery frequency, trigger conditions, and formatting requirements.
Production Examples: SEDA Fast and Event Resolution
Outcome Market demonstrates SEDA's event resolution capabilities through HIP-4 prediction markets on Hyperliquid. HIP-4 is Hyperliquid's standard for outcome markets — prediction markets that resolve to binary or categorical results rather than continuous prices. These markets require oracles that can be configured to verify real-world events and deliver resolution data with high confidence.
SEDA Oracle Programs power Outcome Market through custom event resolution logic. Each market type — sports outcomes, earnings results, economic data releases — uses a different oracle program optimized for that event category. The oracle programs query authoritative sources, apply event-specific parsing rules, and reach consensus among independent executor nodes before delivering resolution data.
SEDA Fast reduces resolution latency to under 5 seconds for time-sensitive events. Traditional oracle networks are bounded by blockchain block times, creating multi-second delays between event occurrence and onchain resolution. SEDA Fast processes the fetch-transform-consensus pipeline offchain, delivering verified results with sub-50ms processing time and under-5-second onchain settlement.
Nunchi demonstrates custom rate oracle implementation through HIP-3 perpetual markets on Hyperliquid. While primarily known for funding rate perpetuals, Nunchi's architecture showcases how SEDA Oracle Programs handle API-sourced rate data that requires custom extraction and formatting logic. The oracle programs fetch rate data from external sources, apply session-aware processing, and deliver formatted results that smart contracts can consume directly.
24/7 Market Infrastructure
SEDA Oracle Programs can support applications that operate continuously by providing configurable session-aware data feed logic. Traditional price feeds operate 24/5, going stale during weekends, holidays, and scheduled maintenance. Applications requiring 24/7 operation need oracle infrastructure that maintains data feed continuity during off-hours periods.
Oracle programs can be configured to implement custom off-hours logic per asset class. Tokenized equities might use futures-based data inputs when spot markets close. Commodities might blend prices from different geographic exchanges to maintain coverage. Cryptocurrency-based assets might continue with spot pricing but apply volatility adjustments during low-liquidity periods.
The session logic is programmable and updateable. As market structure evolves or new data sources become available, oracle programs can be upgraded to incorporate improved off-hours methodologies without requiring smart contract changes.
FAQ
What is the difference between a programmable oracle and a traditional price feed?
A traditional price feed reports predetermined values for a fixed set of assets during market hours. You subscribe to ETH/USD or BTC/USD and receive regular price updates. A programmable oracle lets you write custom logic that defines what data to fetch, how to transform it, and when to deliver it onchain. Instead of being limited to predefined feeds, you can create oracle programs that handle any external data: custom asset price data, event resolution, API verification, or complex multi-source aggregation. The key difference is control — you define the data pipeline rather than consuming a predetermined one.
Why would I need programmable oracle infrastructure instead of static oracle infrastructure?
Traditional oracle networks excel at providing high-quality price feeds for major assets during market hours. A programmable oracle becomes relevant when you need: (1) price data for assets not covered by standard feeds, (2) 24/7 data feeds that continue through weekends and holidays, (3) custom aggregation logic like weighted blending or session-aware behavior, (4) non-price data such as event outcomes or API responses, or (5) custom computation at the oracle layer. SEDA can also wrap existing feeds from other providers, extending them with programmable logic — it works as both a standalone solution and an upgrade layer for existing oracle infrastructure.
What types of applications can you build with programmable oracles?
Programmable oracles support any use case where onchain applications need external data with custom logic: 24/7 perpetual markets with session-aware pricing that operates through weekends and holidays, prediction markets with custom event resolution and rapid settlement, exotic derivatives for assets without standard price feeds like volatility indices or treasury yields, tokenized asset pricing that combines multiple licensed data sources, AI agent coordination that provides verified external inputs for autonomous decision-making, and structured products that require composite valuation across multiple assets with custom weighting rules.
How does SEDA's consensus mechanism work for non-price data?
For numerical price data, SEDA uses statistical methods to identify consensus among independent executor nodes — typically requiring agreement within a configured tolerance and excluding outliers. For binary and categorical outcomes like event resolution, unanimous agreement is often required among participating nodes. Each executor node runs the oracle program independently, queries external sources directly, and submits a cryptographically signed result. The tally phase collects these signed results and applies the consensus rule. A single corrupted or compromised node is designed not to be able to determine the output on its own if the threshold requires agreement from sufficient honest nodes.
Can SEDA oracle programs update their logic after deployment?
Yes, oracle programs can be upgraded to incorporate new data sources, improved aggregation methods, or enhanced off-hours logic. This upgradeability is essential for maintaining oracle adaptability as market structure evolves or better data sources become available. However, upgrades follow governance processes to ensure consuming applications can rely on stable oracle behavior. Applications can also choose to pin to specific program versions for deterministic behavior or automatically receive updates for improved functionality.
Ready to Build Custom Data Pipelines?
Programmable oracles solve the fundamental constraint that prevents smart contracts from accessing external data with custom logic. Instead of being limited to predetermined price feeds during market hours, you can write oracle programs that fetch any external data, apply custom transformation rules, and deliver consensus-verified results onchain 24/7.
Whether you're building prediction markets that need rapid event resolution, DeFi protocols that require exotic asset price data, or AI agents that need verified external inputs, SEDA Oracle Programs provide the infrastructure to implement custom data pipelines with consensus-based security.
Explore the technical documentation and start building: docs.seda.xyz
SEDA is programmable oracle infrastructure for onchain applications. Developers deploy Oracle Programs — custom code that defines how external data is fetched, transformed, and delivered onchain — across an independent executor network with consensus verification. SEDA provides oracle infrastructure used by production deployments including Dreamcash, Nunchi, and Outcome Market on Hyperliquid, with reported over $621.9M in weekly perpetual-market volume.
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 or event outcomes. For important information, please refer to the Content Disclaimer.