Pull-based Oracles vs Push-based Oracles: Data Update Triggers

On-demand data retrieval: Contracts pay gas only when they need an update. This is optimal for applications like NFT rarity checks or infrequent settlement where data freshness isn't critical. Protocols like Chainlink's Data Feeds (when used in a pull model) exemplify this.

User-invoked updates: Requires a transaction to trigger the data pull, adding 200ms-2s+ of latency and forcing users to pay gas. This creates a poor UX for DeFi trading or liquidation engines where speed is paramount.

Proactive data delivery: Oracles like Pyth Network push price updates to chains every 400ms on Solana or upon significant deviation. This is critical for perpetual futures (GMX, Synthetix) and money markets (Aave, Compound) to ensure accurate, timely liquidations.

Continuous gas expenditure: The network of relayers or first-party oracles (e.g., API3's dAPIs) must constantly submit transactions, incurring costs regardless of usage. This model favors high-volume, high-value applications that can amortize the cost, like institutional trading venues.

On-demand data fetching: Smart contracts request data only when needed, avoiding continuous gas expenditure. This matters for low-frequency applications like insurance claim settlements or NFT rarity updates, where paying for constant updates is wasteful. Protocols like Chainlink's Any API and Pyth's Pull Oracle exemplify this model.

Higher per-request latency: Each data update requires a full on-chain transaction, introducing a 12-30 second delay (1-2 Ethereum blocks). This is a critical weakness for high-frequency DeFi like spot DEXes or liquidations, where stale data can lead to arbitrage losses. The latency is a direct function of the underlying blockchain's block time.

Proactive data streaming: Oracles push updates on a schedule or when data deviates beyond a threshold (e.g., >0.5%). This ensures sub-second data freshness, which is mandatory for perpetual futures protocols (GMX, Synthetix) and money markets (Aave, Compound) to prevent price manipulation and ensure timely liquidations.

Continuous gas expenditure: The oracle (or a relayer) pays gas to update on-chain data feeds constantly, leading to high, predictable operational costs. This model is best suited for high-TVL, high-frequency protocols where the cost is amortized across vast user activity. Managing these costs requires sophisticated fee models, as seen in Chainlink Data Feeds and Pyth Network's push oracle.

Guaranteed Data Freshness: Oracles like Chainlink's Data Streams push updates on a fixed schedule (e.g., every 400ms). This ensures low-latency, sub-second updates for perpetuals on dYdX or GMX, where stale prices cause liquidations.

Reduced Contract Complexity: Smart contracts don't need custom logic to request data. This lowers gas costs for high-frequency updates and simplifies development for protocols like Aave, which rely on continuous price feeds for loan health.

Pay-Per-Use Model: Protocols like Uniswap v3's TWAP oracles only incur gas costs when data is explicitly requested. This is optimal for low-frequency, non-critical data (e.g., NFT floor price updates once per hour), preventing unnecessary on-chain bloat.

User-Initiated Updates: If a push oracle network halts, protocols freeze. With pull oracles (e.g., Tellor), any user can trigger an update, providing a decentralized fallback. This is critical for stablecoin redemption or governance contracts where liveness is paramount.

Fixed Operational Overhead: Networks like Pyth Network charge for constant data streaming, regardless of usage. This creates predictable but unavoidable costs, which can be prohibitive for nascent protocols with low transaction volume.

Update Lag Vulnerability: Contracts must wait for a user or keeper to request data. In volatile markets, this latency can exceed 10+ seconds, creating arbitrage windows and risk for options protocols like Lyra or Hegic that need near-real-time spot prices.