Pyth Hermes → Custom EVM Chain Integration Issues

Price Feeds
1

Hi Pyth team,

We are integrating Pyth price feeds on our custom EVM chain (chain ID 968) using the standard Hermes → PythUpgradable pattern.

### Setup

- **Hermes URL:** `https://hermes.pyth.network`

- **Chain:** Custom EVM (chain ID 968)

- **Contract:** `PythUpgradable` deployed at `0x4992eb1cd3DD252603f2A7d296DeA8a2750535cd

our blockchain scan info

- **WormholeReceiver:** deployed separately on the same chain

WormholeReceiver deployed at 0x4939B9E9374c3197D4C16b551C23e78793D185c5

our blockchain scan info

- **Pusher:** Go service — fetches VAA from Hermes, submits via `updatePriceFeeds`

### Problem 1: Guardian Set Mismatch

We deployed a `WormholeReceiver` contract and configured it with guardian set addresses that we collected from previous Hermes VAA responses. However, the guardian set index from Hermes keeps changing between requests (we’ve seen index 0, index 6, etc.), and the addresses at the same guardian index are different across requests. This causes `updatePriceFeeds` to revert with:

```

InvalidWormholeVaa: Given message is not a valid Wormhole VAA

```

We wrote a diagnostic tool that queries the Hermes API multiple times. It discovered that hermes.pyth.network seems to serve VAAs from **different guardian sets** across requests (different `guardian_set_index` and different addresses for the same index). The most frequently seen set is index 6 with 14 out of 19 guardians collected.

**Question 1:** What is the current Pyth mainnet Wormhole guardian set (index and all 19 addresses)? We need the complete list so we can configure our `WormholeReceiver` correctly.

**Question 2:** Is hermes.pyth.network the correct Hermes endpoint for Pyth mainnet? Or should we use a different endpoint for our chain?

or what should i do ;

### Additional Context

- We can run diagnostic commands on demand to help debug

- Our pusher source code and configuration are fully available if needed

Any help would be greatly appreciated. Thank you!

here is some info i can offer you to help me :slight_smile:

```

=== VAA Guardian Signer Check ===
URL: https://hermes.pyth.network

Fetching: https://hermes.pyth.network/v2/updates/price/latest?ids[]=0xff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace&parsed=true … OK (1311 bytes VAA)

Guardian set index: 0
Signature count: 13

Recovered 13 signer(s):
guardian_idx=0 0x45eC320aA32B1a4D103D7D91c4BB769C2bBC62e7
guardian_idx=1 0x8b469378F6DA7A3FC8099725af021A01D335AcB1
guardian_idx=2 0xc33d23B6E7f58d976D216685B5e9187d3Baa3253
guardian_idx=3 0x0b53bB3842f1E39d51e86A4BF4De50fEA666ac12
guardian_idx=4 0xeFFe1D468f9a96f9f4Be1db5Fbb016ccd0D81c02
guardian_idx=6 0x742B8C7252Be18E339958fdca8813Be6f36E5a07
guardian_idx=7 0x30025BeA1f9204d55E7db78bAaaF8de8299823c0
guardian_idx=8 0x4A7B2e13e6C08809Ff076ec3CF91021999C6b030
guardian_idx=10 0x9Fb009d4c631c5d2d8B569535C816275C1776ecF
guardian_idx=12 0x228A96BBE2680edfA1a2E56f2F10Bf9D171831b4
guardian_idx=13 0x14cE839eDEd49D7BA90c4FC2D08a9d81A96376b7
guardian_idx=15 0x4A930E1Df9991806681d7522a4B3E02AabCFF95c
guardian_idx=16 0x9bf0947f92ed7d377EE2dC8fAA3144dB77879796

:white_check_mark: Pass these addresses to your contract team for verification.


i get the response data from hermes with price id ff61491a931112ddf1bd8147cd1b641375f79f5825126d665480874634fd0ace ,and then i recover the address from data; so i set these address to the WormholeReceiver setting the guardian set with; but when i send the data to contract i got the error info link this :
"{"level":"WARN","ts":"2026-06-17T17:39:13.681+0800","caller":"pusher/txmanager.go:301","msg":"Tx reverted","hash":"0xa7264bdd023373d0a307cd24c19aeaa93d133ed2dec540e25dd4bdd2591bea40","retry":3,"reason":"0x2acbe915 InvalidWormholeVaa: Given message is not a valid Wormhole VAA. Check that the VAA comes from a trusted source and is correctly formatted."}"

there is my Discord :tangecho

2

Hi Tang!

Thanks for the detailed write-up.

A few things here:

  1. https://hermes.pyth.network is the correct public Hermes endpoint for Pyth Core mainnet price updates.

  2. You should not derive/configure the Wormhole guardian set by sampling Hermes responses or recovering signer addresses from individual updates. Each VAA only contains a quorum of guardian signatures, not the complete guardian set, and the update payload returned by Hermes should generally be passed through to the Pyth contract as bytes[] unchanged.

  3. If you are deploying Pyth Core contracts on a custom EVM chain, the Wormhole receiver / guardian-set configuration has to match the supported Pyth/Wormhole deployment assumptions. A custom chain integration is not usually just “deploy PythUpgradable + copy observed guardian addresses”; it needs the correct Wormhole receiver setup and contract initialization.

Separately, we would strongly recommend not starting a new Hermes / Pyth Core integration right now. Hermes/Pyth Core is being deprecated soon. Roughly within the next month so for a new integration you should evaluate Pyth Pro instead.

Pyth Pro provides direct price delivery, supports signed payload formats, and is the path we’d recommend for new off-chain or custom-chain-style integrations:

Pyth Pro | Pyth Developer Hub
Pyth Core Upgrade | Pyth Developer Hub

3

So am I good to start integrating Pyth Pro following the integration instructions in the official docs Getting Started | Pyth Developer Hub ? Also, I noticed the official documentation only provides one single smart contract example at present pyth-examples/lazer/evm/src/ExampleReceiver.sol at main · pyth-network/pyth-examples · GitHub, with no standardized contract available for unified deployment. Does this mean developers need to take charge of writing the smart contracts themselves to a certain extent?

Additionally, I would like to check two more points:

  1. Are there any fixed official contract templates we can adopt to realize unified standard contract deployment? Or just using pyth-crosschain/lazer/contracts/evm at main · pyth-network/pyth-crosschain · GitHub and deploying these contract on my custom evm blockchain and interact with the contract was fine?
  2. When developing our backend service, can we rely on the repository https://github.com/pyth-network/pyth-lazer-public from GitHub as the foundation for backend development and push price data to the contract?

4

Yes, the Pyth Pro docs are the right place to start conceptually, but one important clarification: Pyth Pro is not officially deployed on BOT Chain today.

The official Pyth Pro contract addresses are listed here:
Contract Addresses | Pyth Developer Hub

Since BOT Chain is not listed there, you should not assume you can simply deploy the Pyth Pro / Lazer contracts yourself and have a fully supported integration. The verifier contract depends on trusted signer configuration, and that setup should come from an official Pyth-supported deployment process, not from sampling signatures or configuring signers manually.

For your backend, the normal Pyth Pro pattern is:

  1. Subscribe to Pyth Pro WebSocket updates using the SDK.
  2. Request the evm signed format.
  3. Relay those signed update bytes into your contract transaction.

The backend does not create or “push” its own price data; it only relays signed Pyth Pro updates.

The example contract is intentionally a consumer example. Developers still write their own application/receiver logic: accepted feed IDs, freshness checks, stored fields, permissions, etc.

Since BOT Chain is not currently an official Pyth Pro deployment, the most relevant docs for your evaluation are:

* Payload structure and binary formats/signature schemes:
Payload Reference | Pyth Developer Hub

* Subscription parameters, including formats:
Subscribe to Prices | Pyth Developer Hub

In particular, formats controls which binary payload you receive. Use evm for ECDSA/Secp256k1-style EVM verification, solana for Ed25519-native verification, and leUnsigned only for off-chain/no-signature use cases.

5

Based on the information you provided, in other words, if we intend to formally integrate the Pyth Pro oracle—whether on mainnet or testnet—we need to reach a cooperation agreement with your team first. After that, your team will deploy the official contracts using the private keys under your control, while our dedicated contract developers for BOT Chain will conduct secondary development to implement custom functionalities. With that in mind, I have a few questions:

  1. Will the private keys used for deploying Pyth Pro contracts be managed via MPC, threshold signatures, or a single-point private key setup?
  2. Does BOT Chain have administrative or operational permissions over the contracts deployed on the chain?
6

If you want a Pyth official contract deployed on BOT Chain, yes. If so please reach out to genia@dourolabs.xyz

You can of course use Pyth prices in a more trusted manner if you sign the prices yourself on BOT Chain.

In both cases it will anyway require a working Pyth Pro API.

Once deployed, the contracts are not transferred to anyone, they remain operated by Douro Labs.

7

Thank you for your patience. Let’s circle back to our earlier issue where we failed to implement price feeds via the Pyth Core contract integration. We’ve deployed contracts on our own testnet and are pushing data to the contract using the Hermes API we applied for, yet verification keeps failing.

Could you advise how we can obtain the correct Garden Set data and proper initialization parameters? Alternatively, does contract deployment require coordination with your team and have Douro Labs deploy it on our behalf?

Additionally, we would like to confirm whether the open-source project https://github.com/pyth-network/pyth-observer supports monitoring data sourced from Pyth Pro. According to its project documentation, this tool fetches price data from the Hermes API, but there is no explicit mention of compatibility with the Pyth Pro service. Could you clarify if we can utilize this tool to monitor our Pyth Pro data streams normally?

8

If you wish an official deployment working as the other chains, yes. If so, please contact genia@dourolabs.xyz

pyth-network/pyth-observer is a small Python monitoring service for on-chain Pyth / Pythnet-style price feeds, not a Pyth Pro/Lazer WebSocket monitor.

For Pyth Pro monitoring, you should build monitoring around the Pyth Pro WebSocket subscription flow itself: connect to the redundant Pyth Pro endpoints, subscribe to the required feed IDs/channels, request the needed signed format such as evm, and monitor stream freshness, latency, delivery gaps, and verification success in your own backend/consumer flow.