Push Oracles vs Pull Oracles: Downtime Behavior

Push oracles like Chainlink Data Feeds excel at providing high-availability, low-latency data by proactively pushing updates to on-chain contracts. This model ensures data is available for immediate consumption, which is critical for high-frequency DeFi protocols. For example, a lending protocol like Aave relies on this continuous uptime to make instant liquidation decisions, with Chainlink maintaining >99.9% uptime for key price feeds. The trade-off is higher operational cost and potential for unnecessary on-chain writes if the data hasn't changed.

Pull oracles such as Tellor or a custom implementation take a different approach by having applications request data on-demand. This results in superior cost efficiency for low-frequency use cases, as you only pay for data when you need it. However, it introduces a critical trade-off: the requesting contract assumes the latency and gas cost burden, and the protocol must have robust fallback logic if the oracle is unresponsive. A protocol like Uniswap v3, which uses its own time-weighted average price (TWAP) as a pull-based reference, must account for potential gaps in its own liquidity.

The key trade-off: If your priority is maximizing uptime and minimizing latency for critical, real-time functions like liquidations or perpetual swaps, choose a push oracle. If you prioritize cost control and can tolerate request latency or implement your own retry logic for less time-sensitive data, a pull oracle may be optimal. Your protocol's downtime tolerance directly dictates which oracle risk profile you can accept.

Push oracles (e.g., Chainlink Data Feeds) excel at providing high-frequency, low-latency data with a 99.9%+ historical uptime. They proactively push updates on-chain, which is critical for perpetual DEXs like GMX or lending protocols like Aave that require sub-minute price updates to manage liquidations. This model centralizes liveness risk on the oracle network itself; if the Chainlink node operators experience an outage, all dependent protocols may stall until service is restored, as seen in isolated incidents requiring manual intervention.

Pull oracles (e.g., Pyth Network, API3 dAPIs) take a different approach by storing signed data on a low-cost layer (like Pythnet) for users to pull on-demand. This results in a trade-off of latency for resilience. The oracle's core data pipeline can fail without immediately breaking dApps, as the last attested data point remains verifiably available. However, this shifts the burden of liveness and gas costs to the end-user or a relayer, which can be problematic for high-throughput automated systems that cannot tolerate the pull transaction's added latency and potential for front-running.

The key trade-off: If your priority is maximizing uptime for real-time automation (e.g., derivatives, money markets), choose a battle-tested push oracle and accept its centralized liveness risk. If you prioritize cost-efficiency, censorship resistance, and the ability to gracefully degrade (e.g., NFT pricing, less time-sensitive analytics), a pull oracle offers a more resilient failure profile where the protocol's core functions aren't hostage to the oracle's immediate liveness.