Push Feeds (e.g., Chainlink Data Streams, Pyth Network) excel at delivering ultra-low-latency, high-frequency data by proactively pushing updates to subscribers. This model is critical for high-performance DeFi protocols like perpetual futures on dYdX or GMX, where sub-second oracle updates are non-negotiable for liquidations and pricing. The trade-off is higher operational cost and resource consumption for the provider, often passed on as subscription fees, and potential inefficiency for infrequently accessed data points.
Push Feeds vs On-Demand Feeds: Oracle Delivery Models
Introduction: The Core Architectural Decision
Choosing between push and on-demand data feeds is a foundational infrastructure choice that dictates cost, latency, and scalability for your dApp.
On-Demand Feeds (e.g., standard Chainlink Price Feeds, API3 dAPIs) take a different approach by serving data only when a user transaction explicitly requests it, typically via a pull mechanism. This results in a 'pay-per-call' cost structure that is highly efficient for applications with sporadic or user-initiated data needs, such as NFT minting or insurance claim settlements. The trade-off is higher per-call latency (often 2-15 seconds for on-chain confirmation) and the risk of front-running during volatile market events.
The key trade-off: If your priority is sub-second latency and high throughput for a core financial primitive, choose a Push Feed. If you prioritize cost efficiency and flexibility for less time-sensitive or sporadic functions, an On-Demand Feed is superior. Your choice locks in fundamental constraints around user experience and operational budget.
TL;DR: Key Differentiators at a Glance
A high-level comparison of real-time notification delivery models for blockchain applications.
Push Feeds: Proactive Delivery
Guaranteed, low-latency delivery: Notifications are sent directly to user wallets (e.g., via Push Protocol) as soon as an event occurs. This matters for time-sensitive alerts like liquidation warnings, governance votes, or high-value NFT bids where user action is required.
Push Feeds: User Engagement
Higher opt-in and retention: Users receive notifications without needing to check an app. Protocols like Aave, Uniswap, and Snapshot use this to drive engagement. This matters for dApps requiring consistent user interaction and building a sticky user base.
Push Feeds: Cons & Trade-offs
Higher infrastructure cost and complexity: Requires maintaining notification servers and managing spam filters. User must opt-in per channel. This matters for early-stage protocols where development resources are limited or for broadcasts to a passive audience.
On-Demand Feeds: Cost Efficiency
Pay-per-query model: Data is fetched only when needed (e.g., via The Graph subgraphs, Covalent API). This matters for analytics dashboards, portfolio trackers, or batch processing where real-time push is unnecessary and cost control is critical.
On-Demand Feeds: Developer Simplicity
Simpler integration: No need to manage WebSocket connections or user subscription states. Use a standard API call (REST/GraphQL). This matters for prototyping quickly or adding supplemental data to an existing application without overhauling its architecture.
On-Demand Feeds: Cons & Trade-offs
Inherent latency and missed updates: Data is only as fresh as the last poll. Users must actively open the app to see updates. This matters for trading platforms, live auctions, or security monitors where stale information leads to missed opportunities or risks.
Push Feeds vs On-Demand Feeds
Direct comparison of key architectural and performance metrics for blockchain data delivery.
| Metric | Push Feeds (e.g., Chainlink Data Streams) | On-Demand Feeds (e.g., Chainlink Data Feeds) |
|---|---|---|
Data Delivery Model | Continuous, low-latency stream | Request-based, on-demand pull |
Latency (Data to Contract) | < 500 ms | ~1-2 seconds |
Update Frequency | Sub-second to seconds | Minutes to hours |
Gas Cost for Update | Protocol-subsidized | User-paid per request |
Ideal Use Case | High-frequency trading, real-time gaming | Scheduled settlements, periodic valuations |
Protocol Examples | Chainlink Data Streams, Pythnet | Chainlink Data Feeds, API3 dAPIs |
Performance & Cost Benchmarks
Direct comparison of key metrics for oracle data delivery models.
| Metric | Push Feeds (e.g., Chainlink) | On-Demand Feeds (e.g., Pyth, API3) |
|---|---|---|
Update Latency | 1-5 minutes | < 400ms |
Data Freshness | ~1-5 min old | ~100-400ms old |
Protocol Fee per Update | $0.10 - $0.50 | $0.001 - $0.01 |
Gas Cost for Consumer | ~50k gas | ~150k - 300k gas |
Supported Data Types | Price feeds, Proof of Reserve | Price feeds, VWAP, Custom APIs |
Decentralization Model | Decentralized Data Sources & Nodes | Decentralized Publisher Network |
Primary Use Case | Continuous State Updates (DeFi Lending) | Low-Latency Trading (Perps, Options) |
Push Feeds: Advantages and Limitations
A technical breakdown of proactive (Push) and reactive (On-Demand) oracle feed models. Choose based on latency tolerance, gas cost sensitivity, and data update frequency.
Push Feed Advantage: Predictable, Low Latency
Proactive Updates: Data is pushed on-chain at predefined intervals (e.g., Chainlink Data Streams). This guarantees sub-second finality for price updates, critical for high-frequency trading (HFT) protocols and perpetual DEXs like GMX or Synthetix. Eliminates the user-facing latency of an on-demand pull.
Push Feed Advantage: Simplified Integration
No Custom Logic: DApps consume data directly from a live on-chain feed (e.g., Chainlink ETH/USD aggregator). This reduces development overhead and audit surface, ideal for rapid prototyping or protocols where gas costs for users are secondary to reliability, such as lending platforms like Aave.
On-Demand Feed Advantage: Gas Efficiency
Pay-Per-Use Model: Data is fetched only when a user transaction requires it (e.g., API3 dAPIs, Pyth's pull oracle). This eliminates the cost of continuous updates, making it optimal for low-frequency, user-initiated actions like infrequent settlements, NFT price oracles, or insurance claim resolutions.
On-Demand Feed Advantage: Freshness & Customization
Event-Driven Freshness: Data is as fresh as the block it's requested in, avoiding staleness between push intervals. Supports custom data types beyond price feeds (sports scores, weather). Best for prediction markets like Polymarket or bespoke DeFi derivatives that need non-standard data points.
Push Feed Limitation: Higher Operational Cost
Continuous Gas Expenditure: The protocol or node operators bear the cost of perpetual on-chain updates, regardless of usage. This can lead to higher protocol overhead or premium fees passed to integrators. Less sustainable for niche assets with low query volume.
On-Demand Limitation: User Experience Friction
Added Latency & Complexity: Users must wait for the oracle fetch within their transaction, adding 1-2 blocks of latency. Requires more complex smart contract logic to handle the request-fulfillment cycle. Can be a poor fit for seamless UX in high-speed arbitrage or gaming applications.
On-Demand Feeds: Advantages and Limitations
Key architectural trade-offs for oracle data delivery, from cost predictability to latency and decentralization.
Push Feed Advantage: Predictable Cost & Latency
Fixed subscription model: Protocols like Chainlink Data Streams or Pyth Network push updates at predefined intervals (e.g., 400ms). This guarantees sub-500ms latency and predictable gas costs for the publisher. This matters for perpetual DEXs (e.g., GMX, Synthetix) requiring consistent, low-latency price updates for liquidations.
Push Feed Limitation: Inefficient for Low-Frequency Data
Continuous gas expenditure: Pushing data on every block wastes resources for data that changes infrequently (e.g., BTC dominance, TWAPs). This leads to higher operational costs for the feed publisher, which can be prohibitive for niche assets or custom computations. This matters for long-tail asset feeds or bespoke indices where update frequency is low.
On-Demand Feed Advantage: Cost-Effective & Flexible
Pay-per-query model: Solutions like Chainlink Functions or API3 dAPIs allow dApps to fetch data only when needed. This eliminates ~99% of gas costs for static or slow-moving data. This matters for insurance protocols (e.g., Nexus Mutual), prediction markets, or any application with sporadic, event-driven data needs.
On-Demand Feed Limitation: Unpredictable Latency & Front-Running Risk
Variable resolution time: A user or contract must initiate and pay for each request, introducing 1-5 second latency depending on blockchain congestion and oracle network response. This creates a MEV opportunity for front-running the on-chain settlement. This matters for high-frequency trading or any use case where stale data is catastrophic.
Decision Framework: When to Use Which Model
Push Feeds for DeFi
Verdict: The Standard for High-Value, Latency-Sensitive Applications. Strengths: Real-time price updates are critical for liquidations, arbitrage, and limit orders. Push feeds from Chainlink Data Streams or Pyth Network deliver sub-second updates, preventing front-running and stale data. This is non-negotiable for perpetual DEXs like GMX or money markets like Aave where a few seconds of lag can mean millions in losses. The proactive nature ensures your protocol's state is always current.
On-Demand Feeds for DeFi
Verdict: Cost-Effective for Less Time-Critical Functions. Strengths: For functions like calculating historical APYs, periodic treasury rebalancing, or user-facing analytics dashboards, on-demand feeds are superior. Pulling data via Chainlink Functions or a custom oracle only when needed (e.g., once per epoch) drastically reduces operational costs. This model fits protocols like Compound for governance calculations or Yearn Finance for weekly strategy harvests, where real-time data is unnecessary.
Final Verdict and Strategic Recommendation
A data-driven breakdown of the core architectural trade-offs between push and on-demand oracle feeds to guide your infrastructure decision.
Push Feeds excel at providing low-latency, high-frequency data for time-sensitive applications because they proactively broadcast updates on-chain at predefined intervals. For example, a DeFi protocol like Aave or Compound using a Chainlink Data Feed for its price oracle benefits from sub-second updates and 99.9%+ uptime, ensuring liquidations and borrow limits are enforced with minimal delay. This model prioritizes data freshness and reliability for critical on-chain logic, but incurs continuous gas costs for the feed provider.
On-Demand Feeds take a different approach by shifting gas costs and update timing to the dApp user. This results in superior cost-efficiency for applications with sporadic or user-initiated data needs, such as an NFT marketplace checking a rarity score or a prediction market resolving an event. Protocols like API3's dAPIs or Pyth Network's pull-based updates allow developers to avoid paying for unused data, but introduce a user experience trade-off where the first transaction in a block may bear the cost and latency of the data fetch.
The key trade-off is between consistent operational cost and user experience latency versus variable cost and developer flexibility. If your priority is deterministic state and ultra-low latency for core protocol mechanics (e.g., lending, perpetuals, algorithmic stablecoins), choose a Push Feed from a provider like Chainlink. If you prioritize gas cost optimization for non-critical or user-triggered functions and can tolerate a one-block delay, an On-Demand Feed from API3 or a similar solution is strategically superior. Your choice fundamentally aligns with whether data is a continuous protocol cost or a sporadic user expense.
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.