Public Feeds excel at providing low-cost, high-frequency data for non-critical applications because they broadcast aggregated price updates to all users simultaneously. For example, Chainlink Data Feeds update every block on networks like Arbitrum, offering sub-second latency for a predictable gas cost. This model minimizes per-user oracle costs but creates a predictable, broadcast data event that sophisticated bots can front-run.
LABS
Comparisons
Public Feeds vs Per-Tx Oracles: MEV
A technical comparison for CTOs and protocol architects on MEV exposure, latency, and cost trade-offs between broadcast public data feeds and on-demand per-transaction oracle models.
Chainscore © 2026
introduction
THE ANALYSIS
Introduction: The MEV-Oracle Nexus
How oracle design fundamentally shapes your protocol's exposure to MEV and data integrity.
Per-Tx Oracles like Pyth Network's Pull Oracle take a different approach by delivering a unique price attestation directly to the user's transaction. This strategy results in a trade-off: higher per-transaction cost and complexity for the user, but it eliminates the public data broadcast that creates predictable MEV opportunities. The attestation is only revealed upon transaction inclusion, making front-running the oracle update itself nearly impossible.
The key trade-off: If your priority is minimizing user transaction cost and latency for high-frequency actions (e.g., a decentralized perpetuals exchange), a Public Feed is optimal. If you prioritize maximizing fairness and MEV resistance for high-value, low-frequency settlements (e.g., an options expiry or large OTC trade), a Per-Tx Oracle is the superior choice. Your selection dictates your protocol's risk profile.
tldr-summary
Public Feeds vs Per-Tx Oracles
TL;DR: Core Differentiators
Key architectural trade-offs for MEV-sensitive applications at a glance.
01
Public Feeds (e.g., Pyth, Chainlink Data Streams)
Pro: Lower Latency & Cost for High-Volume Apps
- Data is broadcast to a public mempool, allowing any user to submit a transaction referencing the latest price. This eliminates per-transaction oracle fees for the protocol.
- Ideal for high-frequency DeFi primitives like perpetual DEXs (e.g., Hyperliquid, Drift Protocol) where thousands of liquidations/trades need low-cost price checks.
02
Public Feeds (e.g., Pyth, Chainlink Data Streams)
Con: Susceptible to Frontrunning & MEV Extraction
- Since price updates are public, searchers can frontrun transactions that depend on new data (e.g., liquidations, limit orders).
- Creates predictable oracle extractable value (OEV). Protocols like UMA's oSnap and Astria's shared sequencer aim to recapture this value.
03
Per-Tx Oracles (e.g., API3 dAPIs, Chronicle)
Pro: MEV-Resistant & Deterministic Execution
- Oracle data is delivered directly into the transaction, making the update and its dependent logic atomic and private until inclusion.
- Critical for applications where execution certainty is paramount, such as on-chain options settlements (e.g., Lyra) or RWA loan disbursements.
04
Per-Tx Oracles (e.g., API3 dAPIs, Chronicle)
Con: Higher Cost & Protocol-Ledger Bloat
- Each data point requires a separate on-chain transaction and fee, paid by the protocol or user.
- Can become prohibitively expensive for applications requiring frequent updates (e.g., second-price auctions). Suited for lower-frequency, high-value events.
MEV RESISTANCE & DATA DELIVERY
Head-to-Head Feature Matrix: Public Feeds vs Per-Tx Oracles
Direct comparison of oracle data delivery models for MEV-sensitive applications.
| Metric | Public Feeds (e.g., Chainlink Data Streams) | Per-Tx Oracles (e.g., Pyth, API3 dAPIs) |
|---|---|---|
Data Latency (Update Frequency) | ~400ms - 1s | ~100ms (on-demand) |
MEV Exposure for Users | Low (pre-committed, frequent updates) | High (request reveals intent) |
Gas Cost Model | Amortized across all users | Paid per transaction by requester |
Data Freshness Guarantee | SLA-based periodic updates | Real-time on demand |
Primary Use Case | Lending rates, perpetuals, stablecoins | High-frequency trading, options, prediction markets |
Example Protocols | Aave, Synthetix, GMX | Drift, Hyperliquid, Vertex |
pros-cons-a
ARCHITECTURAL COMPARISON
Public Feeds vs Per-Tx Oracles: MEV
Key strengths and trade-offs for MEV-sensitive applications at a glance. The choice impacts cost, latency, and censorship resistance.
01
Public Feeds (e.g., Pyth, Chainlink Data Streams)
Pro: Predictable, Low-Cost Access
- Cost: Fixed subscription or gas-free pull model (e.g., Pyth's pull oracle). No per-update fee for the end user.
- Latency: Updates are broadcast to a public mempool. This matters for high-frequency strategies where watching the mempool is cheaper than initiating transactions.
- Example: A DEX aggregator can monitor the Pyth price feed on Solana for near-zero cost to trigger arbitrage.
02
Public Feeds (e.g., Pyth, Chainlink Data Streams)
Con: Susceptible to Frontrunning & Latency Arbitrage
- MEV Risk: Updates are public. Bots can frontrun transactions that depend on a new price before it's confirmed on-chain.
- Example: A lending protocol's liquidation trigger based on a public feed update can be sniped, capturing the liquidation fee.
- Impact: This creates a latency race, benefiting sophisticated searchers with the fastest infrastructure.
03
Per-Transaction Oracles (e.g., Chainlink Functions, API3 dAPIs)
Pro: MEV-Resistant Execution
- Process: Data fetch is initiated and fulfilled within the same transaction, creating a atomic update.
- Security: No public broadcast phase for searchers to exploit. This matters for sensitive triggers like insurance payouts or conditional transfers where frontrunning is unacceptable.
- Example: A parametric flight insurance policy pays out only if a verifiable API confirms a delay, all in one tx.
04
Per-Transaction Oracles (e.g., Chainlink Functions, API3 dAPIs)
Con: Higher Cost & Execution Complexity
- Cost: Pay for full oracle network computation and gas on every request. Not viable for millisecond-level updates.
- Latency: Subject to blockchain confirmation times plus external API latency.
- Trade-off: You pay a premium for atomicity. This matters for low-frequency, high-value operations where cost is secondary to correctness.
pros-cons-b
MEV Resistance & Cost Trade-offs
Per-Tx Oracles: Pros and Cons
Comparing the MEV and economic profiles of public feed oracles (e.g., Chainlink Data Feeds) versus per-transaction oracles (e.g., Pyth, API3 dAPIs).
01
Public Feeds: MEV Resistance
Stronger censorship resistance: Updates are pushed on-chain by permissioned nodes at predefined intervals, making them difficult to front-run for a single user's transaction. This matters for protocols like Aave or Compound where liquidations must be fair and resistant to predatory MEV bots targeting stale price updates.
02
Public Feeds: Predictable Cost
Fixed, amortized cost: The gas cost for on-chain price updates is subsidized by the oracle network and spread across all consuming protocols. For developers, this means zero gas overhead per transaction. This matters for high-frequency DeFi applications on Ethereum Mainnet where user gas costs are a primary concern.
03
Per-Tx Oracles: MEV Vulnerability
Susceptible to front-running: Prices are fetched and submitted on-demand for a specific transaction. This creates a MEV opportunity where searchers can see the pending oracle update and front-run the target transaction. This matters for large trades on DEXs like Uniswap V4 using Pyth, where price latency can be exploited.
04
Per-Tx Oracles: Granular Cost Control
User-pays model: The requester pays the gas for the on-demand price pull. This allows for fresher data without burdening the protocol with constant update costs. This matters for low-latency, high-value applications on Solana or Avalanche, where gas fees are low and the latest price (e.g., for a derivatives settlement on Drift Protocol) is worth the extra cost.
PUBLIC FEEDS VS PER-TX ORACLES
Technical Deep Dive: MEV Attack Vectors
Maximal Extractable Value (MEV) is a critical attack surface for oracle designs. This analysis compares the inherent MEV vulnerabilities of public data feeds versus per-transaction oracles, helping infrastructure architects choose the right model for their protocol's risk profile.
Public data feeds are significantly more vulnerable to front-running. Since price updates are broadcast to the public mempool, searchers can easily see and front-run transactions that depend on a new price. Per-transaction oracles like Chainlink's requestId model or API3's dAPIs obscure the data request, making it much harder to identify and front-run the target transaction before it's confirmed.
CHOOSE YOUR PRIORITY
When to Choose Which Model
Public Feeds for DeFi
Verdict: The default for high-value, latency-sensitive applications. Strengths: Ultra-low latency (sub-second updates) from providers like Chainlink Data Streams or Pyth Network is critical for perpetuals and spot DEXs to prevent front-running. The continuous feed model minimizes the MEV surface for individual user transactions, as price updates are broadcast to all participants simultaneously. Trade-offs: Requires trust in the feed's liveness and the security of the underlying oracle network. Initial integration and subscription costs can be higher.
Per-Tx Oracles for DeFi
Verdict: Optimal for lower-frequency, high-assurance settlements. Strengths: Superior for finality-sensitive operations like loan liquidations or insurance payouts on protocols like MakerDAO or Aave. The proof-based, on-demand verification (e.g., using Chainlink's CCIP or a zkOracle) provides cryptographic certainty for that specific transaction, making it highly resistant to data manipulation MEV. Trade-offs: Higher per-transaction cost and latency (2-10 seconds) makes it unsuitable for high-frequency trading.
verdict
THE ANALYSIS
Final Verdict and Decision Framework
A data-driven breakdown to guide your infrastructure choice between public feeds and per-transaction oracles in the context of MEV.
Public Feeds (e.g., Chainlink Data Streams, Pyth Network) excel at providing low-latency, high-frequency price updates for a broad audience. This broadcast model amortizes oracle costs and latency across all consumers, enabling sub-second updates and gas-efficient reads for high-throughput DeFi protocols. For example, Pyth's Solana feed delivers updates every 300-400ms, supporting perpetual DEXs like Drift Protocol which require near real-time pricing to manage risk and liquidations effectively.
Per-Transaction Oracles (e.g., API3 dAPIs, Supra Oracles' pull-based model) take a different approach by fetching data on-demand for each specific transaction. This strategy results in superior freshness and customization for the exact moment of execution, a critical defense against MEV attacks like front-running and sandwiching. The trade-off is higher gas cost per transaction and potentially higher latency, as data must be fetched and verified within the transaction lifecycle itself.
The key trade-off is between cost-efficiency/latency and execution integrity. If your priority is maximizing throughput and minimizing operational cost for a high-volume application like a spot DEX or lending market, choose Public Feeds. If you prioritize maximizing security and fairness against MEV for sensitive transactions like large OTC trades, governance execution, or bespoke derivatives, choose Per-Tx Oracles. For many protocols, a hybrid model—using a public feed for general operations and a per-tx oracle for critical settlements—provides the optimal balance.
ENQUIRY
Build the
future.
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