Pyth Network's Pull vs Push Oracle Model: A Technical Comparison

On-demand data retrieval: Smart contracts request data only when needed, paying for it via a fee. This eliminates continuous gas costs for data updates.

Key for: High-frequency trading protocols (e.g., perpetuals on Drift Protocol) and applications with sporadic, user-initiated actions where minimizing baseline operational cost is critical.

Latency and UX complexity: Each price request adds 400-800ms of latency and requires handling a callback. This creates a multi-transaction flow.

Problematic for: Automated systems (e.g., lending liquidations on Solend) that require sub-second, guaranteed price updates without user interaction. The callback pattern adds significant development overhead.

Predictable, low-latency updates: Oracles (e.g., Chainlink Data Feeds) push data on-chain at regular intervals, providing a constantly available on-chain reference price.

Key for: Lending protocols (Aave, Compound), stablecoins, and any application requiring a persistent, low-latency price for core logic without user-triggered calls.

Continuous gas overhead & data relevance: Paying for updates every block (e.g., ~12 sec on Ethereum) is expensive, even if the data isn't used. This can lead to stale data if update frequency is reduced to save costs.

Problematic for: Newer chains with volatile gas prices or niche assets where maintaining a frequently updated on-chain feed is economically unviable.

On-demand data consumption: Protocols pay only for the price updates they explicitly request. This eliminates the gas cost of processing unsolicited updates, which is critical for low-frequency applications like lending liquidations or periodic settlements. For protocols with predictable, infrequent update needs, this can reduce oracle costs by over 90% compared to a continuous push stream.

Deterministic update timing: Developers control exactly when a price is fetched, guaranteeing sub-second freshness at the moment of execution. This is essential for high-precision DeFi primitives like perpetual futures or options, where a stale price at settlement can lead to significant arbitrage losses. It removes the uncertainty of push model update intervals.

Passive data reception: Smart contracts receive prices automatically at fixed intervals (e.g., every 3-5 seconds). This simplifies contract logic, as developers don't need to manage update calls. It's the proven standard for high-frequency trading venues and AMMs like Uniswap v3, which require a constant, low-latency price feed to function correctly without manual triggers.

No callback management: Contracts avoid the complexity and gas overhead of initiating pull transactions and handling the callback. This reduces integration risk and attack surface, making it preferable for rapid prototyping and simpler protocols where minimizing on-chain logic is a priority. The model is well-understood with extensive tooling support from providers like Chainlink.

Added user transaction latency: The pull requires a two-step process: request and callback. This adds ~1-2 extra blocks of latency for the end-user, which can be a poor UX for retail-facing dApps expecting instant swaps. It shifts gas cost and complexity to the user's transaction flow.

Inefficient for low-activity protocols: Paying for continuous updates that go unused wastes gas, especially on high-throughput chains. This creates unnecessary cost overhead for nascent or niche protocols with low transaction volume. It can also lead to network congestion with redundant data broadcasts.