Pyth Pull Feeds excel at minimizing on-chain MEV exposure by requiring users to fetch price updates on-demand. This model, used by protocols like Solana's Jupiter and Avalanche's GMX, keeps price data off-chain until needed, drastically reducing the attack surface for front-running and sandwich attacks. The trade-off is that dApp logic must manage the gas cost and latency of the pull transaction, adding complexity for developers.
LABS
Comparisons
Pyth Pull vs Push Feeds: MEV Risk
A technical comparison of Pyth Network's push and pull oracle models, analyzing their inherent MEV exposure, latency profiles, gas costs, and security trade-offs for protocol architects and CTOs.
Chainscore © 2026
introduction
THE ANALYSIS
Introduction: The Oracle MEV Dilemma
A technical breakdown of how Pyth's pull and push feed models present distinct trade-offs for MEV risk and operational overhead.
Pyth Push Feeds take a different approach by having publishers (e.g., Jane Street, Cboe) continuously push signed price updates to an on-chain store. This results in sub-second latency and simpler integration for protocols like Synthetix Perps, as the latest price is always available. However, this creates a predictable, recurring on-chain transaction stream, which is a prime target for MEV bots seeking to exploit the price update for arbitrage, increasing the cost of oracle freshness.
The key trade-off: If your priority is MEV resistance and gas cost predictability for users, choose Pull Feeds. This is ideal for high-frequency retail actions like swaps. If you prioritize ultra-low latency and simplified contract logic for high-value institutional transactions, choose Push Feeds, accepting the associated MEV tax as a cost of performance. Your protocol's value-at-risk per transaction should guide this decision.
tldr-summary
PULL VS PUSH: MEV RISK ANALYSIS
TL;DR: Core Differentiators
The fundamental architectural choice between pull and push oracles defines your protocol's exposure to MEV. Here are the key trade-offs for security and cost.
01
Pull Feeds: MEV Resistance
On-demand price updates: Protocols pull the latest price only when needed for a transaction, making the update atomic with the user action. This eliminates the front-running window between a price update and its use, protecting users from sandwich attacks. This matters for perpetual DEXs and lending protocols where large, predictable updates are prime MEV targets.
0s
Update-Use Latency
02
Pull Feeds: Cost Predictability
Pay-per-use gas model: The protocol (or user) pays gas only for price updates that are actually consumed. This creates predictable, sunk costs tied to user volume, avoiding wasted gas on unused push updates. This matters for gas-sensitive L2s and protocols with volatile or seasonal activity where maintaining constant updates is inefficient.
03
Push Feeds: Latency & Simplicity
Pre-emptive price updates: Oracles continuously push updates on-chain, guaranteeing the latest price is always in the contract's storage. This eliminates any on-chain pull latency, providing sub-second freshness for the next user. This matters for high-frequency trading venues and money markets where even millisecond delays in fetching a price can lead to arbitrage losses.
< 1s
Price Freshness
04
Push Feeds: MEV Exposure
Predictable update cycles: Regular price updates create known time-based opportunities for searchers. The gap between a pushed update and its consumption by the next user transaction can be exploited via front-running. This matters for protocols with high TVL and liquid markets, as they become persistent targets for automated MEV bots monitoring the oracle's update transaction.
HEAD-TO-HEAD COMPARISON
Pyth Pull vs Push Feeds: MEV Risk Comparison
Direct comparison of MEV risk, update mechanisms, and operational characteristics for oracle feed models.
| Metric | Pyth Pull Feeds | Pyth Push Feeds |
|---|---|---|
Primary MEV Risk Vector | Front-running price updates | Back-running price updates |
Update Latency (Publisher to On-Chain) | User-determined (0-400ms) | Publisher-determined (~400ms) |
On-Chain Update Cost Payer | End User / Application | Publisher / Pyth Network |
Gas Cost per Update (Solana, Approx.) | ~0.001 SOL | ~0.001 SOL |
Data Freshness Guarantee | User-controlled | Publisher SLA |
Typical Update Frequency | On-demand per user tx | ~400ms per price feed |
Best For | Low-latency, user-paid dApps | High-frequency, protocol-subsidized dApps |
pros-cons-a
MEV Risk Analysis
Pyth Push Feeds: Pros and Cons
Evaluating the trade-offs between Pyth's Pull and Push oracle models for high-value DeFi protocols concerned with MEV and latency.
01
Push Feed: Pro - MEV Resistance
On-demand price updates: Updates are triggered by user transactions, not by scheduled pushes. This makes front-running price updates extremely difficult, as the timing is unpredictable. This matters for protocols like perpetual DEXs (e.g., Hyperliquid) where predictable oracle updates create clear MEV opportunities for searchers.
02
Push Feed: Con - Higher Gas Cost for Users
Gas burden shifted to end-users: Each price update requires an on-chain transaction paid by the protocol user, adding ~100k-200k gas per update. This matters for high-frequency applications or those with many small trades, as it directly increases transaction costs and degrades user experience compared to subsidized push models.
03
Pull Feed: Pro - Predictable, Subsidized Updates
Protocol-managed update costs: The protocol or keeper bots pay for regular price updates (e.g., every 400ms on Solana). This provides sub-second latency at no direct cost to the end-user. This matters for order-book DEXs (e.g., Drift Protocol) requiring continuous, low-latency feeds without taxing traders.
04
Pull Feed: Con - Predictable MEV Vector
Scheduled update windows create arbitrage: Known update intervals (like Pyth's Solana price_validity_period) allow searchers to algorithmically front-run large price movements. This matters for protocols with high TVL in lending markets (e.g., Solend, Marginfi) where predictable liquidations can be exploited, potentially harming users.
pros-cons-b
PULL VS. PUSH FEEDS: MEV RISK ANALYSIS
Pyth Pull Oracle: Pros and Cons
A technical breakdown of Pyth's pull-based oracle model versus traditional push oracles, focusing on MEV exposure, latency, and operational trade-offs.
01
Pro: Reduced On-Chain MEV Exposure
Pull model shifts risk to the user: Price updates are only published when a user's transaction explicitly pulls them on-chain. This eliminates the risk of front-running or sandwich attacks against the oracle's own update transactions, a common vector for push oracles like Chainlink. This matters for protocols where oracle update predictability is a security liability.
02
Pro: Cost Efficiency for Low-Activity Assets
Pay-per-update economics: Protocols only pay gas for price updates when they are needed for a user transaction, rather than funding continuous push updates. This is optimal for long-tail assets or low-volume markets where frequent updates are unnecessary. Compare this to push models that incur costs for every block, regardless of usage.
03
Con: Introduces User-Facing MEV & Latency
MEV risk transfers to end-users: The pull transaction itself (which includes the price data) can be front-run. Users must also bear the gas cost and latency of the on-chain pull. This creates a poor UX for time-sensitive trades and adds complexity, unlike push feeds where data is passively available.
04
Con: Protocol Design Complexity & Liveness Assumptions
Reliance on user-driven liveness: Protocols must ensure users or keepers are incentivized to pull prices. This adds systemic complexity versus the simpler, automated guarantee of a push feed. In low-liquidity scenarios, stale data risk increases if no one pulls an update.
PYTH PULL VS PUSH FEEDS
Technical Deep Dive: MEV Mechanics
A critical analysis of how Pyth's Pull and Push oracle models differ in their exposure to Maximal Extractable Value (MEV), a key consideration for DeFi protocol architects and risk managers.
The Pull model is inherently more vulnerable to MEV than the Push model. In a Pull system, price updates are triggered by user transactions, creating a predictable race condition that searchers can exploit. Push models, like Chainlink, broadcast updates on a schedule, making the update event itself less predictable and harder to front-run. This makes Pull oracles a higher-risk choice for high-value, latency-sensitive DeFi applications like perpetual futures or lending liquidations.
CHOOSE YOUR PRIORITY
When to Use Which Model
Pyth Pull for DeFi
Verdict: The Standard for High-Value, MEV-Sensitive Applications. Strengths: Pull oracles give your protocol explicit control over price update timing, allowing you to batch updates and shield users from front-running. This is critical for perps on dYdX, Synthetix, or MarginFi, where a single manipulated price can trigger cascading liquidations. Use Pull to integrate with MEV-protected sequencers (like Espresso, Shutter) for maximal security.
Pyth Push for DeFi
Verdict: Ideal for Simpler, High-Frequency Applications. Strengths: Lower gas overhead and simpler integration make Push feeds suitable for AMMs (e.g., Uniswap V4 hooks), lending markets with frequent oracle updates, or yield aggregators where sub-second latency is more critical than absolute MEV resistance. The passive update model reduces your smart contract complexity.
verdict
THE ANALYSIS
Final Verdict and Decision Framework
Choosing between Pyth's pull and push oracle models hinges on your application's tolerance for latency, cost, and MEV exposure.
Pyth Pull Feeds excel at minimizing on-chain MEV risk by design. The data is only published when a user's transaction explicitly requests it via a permissionless PythNetwork contract call, creating a verifiable on-chain proof of the price at that exact moment. This atomic pull mechanism eliminates the risk of front-running or sandwich attacks on the price update itself, as there is no public pending transaction to exploit. For protocols like perpetual DEXs or lending markets where price staleness can be catastrophic, this deterministic security is paramount.
Pyth Push Feeds take a different approach by having designated publishers submit price updates at regular intervals (e.g., ~400ms). This results in consistently fresh data being available in a low-latency cache (PythERC7412), reducing the gas cost and latency for end-users. The trade-off is the introduction of a predictable update cadence, which, while still fast, creates a window where the update transaction itself could theoretically be targeted by MEV bots if the fee market is highly competitive, though Pyth's high update frequency mitigates the value of this attack.
The key trade-off: If your priority is maximizing security and MEV resistance for high-value settlements, choose Pull Feeds. They are ideal for low-frequency, high-stakes operations like liquidations or derivatives settlement on chains like Ethereum Mainnet. If you prioritize ultra-low latency and cost for high-frequency interactions, choose Push Feeds. They are better suited for perp DEXs on Solana or Arbitrum, where sub-second updates and minimal user-paid gas are critical, and the economic value of front-running a single update is diluted by the rapid update cycle.
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