Most oracle networks before Pyth used a push model. A service ran on every supported chain, writing a fresh price on-chain at a regular cadence so any contract could read it from a known address. That works, but it pays gas continuously on every chain regardless of whether anyone is reading.
Pyth flips that. The aggregation runs on a single appchain (Pythnet). Signed updates accumulate centrally. When a contract on Solana, Ethereum, Sui, or any other supported chain needs the price, a relayer fetches the latest update from Hermes and posts it on-chain inside the same transaction that needs the price. The consumer verifies Pyth's signature and uses the value.
Why it matters
- Cost scales with usage, not chain count. A new chain integration is one verifier contract — no node committee to fund per chain.
- Updates can be as fresh as the requesting transaction. The contract chooses the staleness tolerance, not a scheduler.
- Idle gas is zero. Chains with infrequent reads aren't paying for updates nobody is consuming.
The tradeoff
Each on-demand update is paid for by the consumer — a small update fee on top of normal gas — and adds a fraction of a second to the path. Apps that want continuous fresh prices regardless of read traffic still need their own keeper. Pull is most efficient when prices change faster than reads happen, or when many chains are involved.
Where it shows up in Pythscan
Open any feed and watch the publish time on the hero card refresh as new updates flow through. The feed exists on Pythnet, but the same identifier resolves to a deployed verifier on every chain listed under Chains.