Pyth vs API3: Revert on Failure

Pull-based, permissioned network: Aggregates data from 90+ first-party publishers (e.g., Jane Street, CBOE) for 400+ price feeds. Updates on-chain via Pythnet every 400ms. This matters for high-frequency DeFi like perpetuals and spot trading on Solana, where sub-second latency is critical.

Wormhole-powered attestations: Data is signed on Pythnet and pushed to 30+ supported blockchains via Wormhole. This creates a unified data layer where a single update can be consumed across Solana, EVM chains (Arbitrum, Base), and Move chains (Sui, Aptos). This matters for multi-chain dApp deployment.

dAPI architecture: Data is sourced directly from first-party providers (e.g., OpenWeather, Binance) who run their own oracle nodes (Airnodes). This eliminates middlemen, reducing trust assumptions and providing cryptographic proof of source. This matters for institutional-grade data and compliance-sensitive applications.

DAO-managed coverage pool: The API3 DAO manages a staking pool that provides on-chain insurance for dAPI users against data feed failures. Stakers underwrite the data and are slashed for malfeasance. This matters for risk-averse protocols (e.g., institutional DeFi, RWA platforms) requiring financial recourse.

• Ultra-low latency trading (Perps DEXs like Drift, Hyperliquid).
• Multi-chain dApps needing the same feed on many L2s.
• Solana-native development where Pyth is the de facto standard.
• When you prioritize maximum data freshness over decentralized governance.

• Transparent, verifiable data sourcing from named providers.
• Applications needing insurance against oracle failure (e.g., RWA, insurance protocols).
• EVM-centric development with a preference for decentralized governance.
• When data provenance and auditability are non-negotiable requirements.

Deterministic Safety: Pyth's on-chain programs revert transactions if the price update is stale or invalid, preventing protocols from operating on bad data. This is enforced at the protocol level for feeds like SOL/USD and BTC/USD. This matters for high-value DeFi protocols like MarginFi and Drift that require absolute data integrity for liquidations.

Flexible Failure Policies: API3's dAPIs allow the dAPI sponsor (often a DAO) to set a failure strategy per feed—revert, return last known value, or use a fallback oracle. This matters for gas-sensitive applications on L2s like Arbitrum or protocols like Lido that may prioritize liveness over strict freshness for certain functions.

Potential for Transaction Stalls: If the Pyth network experiences a temporary outage or high congestion, dependent protocols may see transactions fail until a fresh update is pushed. This can impact user experience in fast markets. Protocols must implement robust frontends to handle revert errors gracefully.

DAO Decision Required: Choosing and updating a failure policy requires governance action by the dAPI's sponsor DAO. This adds latency for protocol changes and assumes effective decentralized governance. This matters for rapidly iterating protocols that need to adapt failure strategies quickly based on market conditions.

Pull-based architecture ensures on-chain data is always fresh and valid. Smart contracts explicitly request an update, which reverts if the Pyth network cannot provide a price within a predefined confidence interval and staleness threshold. This eliminates the risk of using stale data, crucial for high-value DeFi protocols like perpetuals and lending markets where a single bad price can lead to insolvency.

Higher per-update gas costs for the end user. Each price pull is a new on-chain transaction. While Pyth's Wormhole-based attestations are efficient, the model is less optimal for high-frequency, low-margin applications (e.g., some DEX arbitrage) where gas fees can erode profits. The cost is paid by the integrator at the time of use.

Push-based dAPIs offer a gas-efficient model for data consumers. Once a dAPI is funded, updates are pushed on-chain by first-party oracles at regular intervals. Users pay a predictable subscription fee (often in stablecoins) instead of variable transaction gas for each data point. This is ideal for high-throughput dApps seeking stable operational costs.

Requires active monitoring. If a dAPI update fails, the last known price remains on-chain until the next successful update. Integrators must implement their own circuit breakers and staleness checks (e.g., using timestamp values) to pause operations. This shifts some security responsibility to the dApp developer, adding complexity compared to Pyth's built-in revert.