Pyth vs API3: Oracle Scalability

Pull-based model with P2P network: Data is published on-chain only when a user request (pull) is made, minimizing base-layer costs. The Pythnet appchain aggregates data off-chain at 400ms intervals. This matters for high-frequency DeFi (e.g., perpetuals on Solana, Sui) requiring sub-second price updates.

Direct integration with major institutions: Data is sourced from ~90 first-party publishers (e.g., Jane Street, CBOE) rather than aggregating existing APIs. This reduces latency and potential points of failure. This matters for protocols needing institutional-grade data with verifiable provenance and minimal manipulation vectors.

Push-based, aggregated data feeds: dAPIs are continuously updated on-chain by first-party oracle nodes. While each update costs gas, the cost is amortized across all dApp users. This matters for EVM-centric dApps (e.g., on Arbitrum, Base) where predictable, subsidized data costs for users are a priority.

API3 DAO controls data feeds: Feed configuration, provider selection, and revenue distribution are managed by token holders. This creates a permissionless marketplace for data. This matters for protocols requiring censorship-resistant oracle services and teams who want direct influence over their data source's parameters.

• High-Performance, Non-EVM Chains: Solana, Sui, Aptos where low-latency is critical.
• Maximal Data Freshness: Applications like perpetual futures or options that trigger on sub-second price movements.
• Institutional Data Preference: Willing to trust a curated set of high-quality, first-party publishers.

• EVM Ecosystem Focus: Deploying on Ethereum L2s (Arbitrum, Optimism) or other EVM chains.
• Decentralized Curation: Preference for a DAO-managed, permissionless data marketplace over a curated whitelist.
• Predictable User Experience: Willing to pay for consistently updated on-chain data to eliminate user pull transactions.

Pull-based, on-demand updates: Data is updated and delivered only when a user transaction requests it, minimizing on-chain storage and gas costs. This enables 400+ price feeds with sub-second updates. This matters for perpetual DEXs (e.g., Hyperliquid) and options protocols requiring real-time, granular data.

Wormhole-based attestations: Price data is signed off-chain and verified via light clients on over 50 blockchains. This provides native scalability without relying on a single settlement layer. This matters for multi-chain DeFi applications (e.g., MarginFi on Solana and Sui) that need consistent data across ecosystems.

Push-based, first-party oracles: Data is pushed on-chain at regular intervals by the data providers themselves (Airnode). This creates transparent, fixed operational costs with no per-call fees, avoiding gas price volatility. This matters for long-tail assets and budget-conscious dApps where cost predictability is critical.

DAO-managed dAPIs: The API3 DAO curates and manages data feeds, with providers staking tokens as collateral. This aligns incentives for cryptographic proof of provenance. This matters for protocols prioritizing verifiable decentralization and censorship resistance over pure latency, such as insurance or prediction markets.

Reliance on Pythnet: The core aggregation and signing occur on the permissioned Pythnet appchain. While the data sources are diversified, the attestation layer presents a centralized technical dependency. This is a trade-off for protocols that prioritize performance and breadth of feeds over maximal decentralization.

Block-by-block push model: On-chain updates are limited by block times and provider-set intervals, leading to higher latency (often 12+ seconds on Ethereum L1). This is a trade-off for high-frequency trading dApps on low-latency chains (e.g., Solana, Avalanche) that require tick-level data.

Pull-based (Publish/Subscribe) model: Consumers request data on-demand via Solana or Pythnet. This enables 400+ publishers to feed data for 500+ price feeds with sub-second updates. Matters for: High-frequency DeFi protocols (e.g., perpetual DEXs like Drift, margin platforms) that need the latest price within the same block and can absorb the gas cost of an on-chain pull.

Wormhole-based bridging: Data is published on Pythnet/Solana and bridged to 50+ chains. This introduces a dependency layer and potential latency during network congestion. While fast, the architecture adds complexity versus a native solution. Matters for: Protocols requiring absolute minimal failure points or deterministic finality across all supported chains.

Push-based (dAPI) model: First-party oracles update on-chain data feeds directly, paid by the dAPI's staking pool. This removes the gas cost burden from the end-user. dAPIs serve data to 20+ chains natively. Matters for: Mass-market dApps, gas-sensitive operations (e.g., gaming, micro-transactions), and protocols where predictable, sunk operational costs are preferable to variable user-paid gas.

Update frequency is configurable per dAPI, balancing freshness with cost. While suitable for many use cases, it may not match the sub-second cadence of specialized pull oracles for the most latency-sensitive feeds. Matters for: Applications like lending (AAVE, Compound forks) or insurance that prioritize cost efficiency and reliability over millisecond-level price updates.