Pull Oracles vs Push Oracles: Reuse

On-demand data fetching: Contracts request data only when needed, paying the gas cost. This is optimal for low-frequency, user-initiated actions like checking a price for a single trade. Data is not automatically refreshed for others.

Proactive data broadcasting: Oracles push updates on-chain at regular intervals or when thresholds are met. This creates a publicly reusable data feed where one update (e.g., an ETH/USD price) can be consumed by thousands of contracts, amortizing the update cost.

Unique, one-off data needs where reuse is unlikely.

• Example: A protocol fetching a custom basket of assets for a specific user's portfolio valuation.
• Trade-off: Higher per-query cost, no passive benefit from others' updates.

High-frequency, shared data where many contracts depend on the same source.

• Example: A lending protocol (like Aave) needing a live ETH price for liquidations; a perpetual DEX (like dYdX) using a price feed.
• Trade-off: Requires upfront incentive model (e.g., fee from consumers) to keep data fresh.

Gas Efficiency for Users: Contracts only pay for data when they need it. This eliminates ongoing subscription fees, making it ideal for low-frequency, user-initiated actions like infrequent price checks for limit orders or one-off NFT valuations. Protocols like Chainlink's Any API and Pyth's Pull Oracle exemplify this model.

Higher Latency for Contracts: The contract must wait for a user or keeper to trigger the data fetch. This introduces front-running risk and is unsuitable for high-frequency DeFi (e.g., perpetuals, money markets) that require sub-second, autonomous updates. It adds operational overhead for protocols to manage update triggers.

Guaranteed, Low-Latency Updates: The oracle pushes data on a predefined schedule (e.g., every block). This provides real-time state consistency, critical for lending protocols (Aave, Compound) and derivatives (dYdX, GMX) that require continuous, accurate price feeds for liquidations and mark-to-market valuations.

Fixed, Ongoing Gas Costs: Contracts pay for every update, regardless of use. This leads to high, predictable overhead, which scales poorly with low-utilization data feeds. It's less optimal for event-driven or niche data (e.g., sports scores, weather) where on-demand fetching is more cost-effective. Major examples include Chainlink Data Feeds and Chronicle.

Deterministic, Low-Latency Updates: Data is broadcast on-chain proactively by the oracle network (e.g., Chainlink Keepers, Pyth Network's Wormhole-based push). This guarantees sub-second finality for price feeds, critical for high-frequency DeFi protocols like perpetual futures (GMX, Synthetix) and liquidations.

Higher Baseline Gas Costs & Complexity: The oracle pays gas for every update, regardless of usage. This cost is socialized across data consumers via fees or inflation, leading to inefficiency for low-activity assets. It also requires complex off-chain infrastructure for relayers and heartbeat monitoring.

Cost-Efficient & Demand-Driven: Data is fetched on-chain only when a user transaction requires it (e.g., Tellor, DIY Oracle with Chainlink Data Feeds). Users pay the gas, eliminating wasteful updates. Ideal for low-volume assets, NFT valuations (Upshot), and protocols where data freshness is not sub-second critical.

Unpredictable User Latency & UX Friction: Users experience variable transaction latency as they wait for the oracle query to resolve. This creates a poor UX for time-sensitive actions and exposes protocols to front-running risks if the pull mechanism is not carefully designed with commit-reveal schemes.