Interval Feeds vs Request Feeds

Automated updates: Data is pushed on-chain at fixed intervals (e.g., every block, 30 seconds). This matters for real-time monitoring like DeFi lending/borrowing protocols (Aave, Compound) that need constant price checks for liquidations.

Continuous on-chain cost: Updates occur regardless of demand, leading to higher aggregate gas consumption for the network. This matters for cost-sensitive protocols where data freshness is less critical than operational overhead.

Pull-based model: Data is fetched only when a user or contract explicitly requests it, minimizing baseline gas costs. This matters for event-driven applications like insurance payouts (Nexus Mutual) or options settlements that need data at specific moments.

User-incurred latency: The requesting contract must handle the callback, adding complexity and a 1-2 block delay. This matters for high-frequency trading or any application where sub-block finality and simple integration are paramount.

Guaranteed Freshness: Data is pushed on-chain at fixed intervals (e.g., every 5 minutes for Chainlink Data Streams). This ensures deterministic latency for applications like perpetual DEXs (GMX, Synthetix) that require continuous price updates without user action.

Gas Efficiency for High Frequency: Update costs are amortized across all users of the feed. For protocols with heavy volume like Aave or Compound, this creates predictable, lower per-user oracle costs compared to paying for individual pull requests.

Inefficient for Low Activity: Continuously updating data for dormant assets or chains wastes gas. This model struggles with long-tail assets or niche data pairs where update frequency outpaces demand, as seen with some less-liquid Chainlink feeds.

Reliance on Off-Chain Infrastructure: The update cycle is initiated by off-chain nodes. This introduces a liveness dependency on these nodes, creating a potential single point of failure if the node network halts, unlike decentralized pull mechanisms.

Pay-Per-Use Efficiency: Data is fetched only when a user transaction requires it (e.g., Chainlink Any API, API3 dAPIs). Ideal for low-frequency events like insurance payouts (Nexus Mutual) or NFT rarity checks, eliminating idle update costs.

Unpredictable User Experience: The end-user pays the gas and waits for the entire request-fulfillment cycle, adding variable latency (5-30+ seconds). This is problematic for front-ends requiring instant quotes, unlike the sub-second finality of pre-pushed data.

Fixed operational overhead: Costs are borne by the oracle service and amortized across all users, leading to predictable gas fees for data consumers. Latency is bound by the update interval (e.g., every block, 12 seconds). This matters for high-frequency dApps like perpetual DEXs or lending protocols that need consistent, time-bound data without user-initiated transactions.

Inherent update delay: Data is only as fresh as the last scheduled update. During volatile market events, price feeds can be stale until the next interval, creating arbitrage opportunities or liquidation delays. This is a critical trade-off for options protocols or NFT floor price oracles where real-time accuracy is paramount.

User-triggered precision: Data is fetched at the exact moment needed by the smart contract, guaranteeing freshness for that specific transaction. This is ideal for low-frequency, high-value settlements like OTC trades, insurance claim payouts, or bespoke derivatives where the cost of a single stale data point is catastrophic.

Unpredictable gas fees: The requester pays all gas for the data fetch and callback, which can spike during network congestion. It also introduces callback complexity, requiring smart contracts to handle asynchronous responses. This adds development overhead and is less suitable for high-volume automated systems like AMMs.