Pull Oracles vs Push Oracles: Scale

Proactive Data Delivery: Updates are pushed to the contract automatically upon price deviation (e.g., Chainlink's >1% heartbeat). This ensures sub-second finality for critical functions like liquidations on Aave or Compound, where latency directly impacts protocol solvency.

Fixed Overhead Per Update: Every data push incurs gas costs, paid by the oracle service or passed to dApps. For low-value or infrequently accessed data (e.g., NFT floor prices for a small collection), this creates prohibitive operational costs and blockchain bloat. Scaling to 10,000+ feeds is economically challenging.

On-Demand Cost Model: Data is fetched only when a user transaction requires it (e.g., Pyth's pull oracle). The user pays the gas. This allows the oracle to maintain 10,000+ price feeds (like Pyth's cross-chain program) with near-zero operational overhead, perfect for long-tail assets or perp markets.

Added Latency & Complexity: Users must include an oracle update in their transaction, adding ~200-500ms of latency and requiring them to manage relayers or witness data. This breaks composability for fast DeFi loops and is unsuitable for keeper-triggered functions like automatic liquidations.

Gas costs scale only with usage: Protocols like Uniswap v3 TWAP or Pyth's pull-update only pay for data when a user transaction requires it. This creates predictable, user-borne costs and eliminates baseline streaming fees. This matters for low-frequency applications (e.g., NFT floor price feeds, governance voting) where constant updates are wasteful.

No wasted network calls or storage: The chain stores no data until explicitly requested, reducing state bloat. This is critical for multi-chain deployments (e.g., a dApp on 10+ L2s) where maintaining active push streams to each chain is prohibitively expensive. Tools like Chainlink Functions exemplify this serverless, compute-on-demand approach.

Sub-second data freshness pre-committed on-chain: Oracles like Chainlink Data Streams or Pythnet push price updates in near real-time (<500ms). This matters for perpetual futures DEXs (e.g., Hyperliquid, Aevo) and money markets where stale data directly causes liquidations and arbitrage losses. The infrastructure cost is justified by the product requirement.

Contracts read from a single, always-fresh source of truth: Developers don't need to implement complex pull mechanisms or worry about update triggers. This reduces contract complexity and audit surface. This matters for rapid prototyping and mainstream DeFi apps (e.g., Compound, Aave) where reliability and simplicity are paramount over marginal gas savings.

Proactive Data Delivery: Updates are streamed to contracts automatically upon price deviation or time threshold (e.g., Chainlink Data Streams). This enables sub-second latency for critical actions like liquidations on Aave or perpetual funding rate updates on dYdX, where milliseconds matter.

Gas Burden on Provider: The oracle network (e.g., Pyth Network publishers) pays for on-chain updates, shielding dApp users from variable gas fees. This creates a stable cost structure for protocols like Synthetix Perps, which require continuous price feeds without passing volatility to traders.

Gas-Only-When-Needed: Contracts fetch data via pull only at execution time (e.g., Uniswap v3's TWAP oracle). This eliminates wasteful updates for low-frequency applications like NFT floor price checks (Blur) or governance voting, optimizing for cost over speed.

Decoupled Infrastructure: No need to maintain a live streaming pipeline for every data point. Scaling involves adding more RPC endpoints and indexers (like The Graph) rather than complex event-driven systems. Ideal for batch processing historical data or serving thousands of low-traffic DeFi pools.

Consensus & Relay Costs: Maintaining continuous streams for 1000+ assets requires significant off-chain infrastructure (Chainlink nodes, Pyth validators) and constant on-chain write operations. This leads to high operational costs that scale linearly with data points, not usage.

User-Facing Delays: The pull transaction must wait for oracle response, adding network RTT and on-chain confirmation time. This creates poor UX for high-frequency trading and can be exploited in arbitrage scenarios where stale data is a vulnerability.