Pull Oracle

A pull oracle operates on a request-response model. The smart contract (the consumer) explicitly calls a function to fetch data, which triggers an off-chain process. This is in contrast to push oracles, which broadcast data continuously. Key steps include:

• Contract emits an event with a data request.
• Off-chain oracle node or relayer listens for the event.
• Node fetches data from the specified API or source.
• Node submits the data back to the contract in a subsequent transaction.

In a pull model, the end-user or the requesting contract pays the gas fees for the final callback transaction that delivers the data. This makes cost accounting transparent and predictable for the dApp. The oracle service typically only pays for the initial event emission. This contrasts with push models, where the oracle provider must continually pay to update data on-chain.

Pull architectures can improve security by decentralizing the data delivery step. Anyone can act as a relayer by monitoring for data requests and competing to submit the response. This creates a permissionless network for data delivery, reducing reliance on a single trusted node. Protocols like Chainlink implement this with decentralized oracle networks (DONs) where multiple nodes respond, and the contract aggregates the results.

The application has direct control over when data is fetched. The contract requests new data at the precise moment it's needed for logic execution (e.g., finalizing a trade or settling a loan). This eliminates stale data issues that can occur if a push oracle fails to update. The trade-off is higher latency, as the data is not pre-loaded on-chain.

For oracle node operators, the pull model is more efficient. Nodes do not need to maintain constant on-chain transactions for all supported data feeds. They only perform work and incur costs when there is a specific, paid request. This allows oracle networks to support a wider array of data feeds without prohibitive gas costs.

A simple pull oracle pattern uses the user as the relayer. For example, in a DEX requiring a price check:

1. User initiates a swap, calling requestSwap().
2. Contract returns an unsigned transaction with the needed price data field empty.
3. User fetches the price off-chain (e.g., from an API).
4. User signs and submits the completed transaction with the price data.
5. Contract verifies the price is valid (e.g., within a time window) before executing. This pattern is used by protocols like Uniswap v3 for its oracle observations.

The core risk is stale data. If a user's transaction to pull data is not executed promptly, the smart contract may act on outdated information. Attackers can exploit this by:

• Front-running the data pull transaction to manipulate market conditions before the update.
• Delaying execution through network congestion or targeted spam.
• Causing liquidation or settlement based on incorrect, old prices.

Security shifts from the oracle provider to the end-user or a designated relayer. This creates risks:

• Unpaid gas costs: If a user fails to call the update function, the protocol state becomes stale, potentially leading to insolvency.
• Relayer centralization: Protocols often rely on a single bot or keeper network to pull data, creating a single point of failure. If the relayer goes offline, the system halts.

The mechanism that triggers the data pull is a critical attack surface. Considerations include:

• Permissionless vs. Permissioned Triggers: Who can call the update function? Permissionless is more decentralized but open to spam.
• Timelocks & Incentives: Implementing time-based or deviation-based triggers can reduce spam but add complexity.
• Oracle Extractable Value (OEV): The value of being the first to trigger an update with new data, which can be captured by searchers and validators, potentially distorting incentives.

Even with a pull model, the source and verification of data remain paramount.

• Source Centralization: If the oracle pulls from a single API endpoint, that endpoint becomes a centralized point of failure subject to manipulation or downtime.
• On-Chain Verification: How does the contract verify the fetched data is correct? Pure pull oracles may lack cryptographic proofs (like zero-knowledge proofs or TLSNotary), relying instead on trust in the reporter's signed message.

Contrasting with Push Oracles (like Chainlink Data Feeds) highlights the trade-offs:

• Push Oracle Risk: Centralized around the oracle node network (e.g., node collusion, sybil attacks). The protocol pays for continuous updates.
• Pull Oracle Risk: Centralized around update liveness and relayer incentives. The user/relayer pays for updates.
• Hybrid models (e.g., push with pull fallback) are emerging to balance freshness guarantees with cost efficiency.

Protocols can mitigate pull oracle risks through careful design:

• Incentivized Relay Networks: Use keeper networks with slashing for liveness failures.
• Fallback Mechanisms: Implement circuit breakers or grace periods when data is stale.
• Decentralized Data Sources: Pull from multiple, independent sources and aggregate results on-chain.
• Explicit Staleness Tolerance: Design contracts to function safely within a known time-to-freshness window.

A data oracle that proactively pushes updated data to smart contracts on-chain, typically via a transaction initiated by the oracle node. This model contrasts with a pull oracle, where the contract must request the data.

• Key Difference: Push oracles handle gas costs and timing, while pull oracles shift this responsibility to the contract.
• Use Case: Ideal for contracts requiring frequent, automated updates, like price feeds for lending protocols.
• Trade-off: Can incur higher operational costs for the oracle service.

The off-chain server or software client operated by a data provider that fetches, verifies, and signs external data for delivery to the blockchain. It is the fundamental execution unit in both push and pull oracle systems.

• Function: Connects to APIs, runs consensus algorithms (if decentralized), and creates cryptographically signed data attestations.
• In Pull Oracles: The node remains idle until it receives an on-chain request, then submits the data in a new transaction.

A continuous stream of specific, validated data points (e.g., ETH/USD price) provided by an oracle network. Pull oracles often serve as the underlying mechanism for updating these feeds on-demand.

• Composition: Aggregates data from multiple nodes to ensure accuracy and decentralization.
• On-Chain State: The latest value is stored in a contract, which applications can pull from directly or via a pull oracle request for a fresh update.

An oracle that provides data along with a zero-knowledge proof attesting to its correctness and the integrity of the source computation. This enhances privacy and security for pull-style requests.

• Mechanism: Generates a ZK-SNARK or STARK proof that the data was fetched and processed according to predefined rules, without revealing the raw source data.
• Advantage: Enables trust-minimized data feeds for sensitive or proprietary inputs in DeFi and identity applications.

The specific communication pattern where a consumer (smart contract) sends a request for data and a provider (oracle) returns a response. This is the foundational protocol for pull oracles.

• Steps: 1) Contract emits a log with a query. 2) Off-chain listeners (oracle nodes) detect it. 3) Nodes fetch data and submit a transaction with the result to the contract.
• Flexibility: Allows for highly customizable, one-off data queries beyond standardized feeds.