What is Pyth?

Introduction

PYTH is an oracle network for delivering market prices to blockchains. The core problem it solves is simple to state but hard to solve well: smart contracts need fresh prices for assets like BTC, ETH, equities, and indexes, but blockchains are expensive places to publish data continuously. If every price had to be pushed on-chain everywhere all the time, the cost would be high, the system would be inefficient, and many chains would end up paying for updates no one actually uses.

Pyth’s design starts from that constraint. Instead of treating oracle delivery as “broadcast every update to every chain,” it separates price creation from price consumption. Prices are aggregated on Pythnet, then made available to other chains in a form that users and applications can fetch when needed. That is why Pyth is best understood not just as a price feed provider, but as a particular answer to the question of how oracle data should move across chains.

What are first-party price feeds and how does Pyth use them?

Most readers coming to Pyth already know what a price oracle does: it gives a smart contract some answer to “what is the current price?” The deeper issue is where that answer comes from. Pyth is built around first-party data providers (the exchanges, trading firms, and market makers that originate market data) rather than a model where third-party operators mainly pull prices from external APIs and repost them.

That design choice matters because the hard part of oracle design is not only transporting data. It is preserving quality while minimizing delay and manipulation surface. If the source of truth is already a market participant producing price information, then the oracle network can aggregate data closer to where it originates. In Pyth’s model, data providers publish their prices directly to Pythnet, and the oracle program combines those contributions into a single aggregate price plus a confidence interval.

That confidence interval is part of what makes Pyth distinctive. Downstream consumers do not just get “the price is X.” They get a price and a measure of uncertainty around it. In volatile or thin markets, that extra information can matter as much as the point estimate itself, because a lending protocol or derivatives venue often cares not only about the midpoint but also about how reliable that midpoint is right now.

How are Pyth prices aggregated and published on Pythnet?

Pythnet is an application-specific blockchain used as the aggregation layer for the network. It is operated by Pyth’s data providers and is based on Solana technology, but it is independent of Solana mainnet. Its job is narrow and important: receive publisher updates and combine them into feed-level prices.

At the on-chain program level, each feed has associated on-chain state for metadata and pricing data. Authorized providers submit updates through an instruction called upd_price, which lets a provider write its current price estimate and confidence interval for a feed. The oracle program stores provider contributions internally, then aggregates them into the public result that downstream applications actually use: the feed’s current aggregate price and confidence interval. It also computes an exponentially weighted moving average, or EMA.

A useful detail here is that applications do not consume each provider’s raw update directly. The downstream interface exposes the aggregate result, not the full set of individual publisher prices. The mechanism is: providers publish independently, the oracle program maintains the internal per-provider state, and consumers read the aggregate output. That is what lets Pyth act as a network-level oracle rather than just a message board of quotes.

Imagine a BTC/USD feed. Several authorized publishers submit their current view of the market with associated confidence values. Pythnet stores those submissions, and when aggregation happens, the feed updates to a single current price and confidence. A protocol integrating Pyth on another chain does not need to know which publisher changed first or what every publisher said individually. What it needs is a verified aggregate answer that is recent enough for its own risk settings. That is exactly the interface Pyth is designed to provide.

Why does Pyth use a pull-based delivery model and what are the trade-offs?

The most important idea in Pyth’s architecture is its pull-based delivery model. In a push oracle, the network proactively writes updates on-chain for consumers. In a pull oracle, the consumer (or someone acting on its behalf) fetches the latest update and submits it when it is actually needed.

This sounds like a small implementation detail, but it changes the economics of the whole system. In a push model, every chain and every feed may incur write costs whether or not any protocol is about to use the data. In Pyth’s pull model, the cost appears when an update is needed for a real transaction. That makes a lot of sense for applications like liquidations, swaps, or settlement, where the economically important moment is the moment a contract is being called.

Pyth’s own documentation describes update fees paid by consumers to invoke price updates. That follows directly from the architecture: if users decide when fresh data should be brought on-chain, they are also the natural party to bear the cost of that update. The trade-off is equally direct. A pull model is usually more cost-efficient, but the application must actively ensure the price has been updated recently enough for its own safety requirements.

This is why Pyth’s on-chain consumer API is built around recency. Protocols read the stored Pyth price from the target-chain contract, and that API returns the price so long as it has been updated sufficiently recently. The protocol can configure its own freshness threshold. In other words, Pyth gives the application a lever: accept older prices and pay less often, or require fresher prices and trigger updates more aggressively.

How are Pyth prices delivered and verified on other blockchains?

Cross-chain delivery is where Pyth’s design becomes more interesting. Prices originate on Pythnet, but many applications want them on EVM chains and other networks. Pyth handles this by separating aggregation, attestation, retrieval, and on-chain verification.

Here is the mechanism. Data providers publish to Pythnet, and the oracle program aggregates feed prices there. On each Pythnet slot, validators send a Wormhole message containing the Merkle root of all prices for that slot. Wormhole guardians observe that message and produce a signed VAA, which is the attestation that the root was observed and signed by the guardian set.

A service called Hermes then listens both to Pythnet and to Wormhole. Hermes collects the price messages, their Merkle proofs, and the signed root. It stores the latest updates and exposes them over HTTP and streaming APIs. When a user or protocol wants to use a Pyth price on a target chain, it retrieves the latest update from Hermes and includes that update in its transaction.

On the target chain, the Pyth contract verifies the update in two steps. First, it checks the Wormhole signatures on the Merkle root. Second, it checks the Merkle proof showing that the specific price update is part of that signed root. If the proof verifies, the contract stores the new price on-chain. After that, the consuming protocol reads the price from the local Pyth contract through a simple API.

The reason this works is that the expensive part (collecting and packaging many feed updates) happens off-chain, while the chain only verifies compact cryptographic evidence. That is the core efficiency gain. Instead of forcing every chain to trust a centralized API call or pay for constant raw data publication, Pyth provides a path where data is aggregated once, attested once per slot, and verified where needed.

How do developers integrate Pyth into DeFi protocols and apps?

For most builders, Pyth is not something they “join” so much as something they integrate. A protocol chooses feed IDs for the assets it cares about, fetches updates from Hermes through REST, streaming, or an SDK, and submits those updates to the Pyth contract on the relevant chain when a transaction needs fresh prices.

That makes Pyth especially well suited to applications where price freshness is important but constant blind broadcasting would be wasteful. DeFi lending, perpetuals, options, and trading systems fit naturally here because they already have high-value moments (opening a position, liquidating collateral, settling a trade) where paying to refresh the oracle is economically justified.

Pyth also has a broader product surface than only its core on-chain oracle. The developer hub describes Pyth Core as the decentralized price feed product with deterministic on-chain delivery, supporting both pull and push updates across more than 100 blockchains. It also describes Pyth Pro, a subscription-based ultra-low-latency product for institutions and advanced use cases. That matters because it shows Pyth serves two adjacent audiences: on-chain applications that need verified oracle updates, and more latency-sensitive or institutional users who may want off-chain delivery with commercial support.

What is Pyth’s trust model and its main trade-offs for integrators?

Pyth is not magic; it is a set of design choices. The strengths come from those choices, and so do the constraints.

The first strength is source quality. Using first-party publishers means the network is built close to the origin of market data. The second is cost efficiency. The pull model avoids paying for universal updates that no one uses. The third is expressiveness. Pyth exposes both price and confidence, which helps downstream applications reason about uncertainty instead of pretending every price is equally precise.

The main trade-offs follow the cross-chain path. Pyth’s delivery mechanism depends on Wormhole for signed attestations of Pythnet state, and on Hermes or another compatible service layer to package and serve updates conveniently. The Pyth docs note that Hermes can be run by third parties and that the Pyth Data Association operates a public instance for development purposes. So while the on-chain verification path is cryptographic, the operational experience still involves external infrastructure choices.

There is also a governance dimension.

Pyth’s whitepaper announcement makes clear that some economic and operational questions are or were left to governance.

• including update-fee sizing
• publisher rewards
• aspects of publisher permissioning

The docs also point to PYTH as the native token used for governance and staking, and to Oracle Integrity Staking as a mechanism for staking PYTH to support publishers and secure feed integrity. Those pieces matter for the network’s incentive layer, but some exact parameters are governance-dependent rather than fixed forever.

Finally, because Pyth is designed around recency thresholds and consumer-triggered updates, integrators must choose their own freshness policies carefully. A protocol that demands very fresh prices may pay more often. A protocol that tolerates stale prices saves money but increases risk. That is not a flaw in the system so much as the practical consequence of making freshness an application-level choice.

Conclusion

Pyth is a first-party, cross-chain oracle network built to deliver market prices efficiently across many blockchains. Its key idea is to aggregate prices on Pythnet, attach confidence to those prices, and let applications pull verified updates onto their own chain when they actually need them.

If you remember one thing, remember this: Pyth is useful because it turns oracle delivery from constant broadcasting into on-demand verification. That shift explains who it is for, how it works, and why its architecture looks the way it does.

How do you buy Pyth?

You can buy PYTH on Cube by funding your account and placing a spot order in the PYTH market. Cube supports fiat on-ramps and crypto transfers for funding, and lets you choose between market orders for immediate fills or limit orders to control price and slippage.

1. Fund your Cube account with fiat via the on-ramp or deposit a supported token (e.g., USDC) to your Cube deposit address.
2. Open the PYTH/USDC (or PYTH/USD) spot market on Cube Exchange and check the orderbook depth.
3. Choose an order type: use a limit order to control execution price and reduce slippage on a thin PYTH market, or a market order for immediate execution.
4. Enter the PYTH amount or the USDC you want to spend, review the estimated fill, fees, and routing, then submit the order.