Push oracles like Chainlink Data Feeds excel at providing low-latency, high-reliability data by proactively pushing updates to on-chain contracts. This model minimizes the time-sensitive MEV risk for protocols like Aave or Synthetix that require immediate price updates for liquidations, as validators cannot front-run a data point that is already confirmed. However, this proactive broadcasting creates a predictable transaction flow, which can be exploited in generalized MEV extraction strategies.
LABS
Comparisons
Push Oracles vs Pull Oracles: MEV Risk
A technical comparison of Push and Pull oracle models, focusing on MEV exposure, latency, cost, and security trade-offs for protocol architects and CTOs.
Chainscore © 2026
introduction
THE ANALYSIS
Introduction: The Oracle MEV Dilemma
Understanding the fundamental trade-offs between push and pull oracle architectures is critical for mitigating MEV risk in your protocol's data feeds.
Pull oracles such as Tellor or custom solutions take a different approach by requiring users or contracts to explicitly request data on-chain. This strategy eliminates the predictable broadcast vector, as data is only published when needed, making it harder for searchers to anticipate and front-run. The trade-off is higher latency and potential gas inefficiency for the requester, as seen in early implementations where each pull required a separate on-chain transaction.
The key trade-off: If your priority is sub-second finality and high-frequency data for DeFi primitives, choose a push oracle and manage risk via threshold encryption or commit-reveal schemes. If you prioritize MEV resistance and cost predictability for less time-sensitive data (e.g., insurance parameters, governance metrics), a pull oracle's on-demand model is superior. The decision hinges on whether your application's value is more sensitive to speed or to the cost and fairness of data inclusion.
tldr-summary
Push vs Pull Oracles: MEV Risk
TL;DR: Core Differentiators
The fundamental architectural choice between push and pull oracles dictates who bears the risk of MEV and front-running. This is a critical security and cost consideration for DeFi protocols.
01
Push Oracle: Predictable Latency
Proactive Data Delivery: The oracle (e.g., Chainlink, Pyth) pushes updates on a schedule or threshold. This creates a predictable transaction flow that is highly vulnerable to MEV extraction. Bots can sandwich the oracle's update transaction, front-running user positions. This matters for protocols like AMMs and lending markets where price updates trigger liquidations.
02
Push Oracle: Protocol Bears Cost
Subsidized Updates: The protocol or data provider pays the gas for on-chain updates. This simplifies user experience but centralizes MEV risk and cost on the protocol's treasury. For high-frequency data on L2s like Arbitrum or Optimism, this can become a significant operational expense and attack vector.
03
Pull Oracle: User-Triggered Updates
On-Demand Freshness: Data is fetched by the end-user's transaction (e.g., using Tellor, DIY zkOracle designs). This randomizes the update timing, making front-running attacks far more difficult and expensive for bots. This matters for low-latency, high-value applications like prediction markets or options protocols where MEV is a primary concern.
04
Pull Oracle: User Bears Cost & Complexity
Decentralized Execution: The user pays the gas to pull and verify the latest data. This shifts cost and composability burden to the user, requiring them to bundle the oracle call with their action. This is a trade-off for maximal security, best suited for sophisticated users or batch-processing systems like Gelato Network.
HEAD-TO-HEAD COMPARISON
Push Oracles vs Pull Oracles: MEV Risk Comparison
Direct comparison of MEV risk and operational characteristics between push and pull oracle models.
| Metric | Push Oracle (e.g., Chainlink) | Pull Oracle (e.g., Pyth, API3) |
|---|---|---|
MEV Risk Exposure | High | Low |
Update Latency | ~1-5 seconds | On-demand |
Gas Cost Payer | Oracle/Protocol | End User |
Data Freshness Guarantee | Periodic schedule | Per-request |
Primary Use Case | Continuous price feeds | Low-frequency settlements |
Front-running Vulnerability |
pros-cons-a
ARCHITECTURAL COMPARISON
Push Oracles vs Pull Oracles: MEV Risk
A data-driven breakdown of how push and pull oracle models differ in their exposure to and mitigation of Miner Extractable Value (MEV) risks.
01
Push Oracle MEV Risk
High exposure to frontrunning: In a push model (e.g., Chainlink's standard architecture), oracles broadcast price updates to all nodes simultaneously. This creates a public mempool transaction that can be frontrun by searchers. For example, a large price update for ETH/USD can be exploited in DeFi lending protocols before the update finalizes, leading to liquidations or arbitrage at the protocol's expense.
02
Push Oracle Mitigations
Relies on infrastructure hardening: Leading push oracles combat MEV with techniques like private mempool relays (e.g., Chainlink's Fair Sequencing Service) and commit-reveal schemes. These add latency and cost but reduce surface area. The trade-off is clear: enhanced security requires accepting higher operational complexity and gas costs per update, which is viable for high-value protocols like Aave or Compound.
03
Pull Oracle MEV Risk
Shifts risk to the dApp/user: In a pull model (e.g., Tellor, DIY Oracles), data is only fetched on-demand by the end user's transaction. This eliminates broadcast frontrunning but introduces request-based MEV. A malicious actor can see a pending data request and race to fulfill it with a manipulated value if the reward is insufficient, potentially compromising the specific transaction.
04
Pull Oracle Mitigations
Incentive-based security: Pull systems mitigate MEV by making attacks economically irrational. This requires robust cryptoeconomic design with high staking bonds (e.g., Tellor's dispute mechanism) and careful reward calibration. The model excels for low-frequency, high-value data points where the cost of securing a pull request is justified, but struggles with high-frequency price feeds due to latency and gas overhead for users.
pros-cons-b
ARCHITECTURAL COMPARISON
Push Oracles vs Pull Oracles: MEV Risk
A technical breakdown of how push and pull oracle models expose protocols to different MEV vectors. The choice impacts security, cost, and latency.
01
Push Oracle MEV Risk
Higher exposure to frontrunning: Updates are broadcast transactions visible in the public mempool. This allows searchers to front-run price updates for assets like ETH/USD on Uniswap V3, extracting value before the new data is confirmed. Centralized update timing: Scheduled updates create predictable, high-value targets for sandwich attacks and arbitrage bots, especially during volatile market events.
02
Push Oracle Mitigations
Commit-Reveal Schemes: Oracles like Chainlink use threshold signatures off-chain, broadcasting only a final aggregated value. This hides the update data from the mempool. Sub-second Finality: Deploying on high-throughput L2s like Arbitrum or Solana reduces the viable time window for MEV extraction by confirming updates faster.
03
Pull Oracle MEV Risk
Lower inherent exposure: Data is fetched on-demand by the end-user's transaction. There is no broadcast oracle update to front-run. The primary risk shifts to the user's transaction itself. User transaction MEV: While the oracle call is safe, the surrounding swap or liquidation logic in the user's tx (e.g., on Aave) can still be exploited via generalized frontrunning.
04
Pull Oracle Trade-offs
Latency & Cost Burden: Each user pays the gas for the data fetch (e.g., a Chainlink latestAnswer call), adding ~50k-100k gas per transaction. This creates a poor UX for high-frequency actions.
Stale Data Risk: If not fetched regularly, protocols like a lending market can operate on outdated prices until a user triggers an update, creating liquidation inefficiencies.
PUSH VS PULL ORACLES
Technical Deep Dive: MEV Attack Vectors
Maximal Extractable Value (MEV) presents distinct risks to oracle designs. This analysis compares the inherent MEV vulnerabilities and mitigation strategies of push-based and pull-based oracle architectures.
Pull oracles are fundamentally more vulnerable to front-running. In a pull model, the price update transaction is publicly broadcast, creating a visible opportunity for searchers to sandwich the update. Push oracles, where updates are submitted by permissioned nodes, obscure the transaction path, making targeted front-running more difficult. However, push oracles can still be vulnerable to generalized front-running if update timing is predictable.
CHOOSE YOUR PRIORITY
When to Choose Which Model
Push Oracles for DeFi
Verdict: Default choice for critical, high-value operations. Strengths: Push oracles like Chainlink provide proactive, low-latency price updates, which are essential for liquidations and stablecoin pegs. This minimizes the window for stale price attacks. The broadcast model is battle-tested with over $8B in TVL secured. MEV Risk Profile: Lower. The update is pushed to all nodes simultaneously, reducing the opportunity for generalized frontrunning based on the data itself. The primary MEV risk shifts to the latency of the oracle's update transaction.
Pull Oracles for DeFi
Verdict: Strategic choice for cost-sensitive, non-time-critical functions. Strengths: Pull oracles (e.g., Pyth Network's pull model, custom MakerDAO feeds) allow protocols to pay only for the data they consume. This is ideal for governance parameters, yield rate updates, or insurance payouts where a 1-2 block delay is acceptable. MEV Risk Profile: Higher and more complex. The act of pulling data creates a clear, on-chain transaction that can be frontrun. This can lead to priority gas auctions (PGAs) and time-bandit attacks where validators reorg the chain to capture the value of the new data.
verdict
THE ANALYSIS
Final Verdict and Decision Framework
Choosing between push and pull oracles requires balancing MEV risk against operational complexity and cost.
Push oracles (e.g., Chainlink, Pyth) excel at providing low-latency, guaranteed data delivery because they proactively push updates on-chain. This proactive model minimizes the risk of stale data for critical DeFi protocols like Aave or Compound, where a delayed price feed can trigger liquidations. However, this creates a predictable transaction pattern, making oracle updates a prime target for sandwich attacks and front-running, with MEV bots extracting value from the latency between the oracle update and user transactions.
Pull oracles (e.g., Tellor, DIY solutions using Chainlink's checkData or requestData) take a different approach by requiring users or contracts to explicitly request data on-demand. This results in unpredictable transaction timing, drastically reducing the surface for predictable MEV extraction. The trade-off is increased gas cost and complexity shifted to the dApp, which must now manage the request-response lifecycle and handle potential request failures or delays, impacting user experience.
The key trade-off is between security and convenience. If your priority is maximizing MEV resistance for a protocol where users can tolerate slightly higher gas costs or latency (e.g., insurance protocols, governance), choose a pull oracle. If you prioritize guaranteed, low-latency data for high-frequency applications where user experience is paramount (e.g., perpetual DEXs, lending markets), a push oracle is preferable, but you must architect with MEV in mind using techniques like commit-reveal schemes or threshold signatures.
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