Pyth Pull vs Push Oracles: Scale

On-demand data retrieval: Consumers (dApps, smart contracts) pull price updates only when needed. This allows the network to support a theoretically unlimited number of data consumers without increasing on-chain load or costs for the oracle. This matters for mass-market dApps expecting millions of users or protocols with a vast array of derivative products.

Pay-per-use fee model: Protocol pays only for the data it actually consumes via a pull transaction, not for continuous broadcasts. This creates predictable, linear scaling of oracle costs with user activity. This matters for high-frequency protocols (Perps DEXs like Hyperliquid, Drift) where cost-per-trade is a critical metric.

Proactive data delivery: The oracle network pushes updates to a contract on every price change, guaranteeing all subscribed contracts have the latest data with minimal latency. This matters for latency-sensitive DeFi primitives (like money markets such as Aave or Compound) where liquidation systems must react to price movements in the same block.

Set-and-forget data streams: Once a feed is subscribed to, the protocol does not need to manage update fetching logic. This reduces integration complexity for a fixed set of core assets. This matters for established protocols with a stable set of price dependencies (e.g., stablecoin minting, basic lending) where development simplicity is prioritized.

On-demand data retrieval eliminates the need for continuous on-chain updates. This reduces gas costs by up to 90% for protocols with sporadic data needs (e.g., options platforms, limit orders). The system scales horizontally with user demand, not data feed count.

Users pull the latest price at execution time, guaranteeing freshness for their specific transaction. This is critical for high-frequency DeFi (e.g., perpetuals on Hyperliquid, margin calls) where stale data from a push oracle's update interval is unacceptable.

Added user transaction: Each pull requires an extra on-chain call to the Pyth contract, adding ~100-500ms of latency and complicating the front-end flow. This is a poor fit for simple swaps or wallets where UX simplicity is paramount.

Smart contracts must be explicitly designed to request and verify Pyth price updates. This adds development complexity compared to simply reading from a push oracle's latestAnswer(). Protocols like Aave or Compound, which need constant price availability, may find this model cumbersome.

Automated, on-chain updates: Data is pushed to consuming contracts automatically upon new price publication. This eliminates stale data risks for critical applications like perpetuals (e.g., Synthetix, Drift Protocol) and money markets, where a missed update can mean liquidations.

Publisher-pays gas model: The data provider (or a relayer) incurs the gas cost for every update on every supported chain. At scale, with 400+ price feeds across 50+ blockchains, this creates significant, recurring operational overhead compared to the user-pays pull model.

User-initiated, pay-per-use: Contracts only pull data when needed, paying the gas cost themselves. This is optimal for less time-sensitive applications (e.g., weekly reward calculations, settlement) or protocols on high-gas chains like Ethereum mainnet, where minimizing fixed costs is critical.

Update lag introduces risk: Relies on external actors (keepers, bots, or the protocol itself) to trigger pulls. During network congestion or low incentive periods, data can become stale, a major vulnerability for options pricing (e.g., Lyra) or fast-moving forex pairs.