Perseus Network Upgrade

The Pyth Network just launched the Perseus Upgrade, a major improvement to the oracle network. This upgrade significantly reduces gas costs for users, while also decreasing latency and enhancing reliability. These improvements stem from major changes to the network architecture. In addition to the benefits mentioned above, these changes create opportunities to launch new functionality and features. This blog post describes the upgrade and analyzes some of its benefits.

The Pyth Network aims to bring all of the world’s financial data on-chain for developers globally.  The ability to process thousands of transactions rapidly will be crucial for future DeFi systems. This requirement makes cost efficiency a critical imperative for DeFi primitives—especially price oracles, since they are the cornerstone of Web3 capital markets. The Perseus Upgrade represents a pivotal milestone in enhancing data accessibility to unlock high-throughput DeFi applications.

We’ll start with an overview of the Pyth Network’s architecture before explaining how the Perseus Upgrade makes the oracle’s price delivery cheaper and more accessible than before.

Background

The Pyth Network launched its low-latency Pythnet Price Feeds last year. These feeds featured a novel permissionless “pull” mechanism, representing a fundamental change to oracle architectures. In contrast, most legacy oracles used a “push” mechanism: the oracle itself would continuously publish transactions to the blockchain that updated the on-chain price. This approach is not scalable, as the oracle must pay transaction fees for every update, so it becomes economically infeasible to support frequent updates of many price feeds on many blockchains.

The pull mechanism changes oracle economics to be highly scalable. The Pyth Network oracle generates a stream of signed price updates off-chain, and allows Pyth users to permissionlessly pull any of those prices on-chain. As a consequence, the Pyth data providers do not pay transaction fees, and thus the architecture can scale easily. In fact, the pull mechanism even enables the oracle to monetize by charging users a small fee every time they update the on-chain price.

Pythnet Price Feeds have grown tremendously since launch. The growth speaks to the needs of applications for high-frequency feeds, for many assets, on many blockchains. It now supports over 300 price feeds, updating once per second—Perseus lowers this to every 400 milliseconds—on over 30 blockchains. Major protocols have integrated these feeds, including Vela Exchange, Aevo, HMX and more.

Pull Architecture

Pythnet Price Feeds used the following pull architecture prior to the upgrade:

The backbone of the pull architecture is Pythnet, an application-specific blockchain operated by data providers. This blockchain is a Solana Virtual Machine (SVM) chain, but is independent of Solana mainnet-beta. Pythnet hosts several programs that perform different functions:

• The Aggregation Program combines prices from data providers into a single aggregated price.
• Wormhole is a cross-chain messaging protocol. The Pythnet feeds use this protocol to create the signed off-chain messages.
• The Attester is the connection between the aggregation program and Wormhole. It reads price data from the aggregation program, formats it into messages, and sends them to Wormhole. In order to reduce the number of messages, the attester program batches 5 price updates into each message.

After the data is sent through Wormhole, it arrives at the price service. This web service provides a convenient HTTP API to retrieve signed price updates. Pyth Network users communicate with this API and submit the retrieved price updates to the Pyth contract on their blockchain. The Pyth contract verifies the signed messages and stores the contained price.

While this architecture has been effective, it is not optimal. There are two main problems, centered around the Attester:

• The Attester batches 5 price updates into a single Wormhole message. This batch size is a compromise intended to reduce verification cost on target chains and Wormhole message rate. However, Pyth users cannot select which feeds are in each batch. As a consequence, users are often forced to submit multiple messages to the Pyth contract, incurring the Wormhole verification cost for each one. It’s quite rare for two of a user’s desired feeds are in a single batch—with a batch size of 5 and 300 feeds, the probability is 1/60.
• The attester needs to be continuously “cranked” from off-chain. In order for Wormhole to send a message, the Wormhole contract must register a transaction. For various technical reasons, the crank can only be operated once per second per price feed, and cranking introduces variability in the timing between price updates.

Perseus Upgrade

The Perseus Upgrade is a significant change to the network that improves the path by which data flows from Pythnet to other blockchains, thereby fixing both of the problems above. The core change introduced by this upgrade is to eliminate batching, and instead allow users to group together any set of feeds into a single payload. To achieve this goal, the system constructs a Merkle tree of price updates, then signs the root of the Merkle tree using Wormhole.

A Merkle tree is a data structure for provably storing a collection of values. You create a merkle tree from a collection of items, e.g., [A, B, C, D], by hashing adjacent items pairwise to create a tree:

The topmost node of the tree is called the root. Its value uniquely identifies the collection of items. Furthermore, anyone can prove that their item is in the collection via a Merkle proof. The proof consists of the children of the nodes along the path from the item to the root. For example, to prove that A is in the tree above, the proof would be [A, B, hash(C, D)]. Given this path and the root, anyone can check that A is in the tree—simply compute hash(hash(A, B), hash(C,D)) and check that it equals the root. Furthermore, due to the cryptographic properties of hash functions, it is computationally infeasible for anyone to prove that another item is in the tree. For example, given an item E, there’s no way to construct a proof that E is in the tree above.

Merkle trees allow the new design to solve the batching problem. The protocol puts all of its current prices into a Merkle tree, then uses Wormhole to sign the root of the tree. Pyth users can then create a price update payload containing exactly the price updates they want. This payload includes the signed tree root, along with the Merkle proofs of each included price update. To verify the payload, the Pyth Network contract simply checks the Wormhole signatures on the root, then checks the Merkle proofs.

The Perseus Upgrade puts the Merkle tree computation into the Pythnet validator itself. The new architecture looks like this:

Everything before the aggregation program and after Wormhole are the same as before. However, the connections between those components has changed. Instead of the attester program with its crank, there’s a new program called the message buffer. This program stores a collection of messages (each of which holds arbitrary data) that should go into the Merkle tree. The aggregation program directly calls into the message buffer program every time the aggregate price is updated, and writes a price update message into the buffer. The Pythnet validator reads the messages in the message buffer at the end of every slot, computes a Merkle tree, and publishes the Merkle tree root to Wormhole. The validator also maintains an on-chain circular buffer of the Merkle tree contents (which will be needed to construct Merkle proofs later).

To pull an update on-chain, users first assemble an update payload. They take the Wormhole-attested Merkle root, select the price updates they want, then retrieve the corresponding data and Merkle proofs from Pythnet. They assemble all of this into a payload in a specific format that the Pyth contract understands.

If that process sounds a little complicated, well, it is. The Perseus Upgrade includes a new version of the price service called Hermes that does all this work for Pyth users. This service has the same API as the existing price service, but returns the new, more efficient payloads. Simply query its HTTP or Websocket API with the IDs of the price feeds you want, and it will do the rest.

Benefits

The Perseus Upgrade brings several significant benefits to Pyth Network users.

Price updates cost less. Here’s the cost of updating a single price on the various supported ecosystems:

As you can see from the graph above, “Baseline” represents the gas cost of a single batch update, and “Perseus” represents the gas cost of a single Merkle tree update. Both numbers are represented as percentages of the cost of a single batch update to standardize the measurement across ecosystems. This graph shows that a single update is cheaper on every ecosystem except for Aptos [1]. EVM L2 costs have been split into two bars, one for the L2 gas, and one for the L1 fees (which typically represent the majority of the transaction cost on Ethereum L2s). The change in cost varies across ecosystems due to differences in how each one computes gas.

Price updates are even cheaper if you update multiple prices at the same time. The following graph shows the cost of updating five price feeds for the same ecosystems:

This graph shows a cost reduction of 50-80% across ecosystems with the Perseus Upgrade.

The cost reduction for multiple updates comes from the fact that transactions only have to verify one set of Wormhole signatures regardless of the number of updates. Hashing is relatively cheap compared to signature verification, so checking the Merkle proofs is not a major factor in the overall cost.

Price updates are faster and more frequent. The Pythnet validator publishes price updates once per slot, that is, every 400ms, which increases update frequency by 2.5x over the previous once per second speed. A faster update frequency also means lower average latency. Part of that reduction is from the increased update frequency, and the other part is from removing the attester and simplifying the whole pipeline.

Extensibility. The message buffer opens the door to publish new kinds of data, such as TWAPs and volatility. All we have to do is update the aggregation program to write the new message into the message buffer. From there, the validator will automatically put the message in the Merkle tree and make it verifiable on-chain.

Security

The Perseus Upgrade was audited by Trail of Bits and Ottersec. The audit reports are available here.

Conclusion

The Perseus Upgrade is now live in mainnet. As a Pyth Network user, you can upgrade by simply changing your price service URL to point to Hermes instead:

• Mainnet: hermes.pyth.network
• Testnet: hermes-beta.pyth.network

You can also find the relevant documentation here. Try it out and let the Pyth contributors know what you think in the Pyth Network Discord.

Footnotes

1. A single update is generally cheaper because hashing is less expensive than processing a full batch of price updates; this is true on every chain except Aptos.

We can’t wait to hear what you think! You can join the Pyth Discord and Telegram, follow us on Twitter, and be the first to hear about what’s new in the Pyth ecosystem through our newsletter. You can also learn more about Pyth here.