Decoding VAA on custom chain

Hello,

I am building a custom DEX which is not on an EVM chain or any of the other Pyth supported networks. I am under the impression Pyth can be used for this use case but I’m not entirely sure as there is no docs. In fact, in the docs here: https://docs.pyth.network/price-feeds/use-real-time-data it says If your blockchain is not supported, please ask in the dev-forum.I am not operating on a general purpose blockchain so would need to do the vaa verification myself.

My questions are:

  • Is this an intended use of Pyth? Does it support custom L1s or rollups?
  • If yes, how do i decode and verify a vaa? How do i get guardian sets? Is there any example code?
  • I see that on certain chains like EVM you use a Proxy. If the VAA format changes the consumers don’t need to update their implementations as the implementation is upgrade and everyone interacts with the proxy and everything continues to work. In the case of updates, how would developers of chains like mine become aware?

Thanks

Hey @bison

Thanks for the post.

Yes Pyth can be deployed on pretty much any chain, whether it is permissioned/permissionless/app-specific etc.

For instance, the Pyth oracle contract is deployed on Polynomial chain, for their own perp dex.

Would you mind sharing more details on the network you want to use Pyth on?

Having an official Pyth oracle deployed on the chain/network you build on, enables you to have the same dev experience as any other chains already supported + the onchain verification of the cryptographic proof (VAA) of the price generated by the pyth oracle.

For some chains where the Pyth oracle is not deployed on, we do have seen some users that ‘sign’ themselves the price fetched from the Hermes endpoint. These are fully trusted oracle usage as the protocol sign itself so end users trust that the protocol does it as it should and does not replace/create fake Pyth prices.

Most of the changes are aimed to be done so that it’s retro-compatible but it is not possible to commit to this forever.
Assuming you went on and sign these prices from hermes yourself, indeed, a change of Hermes data structure would require up to update/fix this.
If this were to happen, I am pretty sure we would proactively announce the date and various changes so that people like you could have time to fix/update but again, will not commit to it nor bear responsibilities if things were to break (as it is not an official deployment/usage of Pyth).

Feel free to share more details on this network as we may just investigate to expand there.

We’re building a custom chain in rust so there’s no concept of smart contracts or a virtual machine. For us to integrate it would not be possible to “deploy pyth” in the traditional sense due to us not supporting generalised smart contracts but we would need to write some code equivalent to the smart contract in rust.

I’m not sure what details of the chain you need exactly. We are still in development, using rust, not using EVM or any other VM so would just like the rust code to validate signatures.

Resigning payloads removes the trust from Pyth and puts it on us to manage signatures from being compromised and it seems counterintuitive since the payloads are already signed and we just need the logic to verify them?

Would the price verification be done at the validator level or something like that (a bit like the Cosmos chains idea)?

But yeah overall you’d need something that verifies the VAA on your appchain/or validator client or something

yes, at that level. we essentially run a custom validator something like a cosmos chain (but not cosmos) and would need to do it there.

do you guys have some code that I could use or at least reference (any language)?

This should be it: pyth-crosschain/target_chains/ethereum/contracts/contracts/pyth/PythAccumulator.sol at main · pyth-network/pyth-crosschain · GitHub