Push oracles (e.g., Chainlink Data Feeds) excel at providing low-latency, high-frequency data for critical DeFi applications because they proactively push verified data on-chain at regular intervals. This model guarantees data availability for smart contracts, enabling sub-second price updates essential for perpetuals on dYdX or Aave's lending markets. For example, Chainlink's mainnet feeds update every block (approx. 12 seconds) with data aggregated from 31+ premium node operators, securing over $20B in Total Value Secured (TVS).
LABS
Comparisons
Oracle Push Scaling vs Pull Scaling
A technical comparison of push-based and pull-based oracle scaling models, analyzing their performance, cost, security trade-offs, and optimal use cases for protocol architects and CTOs.
Chainscore © 2026
introduction
THE ANALYSIS
Introduction: The Core Scaling Dilemma for On-Chain Data
A foundational look at the architectural trade-offs between push and pull oracles for scaling real-world data on-chain.
Pull oracles (e.g., Pyth Network, API3's dAPIs) take a different approach by storing data attestations on a low-cost layer (like Pythnet) and allowing protocols to pull data on-demand via a permissionless pull function. This strategy results in a significant trade-off: it dramatically reduces on-chain gas costs and data latency for the oracle network itself, but shifts the cost and timing burden to the final application, which must now pay gas to request each update.
The key trade-off: If your priority is guaranteed, hands-off data freshness for high-value transactions (e.g., liquidations, options settlements), choose a push model. If you prioritize extreme cost-efficiency and maximal data granularity for applications that can batch or schedule updates (e.g., structured products, periodic settlements), a pull oracle architecture is superior. The choice fundamentally hinges on who bears the cost and responsibility for data latency: the oracle network or the consuming protocol.
tldr-summary
Push vs Pull Oracle Scaling
TL;DR: Key Differentiators at a Glance
A direct comparison of the two dominant oracle data delivery models, highlighting their architectural trade-offs for latency, cost, and reliability.
01
Push Model: Real-Time Guarantees
Proactive Data Delivery: Oracles like Chainlink Automation and Pyth push updates on-chain when predefined conditions (e.g., price deviation) are met. This ensures sub-2-second finality for critical data feeds. This matters for perpetual DEXs (e.g., GMX, dYdX) and liquidation engines where latency is a direct financial risk.
02
Push Model: Predictable Cost Structure
Fixed Operational Cost: The cost of data updates is borne by the oracle service or a designated payer, not the end-user. This creates a predictable gas overhead for protocols. This matters for high-frequency applications where user transaction costs must remain stable and composable calls don't incur surprise fees.
03
Pull Model: Ultimate Cost Efficiency
Pay-Per-Use Economics: Protocols like Tellor and some Chainlink low-latency feeds require users or contracts to explicitly request data, paying gas only when needed. This enables near-zero baseline cost for dormant contracts. This matters for NFT valuation oracles, insurance protocols with infrequent claims, and budget-conscious early-stage dApps.
04
Pull Model: On-Demand Flexibility
User-Initiated Updates: Any participant can trigger a data update, decentralizing the trigger mechanism and allowing for customizable freshness. This matters for long-tail asset pricing, DAO governance data, and cross-chain messaging (like LayerZero) where updates are event-driven rather than continuous.
05
Push Trade-off: Gas Inefficiency at Scale
Potential for Redundant Updates: Continuously pushing data during low volatility leads to wasted gas and blockchain bloat. On networks like Ethereum Mainnet, this can mean $100K+ annual overhead for a single active feed. This is a critical consideration for protocols deploying on multiple chains or managing dozens of price pairs.
06
Pull Trade-off: Latency & UX Complexity
User-Facing Delay: The need to initiate a pull transaction adds ~1-3 block confirmations of latency and requires users to hold gas tokens. This creates a poor UX for retail DeFi and breaks composability for flash loans or arbitrage bots that require immediate, guaranteed data availability.
HEAD-TO-HEAD COMPARISON
Push vs Pull Oracle Scaling Comparison
Direct comparison of key architectural and performance metrics for oracle data delivery models.
| Metric | Push (On-Demand) Model | Pull (Publish/Subscribe) Model |
|---|---|---|
Latency (Data to On-Chain) | ~3-12 seconds | < 1 second |
Gas Cost (Per Update) | User pays (e.g., $0.50-$5.00) | Protocol subsidizes (e.g., $0.01-$0.10) |
Network Overhead | High (per-request on-chain calls) | Low (batch updates, off-chain aggregation) |
Suitable for | Low-frequency, high-value updates (e.g., Chainlink VRF) | High-frequency, low-latency feeds (e.g., Pyth, Chainlink Low-Latency) |
Data Freshness Guarantee | On request | Continuous (e.g., 400ms intervals) |
Primary Infrastructure | Chainlink, API3, Witnet | Pyth Network, Chainlink Streams |
PERFORMANCE & COST BENCHMARKS
Oracle Push Scaling vs Pull Scaling
Direct comparison of key architectural metrics for on-chain data delivery.
| Metric | Push Model (e.g., Chainlink) | Pull Model (e.g., Pyth, API3) |
|---|---|---|
Data Latency (On-Chain) | ~1-5 seconds | < 400 milliseconds |
Gas Cost (Per Update) | $0.50 - $5.00+ | $0.001 - $0.05 |
Network Overhead | High (Broadcast to all) | Low (On-demand fetch) |
Consumer Sovereignty | ||
Update Frequency | Scheduled (e.g., 1 min) | Event-Driven or On-Demand |
Primary Use Case | Perpetual Data Feeds | Low-Latency Trading, Perps |
pros-cons-a
Oracle Push Scaling vs Pull Scaling
Push Model: Pros and Cons
Key architectural trade-offs for real-time data delivery on-chain. Push models proactively broadcast, while pull models require on-demand requests.
01
Push Model: Proactive Latency
Sub-second finality for critical data: Updates are broadcast automatically upon off-chain verification. This is critical for DeFi lending protocols (e.g., Aave, Compound) that need instantaneous liquidation price updates to prevent undercollateralization.
02
Push Model: Predictable Cost
Fixed operational overhead: The oracle operator (e.g., Chainlink Keepers, Pyth Network) bears the gas cost for data pushes, providing cost certainty for dApp users. This simplifies budgeting for high-frequency applications like perpetual futures exchanges (e.g., dYdX, GMX).
03
Pull Model: Cost Efficiency
Pay-per-query model: Smart contracts (e.g., Uniswap v3 TWAP oracles) only incur gas costs when data is explicitly requested. This is optimal for low-frequency data needs like NFT floor price updates or governance snapshotting, where 99% of blocks don't require an update.
04
Pull Model: Data Freshness Control
On-demand data resolution: Contracts control exactly when to fetch and pay for an update, eliminating stale data pushes. This is essential for insurance protocols (e.g., Nexus Mutual) that need verifiable, timestamped data for claim adjudication only at specific moments.
05
Push Model: Cons - Resource Burden
Inefficient for idle periods: Continuously broadcasting data to all subscribers (e.g., Chainlink Data Streams to 50+ contracts) wastes network bandwidth and gas during low-volatility markets. This can lead to ~40% higher operational costs for oracles serving sporadic users.
06
Pull Model: Cons - User Experience Friction
Latency introduced by user actions: A user must submit and pay for a transaction to trigger a data pull, adding critical seconds. This creates a poor experience for DEX aggregators (e.g., 1inch) where price slippage can occur during the pull request lifecycle.
pros-cons-b
Oracle Push Scaling vs Pull Scaling
Pull Model: Pros and Cons
Key architectural trade-offs for on-chain data delivery, from gas efficiency to decentralization.
01
Push Model: Pro - Real-Time Execution
Guaranteed data freshness: Oracles like Chainlink and Pyth push updates on a schedule or when thresholds are breached, ensuring dApps like Aave and Compound have the latest prices for liquidations (< 1 sec latency). This is critical for high-frequency DeFi protocols.
02
Push Model: Con - Gas Inefficiency & Spam
High, unpredictable L1 costs: Every update consumes gas, paid by the oracle or protocol. On Ethereum mainnet, this can cost $10s per update. Under volatile conditions, spam can congest the network, as seen with Chainlink during the 2021 bull run.
03
Pull Model: Pro - On-Demand Gas Efficiency
User-pays gas model: Protocols like Tellor and API3's dAPIs shift gas costs to the end-user who initiates the data request. This eliminates idle network spam and is optimal for low-frequency data needs (e.g., NFT floor price oracles, insurance claim verification).
04
Pull Model: Con - Latency & UX Friction
Added user wait time: The pull transaction must be mined, introducing latency (e.g., 12+ seconds on Ethereum). This creates poor UX for real-time applications and requires front-ends to handle asynchronous data fetching, complicating design.
CHOOSE YOUR PRIORITY
Decision Framework: When to Use Which Model
Push Model for DeFi
Verdict: Dominant for high-frequency, high-value protocols. Strengths:
- Real-time updates from oracles like Chainlink Data Streams or Pyth Network are critical for liquidations, options pricing, and perpetual futures.
- Predictable gas costs for the protocol, as the oracle pays for data delivery.
- Battle-tested for core money legos (AAVE, Compound, Synthetix). Trade-offs: Oracle node bears gas cost, which may be passed to data consumers via fees. Less suitable for infrequent, low-value data needs.
Pull Model for DeFi
Verdict: Optimal for cost-sensitive, event-driven logic. Strengths:
- Zero idle cost; you only pay gas when your contract explicitly requests an update (e.g., a user initiates a loan closure).
- Full control over update timing, useful for governance votes or TWAP oracles.
- Can be cheaper for low-traffic vaults or niche derivatives. Trade-offs: Introduces latency and UX friction (user must trigger pull). Not viable for automated, time-sensitive protections.
verdict
THE ANALYSIS
Final Verdict and Strategic Recommendation
Choosing between push and pull scaling is a foundational architectural decision that dictates your oracle's performance profile and cost structure.
Push-based oracles excel at providing low-latency, high-frequency data because they proactively broadcast updates to on-chain consumers. This model is ideal for high-throughput DeFi applications like perpetual futures on dYdX or GMX, where sub-second price updates are critical. The trade-off is inherent gas inefficiency, as data is pushed regardless of immediate demand, leading to higher operational costs for the oracle provider, which can be reflected in service fees.
Pull-based oracles take a different approach by optimizing for cost and data freshness control. Consumers explicitly request data on-demand, paying gas only when needed. This is highly efficient for less time-sensitive applications like lending protocols (e.g., Aave, Compound) that may only need hourly price checks for liquidations. The key trade-off is latency; a pull request must complete an entire request-response cycle, making it unsuitable for real-time trading.
The key trade-off: If your priority is ultra-low latency and predictable data delivery for high-frequency applications, choose a push model like Chainlink's Data Streams or Pyth Network. If you prioritize gas cost minimization and your application can tolerate request latency (seconds to minutes), a pull-based solution like Chainlink's Basic Request Model or a custom Tellor oracle is more strategic. For maximum resilience, a hybrid approach using push for core feeds with a pull-based fallback is often employed by leading protocols.
ENQUIRY
Build the
future.
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