Pull-Based Oracle

In a pull-based oracle system, data is not continuously streamed to the blockchain. Instead, a smart contract initiates a request when it needs specific data, triggering a transaction to fetch it. This contrasts with push oracles, which broadcast data updates automatically, often incurring gas costs for unused data.

• Example: A lending protocol only requests a user's collateral price when they attempt to borrow, rather than maintaining a constantly updated price feed.

The transaction cost (gas fee) for fetching and delivering oracle data is borne directly by the end-user or the specific contract function that initiates the request. This creates a clear and efficient cost attribution model.

• Advantage: Protocols and users only pay for the data they actually consume, eliminating the subsidy costs associated with maintaining universal push feeds.

Data is pulled directly into the transaction that requested it, making the oracle's response an atomic part of the transaction's execution. This provides strong cryptographic guarantees that the data was available and verified at the exact block height of the request.

• Key Benefit: Eliminates the risk of stale data or race conditions that can occur in push-based systems where data updates and contract executions are separate events.

The data retrieval and delivery process is performed by a permissionless network of oracle nodes or a decentralized automation network (like a keeper network). These nodes compete to fulfill data requests, with the winning response being delivered on-chain.

• Mechanism: This creates a trust-minimized and censorship-resistant system for executing off-chain computations and data fetching.

Pull-based oracles enable the creation of custom data feeds tailored to a specific smart contract's needs. Developers can define the exact data source, aggregation method, and update frequency, rather than relying on a one-size-fits-all feed.

• Use Case: A derivatives contract can request a volume-weighted average price (VWAP) from three specific DEXs over a precise 1-hour window.

This is the core operational model for a pull-based oracle. A smart contract (the requester) emits an on-chain event or stores a request. An off-chain oracle node (the relayer) monitors the blockchain, processes the request by fetching external data, and submits the result back in a subsequent transaction. This decouples the data fetch from the initial contract call, introducing a latency period but allowing for gas cost optimization and customizable data sources.

While often cited as a push oracle, Chainlink's decentralized price feeds use a hybrid pull-push mechanism. A network of nodes pulls price data from multiple exchanges off-chain, aggregates it, and periodically pushes the aggregated result on-chain for any contract to consume. The critical 'pull' component is the off-chain data sourcing and consensus, which makes the on-chain data highly reliable and resistant to manipulation.

Tellor is a canonical example of a pure pull-based oracle with a staking and dispute mechanism. Data requests are posted on-chain. Miners (reporters) compete to pull the correct off-chain data, submit it with a Proof-of-Work, and stake TRB tokens. Other participants can dispute incorrect submissions. This creates a cryptoeconomic security model where data accuracy is enforced by financial incentives and penalties, rather than frequent on-chain updates.

Used by protocols like UMA and Optimism, this pattern assumes data submissions are correct unless challenged. A proposer pulls data and posts it on-chain with a bond. During a dispute window, anyone can challenge the submission by staking a larger bond, triggering a verification process (often via a DAO or decentralized court). This is highly gas-efficient for data that is rarely disputed, such as election results or custom price identifiers.

Pull oracles are ideal for non-time-sensitive, high-stakes data. For example, a flight delay insurance dApp only needs to know if a specific flight arrived late once, at the time of claim. A user submits a claim, triggering a data request. An oracle node later pulls the flight status from an authoritative API and submits the proof. This avoids the cost of continuously pushing flight data for all possible flights.

Protocols like Chainlink VRF utilize a pull-based design for generating randomness. The requesting contract makes a call and provides a seed. An oracle node pulls the request, generates a random number and a cryptographic proof off-chain, then delivers it back. The contract can cryptographically verify that the number was generated correctly and was not known before the request, ensuring fairness for NFTs, gaming, and lotteries.

The requesting contract controls when data is fetched, creating a race condition window. If a transaction's execution depends on stale data, an attacker can front-run the update call. Key risks include:

• Expired Data: Using price data from a block that is no longer valid.
• MEV Extraction: Bots can sandwich the data pull transaction if the new data triggers a state change with economic value.
• Solution: Implement time-based validity checks (e.g., require(block.timestamp - updatedAt < MAX_DELAY)) and consider commit-reveal schemes for sensitive operations.

Security shifts from the oracle to the requesting contract logic. Vulnerabilities in the update function become critical:

• Access Control: An unprotected updatePrice() function can be called by anyone, potentially with malicious data.
• Gas Griefing: Attackers may call the function with high gas to force updates at inopportune times, draining contract funds.
• Solution: Implement robust access control (e.g., OpenZeppelin's Ownable), rate-limiting, and ensure the contract has a perpetual gas budget for essential updates.

The contract must cryptographically verify that the data it receives is authentic and untampered. Relying on a single, unsigned off-chain source is a major risk.

• On-Chain Verification: Use oracle contracts (like Chainlink Data Feeds) that sign data with a decentralized network's private keys. The pull contract verifies these signatures.
• Data Structure: Ensure the payload includes a timestamp and round ID to prevent replay attacks.
• Solution: Never parse raw data from an untrusted API directly. Always pull from a consensus-based, cryptographically verifiable on-chain source.

A pull-based system requires a willing and incentivized party to pay gas and trigger the update. If no one is incentivized to call the update function, the system stalls (liveness failure).

• Keeper Networks: Projects like Chainlink Keepers or Gelato provide decentralized services to automate these calls for a fee.
• Incentive Design: The contract's economic model must ensure updates are profitable for keepers (e.g., via fees or system rewards) and critical for users.
• Risk: Underfunded contracts or poorly set incentives lead to stale data and a non-functional application.

The conditions that trigger a data pull can be exploited. If updates are based on predictable thresholds (e.g., "update if price moves 5%"), attackers can manipulate the underlying market to trigger or suppress updates.

• Example: A large trade on a DEX could be used to move the spot price, triggering an oracle update at a manipulated value.
• Solution: Use time-weighted average prices (TWAPs) or heartbeat updates instead of, or in addition to, deviation-based triggers. This reduces the profitability of short-term manipulation.

Understanding the security trade-off between oracle models is crucial.

• Push-Based Oracle (e.g., traditional data feed): Centralizes risk on the oracle network to update correctly. Risks include transaction ordering dependency and broadcast cost for the oracle.
• Pull-Based Oracle: Decentralizes the update action but centralizes risk on the caller's logic and incentives. The primary risk shifts from "can the oracle be trusted to push?" to "will the data be pulled on time and verified correctly?"
• Hybrid Models: Many modern systems use pull-based queries to verifiable on-chain data feeds that are themselves maintained by push-based decentralized networks, combining strengths.

An oracle design pattern where data is automatically pushed to smart contracts by the oracle network. This is the primary alternative to pull-based models.

• Key Difference: Proactive vs. reactive data delivery.
• Use Case: Ideal for high-frequency data needs like price feeds for DeFi lending protocols.
• Trade-off: Higher gas costs for the oracle provider, but lower latency for the dApp.

A cryptographic proof, often using Trusted Execution Environments (TEEs) or cryptographic attestations, that verifies the origin and integrity of data fetched by a pull-based oracle.

• Purpose: Provides cryptographic assurance that the data came from the specified, untampered source.
• Mechanism: Examples include Intel SGX attestations or TLSNotary proofs.
• Benefit: Enables trust-minimized data retrieval, a core goal of pull-based systems.

The on-chain smart contract component that initiates a data request in a pull-based oracle system. It is the requester of external data.

• Function: Calls a specific oracle method (e.g., requestData()), specifying the needed data source and callback function.
• Responsibility: Pays the oracle fee and defines the conditions for the data delivery.
• Lifecycle: Remains idle until it needs data, then becomes active for a request cycle.

A function within the oracle client smart contract that is automatically executed by the oracle when the requested data is delivered on-chain.

• Mechanism: The oracle's response transaction calls this function, passing the retrieved data as an argument.
• Critical Role: Contains the core application logic that uses the verified external data (e.g., settling a bet, executing a trade).
• Security: Must be carefully designed to handle oracle responses securely.

The end-to-end process of obtaining data via a pull-based oracle, from initiation to on-chain settlement.

Typical Steps:

1. Request: Client contract calls the oracle contract.
2. Off-chain Fetch: Oracle node retrieves and verifies data from the source.
3. Response: Oracle submits a transaction with the data and proof.
4. Callback: The client's callback function executes with the new data.

• Key Feature: The smart contract's state change is conditional on the oracle's response.

The economic structure defining who pays for transaction fees in an oracle system. Pull-based oracles fundamentally shift this model.

• Push-Based: Oracle pays gas to update many contracts, costs are amortized across users.
• Pull-Based: The requesting dApp (client) pays gas for its specific data delivery. This aligns costs directly with usage.
• Implication: Makes infrequent, high-value data requests economically viable.