Pyth vs Switchboard: Read Latency

Pull-based architecture: Data is updated on-chain only when a user transaction requests it. This enables sub-second price updates (often < 400ms) and near-zero on-chain gas costs for data providers.

Key for: High-frequency DeFi applications (e.g., perpetuals on Solana, Jupiter's limit orders), where the latest price is critical and gas efficiency is paramount.

Passive data propagation: If no one calls the price, it can become stale. While Pyth uses a confidence interval and a 'staleness threshold' (e.g., price is invalid if not updated in X seconds), protocols must actively manage this risk.

Key consideration for: Protocols that cannot tolerate any chance of stale data during low-activity periods must implement their own heartbeat or fallback logic.

Push-based architecture: Data is updated on-chain at a pre-defined interval (e.g., every slot, every 10 seconds) by permissioned oracles, regardless of user demand. This provides deterministic, guaranteed freshness.

Key for: Lending protocols (Solend, Marginfi), stablecoins, and any application where a verifiably recent price is a security requirement, even during low volume.

Update overhead: The fixed interval means the data is, by definition, as old as the interval (e.g., up to 10 seconds). Oracles bear the recurring gas cost for pushes, which can be significant on high-throughput chains.

Key consideration for: High-frequency trading apps where even a few seconds of lag is unacceptable, or for oracle operators managing cost-efficiency across many feeds.

Pull-based, on-demand updates: Pyth's architecture allows consumers to request the latest price on-chain, bypassing scheduled update cycles. This results in sub-second latency for critical price feeds. This matters for perpetual DEXs and liquidation engines where milliseconds count.

Push-based, heartbeat updates: Oracles publish at a pre-defined, configurable interval (e.g., every 5-30 seconds). This creates predictable, consistent latency and cost. This matters for lending protocols, stablecoins, and TWAP oracles where extreme freshness is less critical than reliability and cost control.

Efficient batch updates: By updating on a schedule, Switchboard amortizes transaction costs across all consumers for that period. For applications not requiring millisecond-fresh data, this results in significantly lower gas expenditure per data point compared to frequent pull updates.

Pull-based architecture: Data is published on-chain, allowing protocols to read the latest price in a single on-chain transaction. This results in sub-second latency for price updates. This is critical for high-frequency trading protocols (e.g., perpetuals on Drift, Synthetix) where every millisecond of stale data can lead to arbitrage losses.

High on-chain cost: Every price update is pushed to the Pythnet appchain and then relayed to all supported blockchains (Solana, Sui, Aptos, EVM L2s). This creates significant cross-chain data availability overhead. While read latency is low, the system's overall update frequency is constrained by the slowest and most expensive chain in its network, impacting freshness for less active assets.

Flexible data retrieval: Protocols can choose on-demand pull or scheduled push models via permissionless oracle queues. This allows optimization for specific use cases—pull for infrequent, gas-sensitive reads (e.g., lending health checks) and push for real-time feeds. This granular control is ideal for specialized DeFi primitives (e.g., structured products, insurance) with non-standard latency needs.

Oracle request lifecycle: In pull mode, a protocol's request must be picked up by a keeper, executed off-chain, and the result posted on-chain. This multi-step process introduces variable latency (2-12+ seconds), dependent on keeper incentives and network congestion. This makes it less suitable for latency-sensitive arbitrage or perpetual markets compared to Pyth's direct pull model.