Hello everybody,
I am Christian, from Ark Labs, the company building Arkade, a programmable execution layer for Bitcoin: https://arkadeos.com. We are looking for support for off-chain price feeds.
We are interested in receiving price messages with signatures that we can independently verify.
In this regard I would like to understand the following:
Key rotation policy
Do you have a formal policy or process for rotating the keys used to sign price messages? If so, how frequently are keys rotated, and under what circumstances might an unscheduled rotation occur?
Communication of signing key changes
How do you notify customers when the signing key changes? Is there a defined notice period, and do you provide any overlap period during which both the old and new keys are valid?
Signed message format changes
How do you communicate changes to the format or schema of signed price messages? Are such changes versioned, and do you provide backward compatibility or a migration period?
Thanks in advance. I would be happy to schedule a call if that is easier.
Best regards,
Christian
Ark Labs
Hey Christian,
Unscheduled rotations can occur, for example, if we need to respond to a security incident.
During scheduled key rotations there will be a period when both old and new keys are valid to enable zero downtime for consumers.
We always strive to never break backwards compatibility of the format of signed price messages. We do sometimes add new fields to the payload to support new features in a backward-compatible way, and we also sometimes deprecate old APIs, but we have never broken backward compatibility for the actual signed payload schema.
We communicate any breaking changes in the Dev Hub (here) and on our Docs site, and are soon creating a changelog page for this purpose as well.
I would recommend subscribing to Dev Hub updates to get notified automatically when we are planning any breaking changes to APIs or payloads.
Thank you Kemar for your reply.
What is the canonical way to fetch the Wormhole guardian set addresses (or the 5 Independent Routers after update), so I can verify Pyth Hermes/Core signatures locally?
For current Hermes / Pyth Core, the canonical source of truth for the Wormhole guardian set is the Wormhole Core Bridge state, not Hermes responses. Hermes returns signed price update payloads, but it should not be treated as the registry for the full signer set.
For local/off-chain verification, you would need to read the active Wormhole guardian set from the Wormhole Core Bridge contract / Wormhole SDK and verify the VAA against that set.
That said, Pyth Core/Hermes is being upgraded on July 31, 2026. The upgraded system moves from Wormhole Guardians to 5 independent Pyth Pro routers with a 3/5 quorum, and Hermes will require a Pyth API key. For a new off-chain signed-price integration, we’d strongly recommend looking at Pyth Pro instead:
Pyth Pro | Pyth Developer Hub
Thank you. Ok, going for Pyth Pro but now I have the same question for Pyth Pro. How to retrieve official signers pubkey/addresses for offchain verification? In the documentation it looks that I can verify signatures on-chain only.
Hello @KemarTiti Did you have the chance to look into this?
For Pyth Pro, the canonical source of truth for trusted signers is the Pyth Pro/Lazer verification contract state, not a separate Hermes/REST endpoint.
And for EVM specifically, the verifier recovers the signer from keccak256(payload) and checks isValidSigner(signer) on the deployed PythLazer contract.
If the chain is not listed here, it does not have yet an official deployment:
Contract Addresses | Pyth Developer Hub
If you wish to request an official deployment, please reach out to genia@dourolabs.xyz
If you wish to sign the data yourself, have you seen this already: Payload Reference | Pyth Developer Hub ?