High-Frequency Update Oracles (e.g., Chainlink Data Streams, Pyth Network) excel at delivering sub-second price feeds for DeFi protocols requiring real-time accuracy. They achieve this by pushing data on-chain at predetermined intervals, often leveraging high-throughput networks like Solana or dedicated Layer 2s. For example, Pyth's Solana-based mainnet feed updates major crypto prices every 300-400ms, enabling low-latency perpetual swaps on protocols like Drift.
LABS
Comparisons
Oracle Data Freshness: High-Frequency Updates vs On-Demand Updates
A technical and economic analysis comparing the infrastructure, cost, and performance implications of continuously updated oracle data streams versus data fetched only when needed by smart contracts.
Chainscore © 2026
introduction
THE ANALYSIS
Introduction: The Data Freshness Dilemma
Choosing between high-frequency and on-demand oracle updates is a foundational architectural decision impacting cost, latency, and reliability.
On-Demand (Pull-Based) Oracles (e.g., Chainlink's CCIP, API3 dAPIs) take a different approach by updating data only when a user transaction explicitly requests it. This strategy results in a fundamental trade-off: significantly lower operational costs and reduced on-chain footprint, but introduces a request-response latency of several seconds. This model is optimal for applications like insurance, RWA tokenization, or settlement layers where data needs are sporadic and absolute freshness is less critical than cost efficiency.
The key trade-off: If your priority is ultra-low latency and constant data availability for high-frequency trading, lending, or derivatives, choose a High-Frequency Oracle. If you prioritize minimizing operational gas costs and on-chain bloat for less time-sensitive functions like payroll, parametric insurance, or NFT valuations, an On-Demand Oracle is superior. The decision hinges on your application's specific latency SLA and cost-per-update tolerance.
tldr-summary
High-Frequency vs On-Demand Oracle Updates
TL;DR: Key Differentiators at a Glance
A direct comparison of oracle data freshness models, highlighting core architectural trade-offs for protocol architects.
01
High-Frequency Updates (e.g., Pyth, Chainlink Streams)
Sub-second to 1-second updates via push-based data streams. Ideal for high-frequency trading (HFT) DEXs, perpetual futures, and options protocols where latency is critical. Requires continuous on-chain gas expenditure and sophisticated relayers.
< 1 sec
Update Latency
Push
Update Model
02
On-Demand Updates (e.g., Chainlink Data Feeds, API3)
Update on request with freshness guarantees (e.g., heartbeat triggers, deviation thresholds). Optimized for lending protocols (Aave), stablecoins, and insurance where cost-efficiency and reliability trump millisecond updates. Lower operational overhead for most DeFi applications.
1 sec - 1 hr+
Update Latency
Pull
Update Model
03
Choose High-Frequency For:
- Perpetual DEXs & Derivatives (GMX, dYdX v4) needing real-time price feeds for liquidations.
- High-LTV Lending where collateral value can swing rapidly.
- Sophisticated MEV Strategies requiring front-running protection via freshest data.
04
Choose On-Demand For:
- General-Purpose Lending/Borrowing (Aave, Compound) with conservative parameters.
- Stablecoin Minting/Redeeming (MakerDAO, Liquity) where price stability is assumed.
- Budget-Conscious Protocols where minimizing oracle gas costs is a primary concern.
ORACLE DATA FRESHNESS MODELS
Head-to-Head Feature & Specification Comparison
Direct comparison of key metrics and architectural trade-offs for high-frequency vs. on-demand oracle updates.
| Metric / Feature | High-Frequency Updates | On-Demand Updates |
|---|---|---|
Update Latency (Data to Chain) | < 1 second | ~12 seconds (1 block) |
Typical Update Cost per Data Point | $0.10 - $0.50 | $0.001 - $0.01 |
Ideal Use Case | Perpetual DEXs, Money Markets | NFT Minting, Settlements |
Primary Data Source | Direct CEX/DeFi API Feeds | Decentralized Data Networks |
Gas Cost Sensitivity | High | Low |
Protocol Examples | Pyth Network, Chainlink Low-Latency | Chainlink Data Feeds, API3 |
pros-cons-a
Oracle Data Freshness Models
High-Frequency Updates: Pros and Cons
Choosing between high-frequency (push) and on-demand (pull) oracle updates involves fundamental trade-offs in cost, latency, and infrastructure complexity. The right model depends on your protocol's tolerance for stale data, transaction volume, and gas budget.
01
High-Frequency (Push) Pros
Sub-second data freshness: Updates are broadcast to the blockchain at fixed intervals (e.g., Pyth's ~400ms updates). This is critical for perpetual futures DEXs like Synthetix or high-leverage lending where stale prices cause liquidations. Enables true real-time applications.
< 1 sec
Typical Update Latency
02
High-Frequency (Push) Cons
High, continuous gas costs: The network pays for all updates, regardless of usage. For example, a Chainlink Data Feed on Ethereum can cost $1K+ daily in gas. This creates scaling friction and limits the number of supported assets. Inefficient for low-traffic assets.
$1K+
Daily Gas Cost (Example)
03
On-Demand (Pull) Pros
Pay-per-use cost model: Users or contracts pay only when data is requested, like with API3 dAPIs or Chainlink Functions. Ideal for insurance protocols (e.g., Nexus Mutual) or NFT valuation where updates are sporadic. Drastically reduces operational overhead for long-tail assets.
~$0.10
Cost per Request (Est.)
04
On-Demand (Pull) Cons
Higher per-request latency: Each update requires a full transaction lifecycle, adding ~12-30 seconds on L1s. Unacceptable for DEX arbitrage or money markets. Also shifts cost burden to end-users, which can degrade UX for frequent operations.
12-30 sec
Request-to-Execution Time
pros-cons-b
Oracle Data Freshness
On-Demand Updates: Pros and Cons
Key architectural trade-offs for real-time data feeds. High-Frequency Updates provide continuous streams, while On-Demand (Pull) models offer cost-effective precision.
01
High-Frequency Updates (Push Model)
Guaranteed Freshness: Data is pushed to the blockchain at fixed intervals (e.g., every 3-5 seconds on Pyth, every block on Chainlink). This is critical for perpetual DEXs like dYdX and lending protocols like Aave, where stale prices can lead to instant liquidations.
02
High-Frequency Updates (Push Model)
Higher Operational Cost & Latency: Continuous updates incur significant gas fees and can congest L1s. For example, Chainlink's ETH/USD feed on Ethereum costs ~$50K/month in gas. This model is less suitable for low-volume assets or L2 rollups where batch efficiency is key.
03
On-Demand Updates (Pull Model)
Radical Cost Efficiency: Contracts request data only when needed, slashing gas fees by 90%+. Protocols like API3 dAPIs and Chainlink Functions excel here. Ideal for insurance protocols (e.g., Nexus Mutual) or NFT valuation oracles that don't need millisecond updates.
04
On-Demand Updates (Pull Model)
Introduces User Friction & Latency Risk: Users or keepers must trigger the update, adding steps and potential delay. Unsuitable for high-frequency trading or automated liquidation systems. Requires robust keeper networks like Gelato or Chainlink Automation to mitigate.
ORACLE DATA FRESHNESS: HIGH-FREQUENCY VS ON-DEMAND
Cost Analysis: Gas Fees and Operational Overhead
Direct comparison of operational costs and performance for different oracle update models.
| Metric | High-Frequency Updates | On-Demand (Pull) Updates |
|---|---|---|
Gas Cost per Data Point (ETH Mainnet) | $5 - $50+ | $0.50 - $5 |
Update Frequency | 1 sec - 5 min | Triggered by user transaction |
Data Latency for Consumer | < 5 sec | ~12 sec (incl. block time) |
Infrastructure Overhead | High (Continuous RPC calls) | Low (Idle until request) |
Ideal for Protocols | Perpetuals (GMX), High-Freq Trading | Lending (Aave), Insurance (Nexus Mutual) |
Primary Cost Bearer | Protocol Treasury / Contract | End User |
Example Oracle | Chainlink Keepers / Streams | Chainlink Any API / Pyth |
CHOOSE YOUR PRIORITY
When to Choose Which Model: A Scenario-Based Guide
Chainlink for DeFi
Verdict: The standard for high-value, secure settlements. Strengths: Decentralized oracle networks (DONs) and off-chain reporting provide robust, tamper-proof data for price feeds (e.g., ETH/USD) critical for lending protocols like Aave and decentralized exchanges like Uniswap. Its security model is battle-tested with over $9T in on-chain transaction value secured. Trade-off: Update frequency (typically 1-5 minutes) and cost per update are higher, making it less suitable for micro-transactions.
Pyth Network for DeFi
Verdict: Superior for latency-sensitive, high-frequency trading. Strengths: Pull-based oracle with sub-second updates and low latency (400-500ms). Ideal for perpetual futures DEXs (e.g., Hyperliquid, Drift Protocol) and options platforms requiring real-time mark prices. Data is sourced directly from major trading firms and exchanges. Trade-off: Relies on a permissioned set of professional data providers, presenting a different trust model than fully permissionless networks.
verdict
THE ANALYSIS
Final Verdict and Decision Framework
Choosing between high-frequency and on-demand oracle updates is a fundamental trade-off between proactive data freshness and reactive cost efficiency.
High-frequency update oracles (e.g., Pyth, Chainlink Low-Latency Feeds) excel at providing sub-second data freshness for latency-sensitive applications. They achieve this by maintaining a continuous, push-based data stream onto the blockchain, often leveraging specialized networks like Solana or high-throughput Layer 2s. For example, Pyth's Solana-based feeds update every 400ms, enabling real-time derivatives and perpetual swaps on protocols like Drift and Mango Markets. This model ensures data is always current but incurs constant on-chain gas costs, regardless of usage.
On-demand (pull-based) oracles (e.g., Chainlink Data Streams, API3 dAPIs) take a different approach by transmitting data off-chain and only committing a verifiable proof on-chain when a user request triggers it. This strategy results in a fundamental trade-off: exceptional cost efficiency and scalability for the protocol (pay-per-use model) at the expense of requiring a 1-2 second request-response latency for the end-user. This is ideal for applications like insurance, NFT lending (e.g., JPEG'd), or governance votes where ultra-low latency is less critical than minimizing operational overhead.
The key trade-off is latency versus cost structure. If your priority is sub-second data freshness for high-frequency trading, money markets, or real-time settlement, choose a high-frequency push oracle. If you prioritize minimizing protocol gas fees, scaling to thousands of assets, or servicing less time-sensitive functions, an on-demand pull oracle is superior. The decision ultimately maps to your application's core latency SLA and economic model.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall