Push oracles (like Chainlink Data Feeds) excel at proactive security and liveness because they continuously push verified data on-chain. This model ensures data is always available for smart contracts to consume, preventing transaction failures due to missing inputs. For example, Chainlink's decentralized networks maintain >99.9% uptime, securing over $80B in TVL by preemptively delivering price data for DeFi protocols like Aave and Synthetix. This architecture shifts the gas cost and reliability burden onto the oracle network, simplifying dApp development.
LABS
Comparisons
Push Oracles vs Pull Oracles: Security
A technical analysis of the core security assumptions, attack vectors, and risk trade-offs between push-based and pull-based oracle architectures for CTOs and protocol architects.
Chainscore © 2026
introduction
THE ANALYSIS
Introduction: The Oracle Security Dilemma
The choice between push and pull oracles fundamentally shapes your protocol's security posture, forcing a trade-off between proactive protection and operational control.
Pull oracles (like Tellor or a custom solution) take a different approach by having applications request data on-demand. This results in a critical trade-off: it grants developers fine-grained control over data freshness and gas costs per query but introduces the risk of stale data if pulls are infrequent. The security model is reactive; applications must implement their own validation and fallback logic. This can be advantageous for low-frequency, custom data feeds where cost optimization is paramount, but it places the operational onus squarely on the consuming contract.
The key trade-off: If your priority is maximized uptime and hands-off security for high-frequency data (e.g., perpetual DEX prices, lending liquidations), choose a push oracle. If you prioritize absolute cost control and flexibility for low-frequency or bespoke data requests, a pull oracle architecture may be preferable, provided you have the engineering resources to manage its liveness risks.
tldr-summary
PUSH VS PULL ORACLES
TL;DR: Core Security Trade-Offs
The fundamental architectural choice between proactive data delivery and on-demand fetching defines your security surface and operational model.
01
Push Oracle Security Pros
Proactive, Guaranteed Delivery: Data is pushed on-chain by the oracle network when conditions are met (e.g., price deviation). This eliminates the risk of a user's pull transaction failing or being front-run due to stale data. This matters for high-frequency DeFi protocols like perpetual swaps (GMX, Synthetix) where liveness is critical.
~1-3s
Typical Update Latency
02
Push Oracle Security Cons
Centralized Liveness Risk & Spam Cost: Relies on a designated relayer (often the oracle node) to pay gas for every update. If the relayer fails, the data stream halts. This creates a single point of failure and can lead to expensive, unnecessary on-chain spam during low volatility. This matters for cost-sensitive or decentralized-first applications where you cannot trust a single actor's uptime.
03
Pull Oracle Security Pros
User-Controlled, Cost-Efficient Execution: Data is fetched on-demand by the end-user's transaction. This decentralizes liveness, as any user can trigger an update, and eliminates gas waste for unused data. This matters for less time-sensitive applications like insurance (Nexus Mutual), governance, or NFT valuations, where updates are event-driven.
User-Paid
Gas Model
04
Pull Oracle Security Cons
Front-Running & Staleness Vulnerabilities: The time between a user signing a pull transaction and its inclusion creates a window for MEV extraction. Adversaries can see the pending update and front-run with advantageous trades. Stale data can also cause failed transactions if the on-chain cache expires. This matters for any protocol where price impact is significant, as it exposes users to predictable exploitation.
ARCHITECTURAL SECURITY COMPARISON
Security Feature Matrix: Push vs Pull
Direct comparison of security properties and risk profiles for oracle data delivery models.
| Security Metric | Push Oracle Model | Pull Oracle Model |
|---|---|---|
User-Initiated Data Request | ||
Relayer Front-Running Risk | High | Low |
On-Chain Data Freshness | ~1-5 min | < 1 sec |
Protocol Gas Liability | Oracle pays | User pays |
Data Availability Guarantee | ||
MEV Attack Surface | Large | Minimal |
Primary Failure Mode | Oracle downtime | User request failure |
pros-cons-a
ARCHITECTURAL SECURITY TRADE-OFFS
Push Oracle Security: Pros and Cons
A direct comparison of the core security models for on-chain data delivery. Push oracles (e.g., Chainlink Data Streams, Pyth Network) proactively broadcast data, while pull oracles (e.g., Chainlink Data Feeds, Tellor) require contracts to request it. The choice impacts liveness, cost, and attack surface.
01
Push Oracle: Proactive Liveness
Guaranteed Data Delivery: Updates are pushed on-chain automatically when conditions (e.g., price deviation) are met. This eliminates the risk of a smart contract stalling because it failed to request data. Critical for perpetual DEXs like dYdX and high-frequency options protocols where missed updates equal insolvency.
< 1 sec
Update Latency
02
Push Oracle: Centralized Failure Point
Relayer Dependency: The system relies on a designated off-chain relayer to sign and broadcast updates. If this component fails or is compromised, the data flow stops entirely. This creates a single point of failure not present in decentralized pull models. Mitigations like keeper networks exist but add complexity.
03
Pull Oracle: Decentralized Execution
User-Triggered Security: Data is only fetched on-demand by the end-user's transaction. The oracle network (e.g., Chainlink's decentralized node operators) attests to data, but the request and payment are initiated by the protocol user. This aligns incentives and removes any centralized broadcast mechanism, as seen in AAVE's price feed queries.
04
Pull Oracle: Liveness & Front-Running Risk
Update Gaps & MEV: Data can become stale between requests, requiring protocols to implement heartbeat functions or risk operating on outdated info. Furthermore, the public request transaction can be front-run, allowing attackers to exploit the time between a price request and its fulfillment in arbitrage scenarios.
~12 sec
Typical Update Cycle
pros-cons-b
ARCHITECTURAL COMPARISON
Push Oracles vs Pull Oracles: Security
A data-driven breakdown of security trade-offs between proactive (Push) and on-demand (Pull) oracle models for CTOs and protocol architects.
02
Push Oracle: Centralized Risk
Single Point of Failure: The update mechanism is controlled by the oracle network. If the network halts updates (e.g., due to governance attack or critical bug), all dependent dApps are exposed. This matters for mission-critical, always-on systems where oracle downtime equals protocol failure.
03
Pull Oracle: On-Demand Security
User-Controlled Updates: Data is fetched only when an end-user transaction requires it (e.g., Tellor or DIY oracle contracts). This eliminates wasteful gas for unused data and shifts the trust assumption to the transaction initiator. This matters for low-frequency, user-initiated actions like insurance claims or custom derivatives.
04
Pull Oracle: Latency & Front-Running Risk
Exposed Request-Response Cycle: The time between data request and on-chain delivery creates a vulnerability window. Adversaries can front-run the settlement transaction. Protocols like UMA mitigate this with dispute delays, but it adds complexity. This matters for high-value settlements where MEV extraction is a primary concern.
PUSH VS. PULL
Technical Deep Dive: Attack Vectors and Mitigations
While both oracle models aim to deliver reliable data on-chain, their fundamental architectures expose them to distinct security risks. This section analyzes the primary attack vectors for push and pull oracles and the specific mitigation strategies employed by leading protocols like Chainlink, Pyth Network, and API3.
Pull oracles are inherently more vulnerable to front-running attacks. In a pull model, a user's request for data is a public transaction visible in the mempool. This allows malicious actors to observe the request, fetch the data themselves, and submit their own transaction with the correct data and a higher gas fee to claim the reward, effectively stealing it from the original requester. Push oracles like Chainlink's Data Feeds eliminate this vector by having nodes push updates to a decentralized contract at regular intervals, independent of user requests, making the data available for anyone to use without a race condition.
CHOOSE YOUR PRIORITY
Security Recommendations by Use Case
Push Oracles for DeFi
Verdict: The standard for high-value, latency-sensitive applications. Strengths:
- Proactive Security: Data is pushed on-chain by the oracle network (e.g., Chainlink, Pyth), ensuring immediate availability for critical functions like liquidations on Aave or price checks on Uniswap v3.
- Censorship Resistance: Decentralized networks like Chainlink prevent a single node from withholding price updates, a vital property for multi-billion dollar TVL protocols.
- Battle-Tested: Billions in value secured across thousands of mainnet contracts.
Pull Oracles for DeFi
Verdict: A cost-effective niche solution for non-critical, user-initiated data. Strengths:
- Cost Control: Users or contracts pay gas only when data is explicitly requested (pull). This can be ideal for low-frequency operations like fetching a one-off NFT floor price via an API from The Graph.
- No Oracle Risk When Idle: The protocol isn't exposed to oracle failure or manipulation between updates. Key Risk: Unsuitable for any function requiring guaranteed, timely data (e.g., lending health checks, perpetual futures). A malicious actor could front-run or censor a pull request.
verdict
THE ANALYSIS
Verdict and Decision Framework
A final breakdown of the security trade-offs between push and pull oracle architectures to guide your infrastructure decision.
Push Oracles excel at guaranteed, low-latency data delivery because the oracle node actively pushes updates to on-chain contracts. This proactive model minimizes the window for stale data attacks, as seen in protocols like Chainlink's Data Feeds which maintain >99.9% uptime for price feeds. The security model centralizes risk on the oracle node, which must be highly reliable and economically bonded, but it ensures smart contracts always have the freshest data without manual triggers.
Pull Oracles take a different approach by having the dApp contract request data on-demand. This results in a trade-off of user latency for reduced protocol risk and cost. The security burden shifts to the end-user or a relayer, who must pay the gas fee for the pull transaction. This architecture, used by Pyth Network's pull oracle, eliminates idle gas expenditure for unused updates and can offer higher data granularity, but introduces a reliance on user-initiated actions for security.
The key trade-off is between proactive security and reactive cost-efficiency. If your priority is maximizing uptime and ensuring automatic execution for critical DeFi functions like liquidations or perpetuals, choose a Push Oracle. If you prioritize minimizing protocol-level gas overhead and are comfortable with user-initiated data pulls for less time-sensitive applications like historical data analysis or batch settlements, a Pull Oracle is more suitable. Your choice fundamentally dictates where the security and cost responsibilities lie in your stack.
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