Push-Based Oracle

The core mechanism where the oracle network pushes data updates to subscribed smart contracts without waiting for an on-chain request. This is the opposite of the pull-based model. Key aspects include:

• Event-Driven Updates: Data is transmitted when predefined conditions are met (e.g., price deviation threshold, time interval).
• Subscriber Model: Smart contracts register or subscribe to specific data feeds.
• Reduced Latency for Critical Updates: Eliminates the request-response cycle delay for time-sensitive data.

Push oracles shift the gas cost burden for data delivery from the end-user's contract to the oracle service or data consumer. This has significant implications:

• Predictable Operating Costs: DApp developers can budget for data feeds as a service cost, rather than users paying variable gas for pulls.
• Removes User Friction: Users don't pay gas for oracle calls, simplifying the transaction experience.
• Oracle Incentive Alignment: The entity paying for the push (often the DApp or data provider) is directly incentivized to optimize update efficiency and cost.

Supports multiple update triggers essential for different application needs:

• Threshold-Based Updates: Push new data only when the off-chain value changes by a specified percentage (e.g., >0.5% for a price feed). This optimizes gas usage.
• Heartbeat Updates: Guaranteed periodic updates (e.g., every block, every hour) to ensure data freshness even during low volatility.
• On-Demand Pushes: A hybrid approach where a contract can signal the need for an immediate update, which is then pushed.

The push model is particularly suited for applications where missing an update can cause system failure or significant loss.

• Liquidation Engines: In lending protocols, timely price updates are critical to trigger liquidations before positions become undercollateralized. A push ensures the update is attempted.
• Derivative Settlements: Options or futures that expire at a specific time require a precise price push at expiry.
• Alerts & Keepers: Can act as a decentralized keeper network, pushing transactions to execute when conditions are met off-chain.

Requires an on-chain mechanism to manage which contracts receive data pushes and under what terms.

• Registry Contracts: Maintain a list of authorized subscriber addresses for a given data feed.
• Subscription Models: May implement fee-based subscriptions, granting push access for a period.
• Permissioning: Allows for private data feeds where pushes are only sent to whitelisted contracts, useful for enterprise or institutional DeFi applications.

Understanding the trade-offs between push and pull models is crucial:

• Initiator: Push = Oracle, Pull = Smart Contract.
• Gas Payer: Push = Oracle/Sponsor, Pull = End User (tx sender).
• Data Freshness: Push = Proactively maintained, Pull = Only fresh when requested.
• Use Case Fit: Push is optimal for high-frequency, critical data (e.g., DEX prices, liquidation triggers). Pull is optimal for low-frequency, on-demand data (e.g., NFT rarity score, weather data for a parametric insurance claim).

Push-based oracles enable reactive NFTs and game assets that change based on external events. An oracle can push data like real-world weather, sports scores, or in-game leaderboard updates to a smart contract, which then updates the NFT's metadata or attributes on-chain.

• Key Function: Providing real-time data to mutate NFT state.
• Use Case: An NFT that changes its appearance based on the holder's local temperature or a game item that gains power based on real-time esports results.

A decentralized oracle network where data is pulled on-demand by a smart contract, typically via a user transaction. This is the inverse of a push-based model.

• Mechanism: A contract calls an oracle function, which triggers a query. The response is delivered in a subsequent transaction.
• Use Case: Ideal for infrequent, user-initiated data needs where latency is less critical, such as verifying a specific NFT's rarity.
• Trade-off: Introduces higher latency (two transactions) but can be more gas-efficient for sporadic requests.

A collection of independent node operators that collectively source, aggregate, and deliver data to smart contracts. Both push and pull models can be implemented atop a DON.

• Core Function: Provides cryptographic proof and consensus on data validity off-chain before it's written on-chain.
• Key Feature: Enhances security and reliability by eliminating single points of failure.
• Example: Chainlink Network is a prominent DON that supports both data delivery patterns.

A continuously updated on-chain data stream, such as a price for an asset pair (e.g., ETH/USD). This is the most common application of a push-based oracle.

• Operation: Oracle nodes push aggregated price updates to an on-chain aggregator contract at regular intervals or when price deviations exceed a threshold.
• Purpose: Provides a low-latency, gas-efficient reference price for DeFi protocols like lending markets and derivatives.
• Characteristic: Maintains a persistent, publicly accessible state variable that any contract can read.

A cryptographic oracle that provides provably random and tamper-proof numbers. It typically uses a pull-based request-and-response model.

• Process: The requesting contract submits a seed, pays a fee, and later receives random words and a cryptographic proof.
• Contrast to Push: VRF is request-specific and not a continuous feed, making the pull model more suitable.
• Application: Essential for NFT minting, gaming outcomes, and fair lottery mechanisms on-chain.

A decentralized network that automatically executes predefined smart contract functions based on conditions (e.g., time or price). It is a key complementary service.

• Synergy with Push Oracles: Automation can trigger actions (like liquidations) immediately after a push oracle updates a critical data feed.
• Function: Handles the execution layer, while oracles handle the data layer.
• Example: A keeper network that calls a liquidate() function once a push oracle reports a user's collateral ratio falling below a threshold.

An attack vector where an adversary exploits the data source or delivery mechanism of an oracle to corrupt a smart contract's state. Understanding this risk highlights design trade-offs.

• Push Model Consideration: While reducing latency, frequent pushes from a less secure oracle can increase attack surface.
• Mitigation: Relying on decentralized data sources, cryptographic proofs, and consensus mechanisms is critical for both push and pull models.
• Famous Example: The 2020 bZx flash loan attack involved manipulating a single-source price feed.