Pyth vs Chainlink: Price Expiry Rules

On-demand pricing model: Consumers pay only when they request an update, with no recurring cost for idle feeds. This matters for options protocols or insurance dApps that may only need price checks at settlement (e.g., weekly or monthly). Avoids paying for unused data.

Sub-second updates with verifiable timestamps: Pyth provides a confidence interval and publish time on-chain for each price. This matters for perpetual futures DEXs (like Hyperliquid) and high-frequency strategies where stale data directly translates to arbitrage losses. Updates are pulled at the exact moment needed.

Heartbeat-driven push model: Prices are updated at regular intervals (e.g., every block or 1 second) regardless of demand. This matters for lending protocols (like Aave) and stablecoin mechanisms that require constant, unwavering price availability for liquidations and mint/redeem functions, ensuring the feed is always "live".

No expiry management overhead: The protocol handles update scheduling. This matters for teams prioritizing operational simplicity and mitigating update failure risk. There's no need to build custom logic to monitor and pull new prices, reducing integration complexity and potential points of failure in your smart contracts.

Update responsibility shifts to consumer: If your protocol fails to call for a new price before the old one expires, your application may halt or use stale data. This matters for protocols with complex governance or multisig timelocks that cannot guarantee timely updates, introducing operational risk that must be actively managed.

Costs are incurred continuously, even if data isn't consumed. This matters for niche assets or new protocols with low volume, where paying for perpetual updates of a rarely-used feed (e.g., a specific forex pair) can become a significant and inefficient operational expense compared to a pay-per-use model.

On-chain expiry timestamps: Each price feed has a validUntil time. After expiry, the price is considered stale and is not used for new updates, forcing consumers to check freshness. This creates a fail-safe mechanism for high-frequency trading protocols like perpetuals on Hyperliquid or Synthetix V3, where stale data is catastrophic.

Client-side burden: The protocol does not automatically revert transactions using stale data. It's the dApp's responsibility to query the validUntil timestamp and reject stale prices. This adds implementation complexity and gas overhead for every price fetch, a critical consideration for high-throughput DeFi applications on Solana or Sui.

Configurable freshness: Data is updated based on a heartbeat (time) and deviation threshold (price change). This provides predictable, gas-efficient updates for less volatile assets. It's ideal for lending protocols like Aave and Compound, where extreme freshness is less critical than reliability and cost predictability for stablecoin/ETH pairs.

Potential for outdated data: If the price doesn't move beyond the deviation threshold, it can remain static for the full heartbeat period. In sideways markets, this creates a window of vulnerability where the on-chain price lags behind real markets. Protocols must carefully tune parameters for their specific asset volatility, adding operational overhead.