A pull oracle (or on-demand oracle) is a decentralized oracle architecture where the data retrieval process is initiated by the smart contract itself. Unlike a push oracle that automatically broadcasts data, a pull model requires the contract to call a specific function, triggering a network of oracle nodes to fetch, verify, and submit the requested external data in a single transaction. This design shifts the transaction fee burden and initiation logic to the requesting contract, providing more explicit control over when and what data is consumed.
LABS
Glossary
Pull Oracle
A pull oracle is a decentralized oracle model where a smart contract actively initiates a request to fetch data from an off-chain source when needed.
Chainscore © 2026
definition
BLOCKCHAIN ORACLE ARCHITECTURE
What is a Pull Oracle?
A pull oracle is a decentralized data-fetching mechanism where on-chain smart contracts explicitly request off-chain data, which is then delivered by a network of node operators in response to that request.
The core technical workflow involves a two-step process: a data request and a data fulfillment. First, a user or contract sends a transaction calling a function like requestData(), which emits an event containing the query parameters (e.g., "price of ETH/USD"). Oracle nodes, which are continuously monitoring the blockchain for these events, then compete to fetch the data from pre-defined APIs, aggregate the results to achieve consensus, and submit the final attested data point back to the contract in a subsequent transaction. This model is inherently permissionless for data requesters.
Key advantages of the pull oracle model include cost predictability and gas efficiency for node operators, as they only perform work and pay gas when explicitly paid to do so. It also reduces on-chain spam and unnecessary data storage. However, it introduces latency (the time between request and fulfillment) and requires the requesting contract to handle callback logic. Prominent examples include Chainlink's Any API and Decentralized Data Feeds when used via their latestAnswer() function, which internally manages the request-fulfill cycle.
This architecture is particularly well-suited for low-frequency, high-value transactions where data is not needed continuously, such as insurance claim payouts triggered by a flight delay, settlement of a periodic derivatives contract, or verification of a real-world asset's status. The explicit request acts as an audit trail, making it clear which external data was used to trigger a specific on-chain state change, which is valuable for regulatory compliance and dispute resolution.
When comparing oracle designs, the choice between pull and push oracles (which proactively update data at regular intervals) is fundamental. Push oracles, like standard price feeds, are better for high-frequency data needs (e.g., constant DEX price updates) but incur ongoing costs. The pull model's request-based nature makes it a foundational primitive for building more complex, verifiable computation systems where the oracle network's role can extend beyond data delivery to include off-chain computation.
how-it-works
ORACLE MECHANISM
How a Pull Oracle Works
A pull oracle is a decentralized oracle design pattern where data is not pushed onto the blockchain automatically. Instead, a smart contract explicitly requests, or 'pulls,' external data on-demand when a user initiates a transaction.
In a pull oracle system, the on-chain smart contract holds the responsibility for initiating data retrieval. When a function requiring external data is called, the contract emits an event or makes a call to an oracle contract. An off-chain component, often called a relayer or oracle node, monitors the blockchain for these requests. Upon detecting one, it fetches the required data from an external API, generates a cryptographically signed data attestation, and submits it back to the blockchain in a separate transaction. The requesting contract then verifies the signature and uses the data to complete its execution. This model contrasts with push oracles, which proactively broadcast data updates.
The key architectural components include the on-chain requester contract, the off-chain oracle node, and a data signing mechanism. The oracle node's role is purely responsive; it does not decide when data is needed but acts upon explicit on-chain signals. This design offers significant gas efficiency for applications where data is not needed constantly, as transactions (and associated costs) only occur when data is actually required. However, it introduces latency and a two-transaction model: one to request the data and a second, separate transaction to deliver it, which the end-user must typically wait for or trigger.
A primary use case for pull oracles is in optimistic systems or applications where data freshness is critical only at specific moments. For example, a derivative settlement contract might only need the price of an asset at the exact moment of expiry. Using a pull oracle, the settlement can be triggered manually, pulling the precise price at that time rather than relying on a potentially stale pushed update. This model also shifts gas cost responsibility, often placing it on the party who benefits from the data retrieval, which can be more economically efficient than having an oracle service pay to push data for many unused updates.
Security in a pull model hinges on the cryptographic attestation provided by the oracle node. The data payload is signed by a known oracle operator or a decentralized network of nodes, and the on-chain contract verifies this signature against a whitelist or a decentralized registry. This ensures the data's authenticity and integrity. However, the trust model is similar to push oracles; the application must trust the oracle node operator(s) to provide correct data. Techniques like data aggregation from multiple sources and stake-slashing for malicious behavior are used to enhance security and reliability within this framework.
Implementing a pull oracle requires careful smart contract design to handle the asynchronous nature of the request-response cycle. Contracts must manage state to track pending requests, prevent replay attacks, and gracefully handle scenarios where a data response is never received. Developers often use a pattern involving unique request IDs and callback functions. While more complex for developers than simply reading from a constantly updated data feed, the pull model provides fine-grained control over data timing and cost, making it a foundational pattern for building efficient, user-centric decentralized applications.
key-features
ARCHITECTURE
Key Features of Pull Oracles
Pull oracles are a decentralized data-fetching architecture where smart contracts actively request external data on-demand, contrasting with push oracles that broadcast data automatically.
01
On-Demand Data Retrieval
In a pull oracle model, the smart contract (or a user transaction) initiates the data request. This is a client-initiated process where the contract explicitly calls a function to fetch the latest price, random number, or other data point. This contrasts with a push oracle, which automatically updates contracts at regular intervals.
- Example: A lending protocol calls
getLatestETHPrice()to check collateralization before liquidating a position.
02
Gas Efficiency & Cost Control
The requester (the contract or user) pays the gas fees for the data transaction. This allows for precise cost attribution and optimization. Contracts only pay for data when it's needed for execution, avoiding the ongoing costs of maintaining fresh data in storage.
- Key Benefit: More efficient for applications with sporadic or user-triggered data needs, as costs are incurred per-request rather than continuously.
03
Deterministic Execution Path
Because the data request is part of the transaction, the entire process—from request to callback with the data—must complete within a single block. This creates a synchronous flow but requires oracle nodes to be highly responsive.
- Architecture: The flow is: User TX → Contract requests data → Oracle network fetches & signs → Data is returned in a callback → Contract logic completes.
04
Enhanced Security Model
Pull oracles can reduce certain attack surfaces. Since data is fetched for a specific request, there is no persistent, updatable data feed inside the contract that could be manipulated by a single transaction. Security relies on the decentralization and cryptographic signing of the oracle network responding to the pull request.
- Consideration: The transaction is vulnerable if the oracle network is unresponsive or compromised at the exact moment of the request.
05
Implementation Pattern
The standard technical pattern involves a two-transaction process, often abstracted for developers.
- Request: Contract calls an oracle contract's
requestData()function. - Fulfillment: Off-chain oracle nodes fetch the data, sign it, and submit it back via the oracle contract's
fulfillRequest()function, which then calls back the original requester.
Libraries like Chainlink Functions exemplify this pattern for arbitrary computation.
06
Use Case Examples
Pull oracles are ideal for applications where data is needed unpredictably or is user-specific.
- NFT Random Minting: Fetching a verifiable random number (VRF) when a user mints an NFT.
- Insurance Payouts: Requesting specific weather data or flight status only when a user submits a claim.
- Customized DeFi: A user's transaction that requires a specific asset price at that exact moment.
DATA DELIVERY ARCHITECTURE
Pull Oracle vs. Push Oracle
A comparison of the two fundamental models for how oracles deliver external data to a blockchain smart contract.
| Feature | Pull Oracle (On-Demand) | Push Oracle (Publish-Subscribe) |
|---|---|---|
Data Delivery Trigger | Smart contract request (pull) | Oracle-initiated broadcast (push) |
Gas Fee Payer | End user / requesting contract | Oracle service / data provider |
Latency | Higher (requires on-chain transaction) | Lower (data is pre-available) |
Data Freshness | On-demand, potentially stale | Pre-scheduled, proactively updated |
Use Case Fit | Infrequent, user-initiated actions | Continuous, time-sensitive data feeds |
On-Chain Cost Model | Pay-per-query | Subscription / premium fee |
Example Implementation | Chainlink Any API, Witnet | Chainlink Data Feeds, Pyth Network |
use-cases
PULL ORACLE
Common Use Cases
A pull oracle is a decentralized data-fetching mechanism where the on-chain consumer (e.g., a smart contract) initiates and pays for a specific data request, which is then fulfilled by a network of off-chain node operators. This model contrasts with push oracles, which broadcast data continuously.
01
On-Demand Price Feeds
Used for low-frequency, high-value transactions where paying for data only when needed is cost-effective. Common in insurance claims processing, options settlement, or custom derivatives that trigger on specific dates. The contract pulls the exact price (e.g., ETH/USD) at expiry from oracles like Chainlink or API3, minimizing gas fees versus constant updates.
02
Verifiable Randomness
Critical for provably fair applications like NFT minting, gaming, and lottery systems. A smart contract requests a random number, prompting oracle nodes to generate and deliver a random value along with a cryptographic proof (e.g., a VRF proof). This ensures the outcome is tamper-proof and cannot be manipulated by the contract creator or miners.
03
Cross-Chain Communication
Enables smart contracts on one blockchain to verify and act upon events or state from another chain. A bridge or interoperability protocol contract pulls a cryptographic proof (like a Merkle proof) of an event from source-chain oracles (e.g., LayerZero's Oracle network). This proof is then verified on-chain to mint assets or trigger actions.
04
Conditional Execution & Keeper Networks
Facilitates automated smart contract maintenance. A contract's state (e.g., a loan's health factor) is monitored off-chain. When a predefined condition is met (e.g., liquidation threshold), a keeper bot or network (like Chainlink Keepers) is paid to pull the necessary data and submit the transaction to execute the function (liquidate, rebalance).
05
Customized Data for DeFi
Ideal for bespoke financial instruments requiring non-standard data. A structured product smart contract can pull a specific basket of asset prices, a TWAP (Time-Weighted Average Price), or a proprietary index value at settlement. This allows for complex derivatives without needing a persistent, expensive price feed for every underlying asset.
06
Data Authentication & Proof of Publication
Used to verify the existence and integrity of off-chain data at a specific time. A contract can request a cryptographic commitment (like a hash) of a document, tweet, or API response from an oracle. The oracle pulls the data, generates the proof, and delivers it on-chain, enabling use cases in supply chain provenance, legal attestations, and social media verification.
ecosystem-usage
PULL ORACLE
Protocols & Ecosystem Usage
A pull oracle is a decentralized data feed where the on-chain contract or user initiates the request for external data, pulling it onto the blockchain only when needed.
01
Core Mechanism: On-Demand Data
In a pull oracle model, the smart contract or user is responsible for initiating the data request. This is the opposite of a push oracle, which automatically broadcasts data. The process typically involves:
- A contract calls an oracle function.
- An off-chain oracle node (or decentralized network) fetches the data.
- The data is returned in a subsequent transaction, often requiring a second call to retrieve it. This creates a two-transaction model that shifts gas costs and timing control to the requester.
02
Primary Use Case: Cost Efficiency
Pull oracles are favored for applications where data updates are infrequent or user-initiated, as they avoid the continuous gas costs of push updates. Key examples include:
- Insurance claims: Data is only fetched to settle a specific claim.
- Dynamic NFTs: Metadata updates triggered by a user action.
- Governance: Pulling final vote results or proposal status on-demand. This model prevents paying for unnecessary data broadcasts, making it economically efficient for sporadic events.
04
Trade-off: Latency & Complexity
The main trade-off for cost efficiency is increased latency and contract complexity.
- Latency: Data is not immediately available; it requires waiting for off-chain fetching and a second blockchain transaction.
- Complexity: Smart contracts must implement a callback function to receive the data, managing request IDs and potential failures.
- User Experience: May require users to submit two transactions (request, then retrieve), which is not ideal for high-frequency trading or real-time applications.
05
Comparison with Push Oracles
Understanding the distinction is crucial for system design:
Pull Oracle (On-Demand)
- Initiator: Consumer (Contract/User)
- Gas Payer: Consumer
- Data Freshness: Stale until requested
- Best For: Irregular, user-driven events
Push Oracle (Publish/Subscribe)
- Initiator: Oracle Service
- Gas Payer: Oracle Service/Protocol
- Data Freshness: Periodically updated
- Best For: Regular updates (e.g., price feeds)
06
Security Considerations
While decentralized pull oracles inherit general oracle security, their on-demand nature introduces specific considerations:
- Request Authenticity: The oracle must cryptographically prove the response matches the original request (e.g., via request IDs).
- Callback Execution: The
fulfillfunction must be protected from reentrancy and ensure only the authorized oracle can call it. - Front-running: In public mempools, the data retrieval transaction could be front-run if the result is predictable and valuable. Proper implementation requires careful attention to the request-response lifecycle.
security-considerations
PULL ORACLE
Security Considerations
A pull oracle is a decentralized oracle design where data is retrieved on-demand by the consuming smart contract, rather than being pushed to it. This architecture introduces distinct security trade-offs compared to push oracles.
01
Data Freshness & Liveness
The primary risk is stale data. If a user transaction triggers the pull, the data is only as fresh as the last update cycle. This can be exploited through time-based attacks where an attacker acts on known, outdated price information before a new update is pulled. Contracts must implement logic to reject stale data based on timestamps.
02
Update Centralization & Censorship
The security model often relies on a permissioned set of relayers or a single entity to periodically submit the data update transaction. This creates a centralization vector:
- Relayers can be censored or fail.
- The update transaction competes in the public mempool, risking front-running or failure if gas prices spike.
- A malicious relayer could withhold updates to destabilize the system.
03
Front-Running & MEV
Because data updates are public transactions, they are vulnerable to Maximal Extractable Value (MEV) exploitation. Searchers can observe a pending data update (e.g., a new price) and front-run dependent user transactions. This can lead to unfair liquidations or arbitrage at the expense of regular users. Solutions like commit-reveal schemes or Flashbots-like privacy are complex to implement.
04
User-Funded Update Cost
In a pure pull model, the end user pays the gas cost to fetch the oracle data within their transaction. This creates economic inefficiency and unpredictability. Users may underfund transactions, causing them to revert, or be priced out during network congestion. This shifts operational risk and cost away from the oracle service and onto the user.
05
Data Authenticity & Source Trust
The security of the data hinges on the off-chain infrastructure and the honesty of the relayer. While cryptographic proofs (like TLSNotary or Trusted Execution Environments) can verify data came from a specific API, they cannot verify the correctness of the API's own data. The system is only as reliable as its primary data source and the integrity of the relayer's software stack.
technical-details-request-lifecycle
PULL ORACLES
Technical Deep Dive: Request Lifecycle
This section details the step-by-step process of a data request in a pull-based oracle system, where the on-chain smart contract initiates the data retrieval.
A pull oracle request lifecycle begins when an on-chain smart contract, such as a lending protocol checking a collateral price, requires external data. The contract emits a specific log event containing the data request parameters, which include the data source URL, the parsing path (e.g., a JSON path), and a unique request ID. This event is passive; it does not directly call an off-chain service. Instead, it acts as a broadcast, signaling that data is needed and is now available for any listening oracle node to fulfill.
Off-chain oracle nodes or decentralized networks like Chainlink continuously monitor the blockchain for these log events. Upon detecting a new request, a node retrieves the specified data from the designated API or external source. The node then performs critical off-chain computation: it validates the data's integrity, potentially aggregates responses from multiple sources to ensure accuracy, and converts the data into a blockchain-readable format. Finally, the node submits a signed transaction back to the requesting contract, delivering the verified data payload and completing the request.
The final phase involves on-chain verification and execution. The smart contract receives the transaction containing the oracle's response and cryptographically verifies the node's signature to authenticate the data's origin. Once verified, the contract decodes the data and executes its core logic based on the new information—for instance, processing a loan liquidation if a price falls below a threshold. This request-response model provides explicit, auditable data flows but introduces latency, as the contract must wait for an off-chain actor to voluntarily fulfill the request.
PULL ORACLES
Common Misconceptions
Pull oracles are a foundational data-fetching mechanism in Web3, but are often misunderstood in relation to their push-based counterparts. This section clarifies their operation, security model, and appropriate use cases.
A pull oracle is a decentralized data-fetching mechanism where data is retrieved on-demand by the end-user or smart contract, rather than being pushed automatically by the oracle network. The core workflow involves a smart contract storing a data request, which an off-chain relayer (or the user themselves) fulfills by fetching the data, paying the associated gas fees, and submitting the verified data point back on-chain to complete the transaction.
This model inverts the cost and responsibility structure of a push oracle. Key protocols utilizing this pattern include Chainlink Data Feeds (where users can call latestAnswer()), Pyth Network's pull updates, and MakerDAO's original oracle design where keepers pull price updates.
PULL ORACLE
Frequently Asked Questions
A pull oracle is a decentralized data feed where data is retrieved on-demand by the user's smart contract, rather than being pushed to the chain automatically. This section answers common questions about its mechanics, trade-offs, and use cases.
A pull oracle is a decentralized oracle design pattern where a smart contract explicitly requests and retrieves external data on-demand, rather than receiving automatic updates. The core mechanism involves a two-step process: first, the user's contract calls the oracle contract with a data request, and second, an off-chain oracle node listens for these requests, fetches the data from the API, and submits a transaction back to the blockchain with the result, which the requesting contract can then consume. This model inverts the typical push oracle flow, giving applications direct control over when and what data is fetched, which can significantly reduce gas costs for data that isn't needed constantly.
ENQUIRY
Get In Touch
today.
Our experts will offer a free quote and a 30min call to discuss your project.
NDA Protected
Confidentiality24h Response
Time to ValueDirectly to Engineering Team
No Sales Fluff10+
Protocols Shipped
$20M+
TVL Overall