Pull-Based Oracle

A pull-based oracle is a decentralized data feed where the consumer smart contract initiates the request for external data. This model is also known as a request-response model. The process is:

• A user or contract calls a function requiring off-chain data.
• The oracle network detects the request, fetches the data from specified sources.
• The data is delivered back in a single, final on-chain transaction. This creates a clear, auditable link between request and fulfillment.

The requester pays the gas costs for the data delivery transaction, providing direct cost accountability. This is efficient because:

• Data is only fetched and paid for when needed, avoiding the continuous gas costs of push-based updates.
• The requester can optimize for cost by batching requests or choosing simpler data types.
• There are no wasted transactions for data that no contract is currently using.

Data is retrieved at the moment it is needed, ensuring high freshness for time-sensitive applications. This is critical for:

• Perpetual futures and options pricing, where mark prices must reflect the latest market conditions.
• Dynamic NFT attributes that change based on real-world events.
• Insurance contracts that need to verify a specific condition (e.g., flight status) at a precise claim time. The data is not subject to staleness from pre-scheduled update cycles.

This architecture inverts the economic model of push oracles. Instead of data providers subsidizing updates, the end-user or dApp bears the cost for the specific data they consume. This aligns incentives, as:

• Requesters are motivated to optimize their data calls.
• Oracle nodes are compensated directly for fulfilling discrete jobs.
• It enables a wider variety of customizable data feeds without requiring upfront subsidies from providers.

A typical pull-based oracle system involves several key components working together:

• Consumer Contract: The smart contract that initiates the request.
• Oracle Contract: An on-chain contract that emits an event logging the data request.
• Off-Chain Oracle Node: Listens for events, retrieves data from APIs, and submits the signed response.
• Decentralized Oracle Network (DON): A group of independent nodes that provide cryptographically verified data to ensure security and reliability.

Pull-based oracles excel in scenarios requiring specific, verifiable data points on demand. Common applications include:

• Verifiable Random Function (VRF): Requesting a provably fair random number for NFTs or gaming.
• Cross-Chain Communication (CCIP): Requesting proof of an event or state from another blockchain.
• Custom Data Feeds: Fetching niche data (e.g., sports scores, weather) that isn't widely needed for continuous broadcast.
• Any API Call: Generalizing smart contract access to any authenticated web API.

Parametric insurance smart contracts use pull oracles to verify external events triggering payouts. A contract for flight delay insurance would pull data from a trusted aviation API only when a user submits a claim. This ensures the contract pays for data verification solely during the claims process, aligning costs with usage. The oracle fetches and attests to the flight's status from the authoritative source.

In cross-chain bridges and messaging protocols, a pull-based oracle can be used to verify the state of another blockchain. A contract on the destination chain requests proof that assets were locked or burned on the source chain before minting wrapped tokens. This lazy evaluation model is efficient for bridges with sporadic user activity, as data is only pulled and validated when a user initiates a transfer.

Systems that verify off-chain credentials or attestations often employ a pull model. A DAO's governance contract might request verification of a member's proof-of-humanity or KYC status from a decentralized identifier (DID) registry only when they attempt to create a proposal. This keeps sensitive data off-chain until the precise moment it's required for a specific contract function.

This is the core architectural pattern for pull oracles. The process involves:

• Request: A user's transaction calls a smart contract, which emits an event with a data query.
• Fetch: An off-chain oracle node (listening for events) retrieves the data from the API.
• Response: The node submits a signed transaction back to the contract with the result.
• Callback: The contract verifies the node's signature and executes its logic with the new data.

Pull oracles optimize for cost efficiency over speed. The key trade-offs are:

• Lower Operational Cost: No need to pay for continuous data pushes.
• Higher Per-Request Cost & Latency: The user's transaction must wait for the entire request-response cycle (off-chain fetch + on-chain confirmation), adding significant delay (seconds to minutes).
• Design Complexity: Contracts must manage asynchronous callbacks and state changes, which is more complex than reading a constantly updated on-chain value.

In a pull-based oracle model, the smart contract (the consumer) explicitly requests data when needed by calling a function on the oracle contract. This triggers a transaction where an oracle node fetches the data, submits it on-chain with a proof, and the consumer contract pays a fee for the service. This contrasts with push-based oracles where data is broadcast at regular intervals.

• Key Actors: Consumer Contract, Oracle Node, Oracle Contract.
• Process: Request → Fetch → Submit → Pay.
• Use Case: Ideal for low-frequency, event-driven updates like settling a prediction market or executing a limit order.

Pull-based architectures offer distinct benefits and impose specific constraints compared to push-based systems.

Advantages:

• Cost-Efficiency: Pay only for data when you use it; no cost for unused updates.
• Freshness: Data is as recent as the request, avoiding staleness for time-sensitive functions.
• Flexibility: Supports a vast array of custom, one-off data requests.

Trade-offs:

• Latency: Data is not pre-available; the request-and-fulfill cycle adds delay (seconds to minutes).
• Complexity: Requires more intricate contract logic to handle asynchronous callbacks.
• Reliability: Depends on a node being available to fulfill the specific request.

Pull-based oracles are deployed where data needs are irregular, customizable, or cost-sensitive.

• Dynamic NFT Minting: An NFT's traits are determined by pulling real-world data (e.g., weather, sports scores) at mint time.
• Insurance Payouts: A parametric insurance contract pulls data from a trusted source (e.g., NOAA for hurricanes) to verify an event and trigger a payout automatically.
• Custom DeFi Triggers: Executing a limit order or liquidation based on a specific asset reaching a precise price point, requested only when market conditions are near the threshold.

The security of a pull-based oracle hinges on the decentralization and correctness of its node network.

• Node Decentralization: Multiple independent nodes are typically tasked with the same request. Consensus mechanisms (like averaging or median selection) are applied to their responses to mitigate single-point failures or manipulation.
• Cryptographic Proofs: Reputable protocols provide cryptographic proof (e.g., a signature) from the oracle node, allowing the consumer to verify the data's origin.
• Oracle Reputation: Systems often incorporate reputation frameworks and staked bonds (SLAs) to penalize malicious or unreliable nodes, aligning economic incentives with honest reporting.

Understanding the fundamental difference between pull and push models is key to selecting the right oracle design.

The primary alternative to a pull-based model. In a push-based oracle, the data provider (or oracle node) is responsible for initiating updates by pushing new data on-chain at predefined intervals or when thresholds are met.

• Key Difference: Data is broadcast proactively, not requested on-demand.
• Use Case: Ideal for data that must be updated regularly (e.g., price feeds for lending protocols).
• Trade-off: Can incur higher gas costs for the provider, as they pay for transactions even when data isn't used.

A core security challenge for all oracles. Pull-based designs often rely on cryptographic proofs to verify that the fetched data is authentic and untampered.

• TLSNotary Proofs: Cryptographically prove data was fetched from a specific HTTPS endpoint.
• Signature Verification: Data is signed by the oracle node's private key, proving its origin.
• Commit-Reveal Schemes: Used to prevent front-running by first committing to data (hash) and later revealing it.

A network of independent nodes that collectively source and deliver data. Pull-based requests can be distributed across such a network for enhanced reliability and censorship resistance.

• Redundancy: Multiple nodes pull data from independent sources.
• Aggregation: Results are aggregated (e.g., medianized) to produce a single consensus value.
• Examples: Chainlink Decentralized Data Feeds operate on this principle, though they typically use a push model for final delivery.

A critical design consideration. In a pure pull model, the end-user's contract must pay the gas for the on-chain callback. Solutions have emerged to abstract this cost.

• Gasless UX: Protocols may use meta-transactions or sponsored transactions, where a relayer pays the gas fee on behalf of the user.
• Fee Abstraction: Oracle services may bundle the data cost and gas fee into a single credit system.
• Economic Security: The cost of pulling data must be less than the value of the transaction it enables.

The underlying communication pattern. A smart contract (the requester) sends a data request (often as an off-chain event log). An off-chain oracle node listens, fetches the data, and sends back a response transaction.

• Standardization: Formats like Chainlink's Oracle Request standardize this interaction.
• Flexibility: Allows for arbitrary, one-off data queries beyond predefined feeds.
• Components: Involves an on-chain Oracle contract, off-chain node software, and a Job Specification defining the task.