Byte by byte breakdown of Hex encoded data received in latest price update API

Price Feeds
1

Hi, I was working on a use case that required some documentation that is not available on the website.

I was making use of this latest price updates API

https://hermes.pyth.network/v2/updates/price/latest?ids[]=0xe62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43&ids[]=0xc96458d393fe9deb7a7d63a0ac41e2898a67a7750dbd166673279e06c868df0a

In the output, I received a hex string. I would like to have a documentation describing byte by byte breakdown of this hex string. I want to build an encoder of my own which will generate the hex encoded string that will be sent as an input to updatePriceFeeds() API. So, this data that my encoder will generate needs to be in correct format so that it is not rejected by updatePriceFeeds() API.

• :link: Chain: Ethereum Mainnet

• :stopwatch: Timestamp of the issue (block time or UTC): 1750801394

• :test_tube: Steps to reproduce the issue

  1. Make a call to this API endpoint:

https://hermes.pyth.network/v2/updates/price/latest?ids[]=0xe62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43&ids[]=0xc96458d393fe9deb7a7d63a0ac41e2898a67a7750dbd166673279e06c868df0a

  1. And now you’ll receive the following hex encoded string in output:

504e41550100000003b801000000040d00561f4ceb8ce5eb58adda318009817714a017b0db9a7f1ef57253c81d1984d8140cdee5c06925a1cbd7a2612211fddcd91008dd854444b513519a06fdc1a7b00101021612a8c846810b86a42eb3c9fc25ad9b1c5bbccf6bcd2df39fa83bfd580a58646d508fa28c4cecd8878eefaf964eca8de36031cad28b3c8a870a409a8b0a062d0003e8c8dd8bc33307235e3073e7a66af5087824628e8e6b4fa02df9e8fd1bf4757f28388255e1866b52edb0d8f604e97c6afcb05a33dce52b48dbdeeea85028e9ac0004460bf2bce4fd0f84961c20728aa48d35c35ca7347ad6229800312013e3645371016c837a779fe8c31e6e9b6d5cdeb41e6e215627d6a51e2bf8faaa7ddf25e0ec00065283785418ac10b5b7ee3eb5b753f7e319a6c9890180821c8c6b2b57912ec96d315c91ab544c330839ee1c23f3fefdd063cd36fa77dc06a84a566bf30d9f4c2d01075a1471c93ce6275e0319438f013058aeaf3c4029bab24f3bf8b89786992ff03513440d8a61c4a31b76ea14fd96ec010a52ce2aa6212783163532b6bee047d90b000a4ab3faa7466ed5a62402024f62e0f6ea10b5e44341bf1869dc0317091cbc38444c27c4e88f6d9a8f0c85355c341b108537f01e79363e5c27331e031cccec82bb000b56537c736f12f44027c86e16da23af8515535b7839ff9095a93db178450f954f10f7c7ea7b8132f1b75909aa996ea6fb661cc3bbf12624f88c646fe2f964279d000d1edd3f3b34464a2a103ae7b6a2705f385207d4a91d721a175157f9238d0a54dd1127286db3a13ff1df67f02f195b665c09e4301f9df8fcfd251fefba30d12190010e8814c0416af5a6c702fbdee573ea5819a8ec452db5d182fafc37b47c25937e1d6359b17ddedd696056732ae37a80463ce515b85744a5342999599a9bdcc75ea2010f5821c0d3a9887f0f5f1c59e5a7e62d98fa7f4cd737c44ce4d26f3b466ffe5b310fed58f2282d0449de119d8ad12788624e87aee0d5f49d8881eaa14b5f2d653f00117d01a5a41e69dc58ce406c51ba2254128faa522b69d7f8c8a2eeb862858469eb119c119439513a1e068ad8df5214b251c6b4ef74600366935bdb1b72244dc97200128e34e3a83b7382a8f498235a52efea79d0c9a4e1de30340d70b5e9d8013927be137185a5423ae05a743fd4c5d2374de5aba72d86f70b7bfb2eb88ef8df052e79016634f2f500000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa7100000000033d2ada01415557560000000000084728a20000271034997d7ffc8a4495fd78fed48c2bf8d5e188d74e02005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b4300000595cfbc774800000000c3f8e497fffffff8000000006634f2f5000000006634f2f50000058adefc436000000000e212dff80ab660ac1113aacd22a0d1e837a9cbbb4316ccdd64272484102a99c1337c282e56981a68916d29df1d1716b33f63a3b78b8d7b88ab46652879685487e2520aed797adec6550872f99049088ffbde70766eadb20520615efadb40d92afc542d42a113e1ef3c2d2bb920002cfb5b0bb3452b59e5e59585e25964682084851e189cf74861cd010893df90a7718062c4b6e89f5bfa8269d152c6f58be368cc588af6575595bc376b65a0e7f916fc5eef915402a661ccf024bf94f181b8193367251f0d7411aa23094626f7005500c96458d393fe9deb7a7d63a0ac41e2898a67a7750dbd166673279e06c868df0a00000000004bad0f0000000000001559fffffff8000000006634f2f5000000006634f2f500000000004c074200000000000015a00a3f32b0cd92140161520c68b4df848dce5b315f5a67f61563ec3b2fb6b17ab64fe530f438c7f035cb7c204ba80e3c6b8e14fc54f10b8e79af497f7dbf3c225f183f509b2db99ab2fdee7f1a36b699cc6fc1a868ad8b7fbf9a28461133fb45cb7940271678ca5835657a5089335850924b016ef17cc280e4f7582c879140889bbe4a4d39d5160d5b71f7983a53c4b6e89f5bfa8269d152c6f58be368cc588af6575595bc376b65a0e7f916fc5eef915402a661ccf024bf94f181b8193367251f0d7411aa23094626f7

• Contact: nihardangi@ymail.com

2

Hi @nihar29, you cannot just encode arbitrary prices and send them to the contract. The price updates contain numerous signatures to verify it is coming from Pythnet and they cannot be forged.

The wire format lives here.

3

Hi @ali , thanks for replying.

What if I want to send only one price feed to updatePriceFeeds() instead of 2? How should I make changes to the original packet that contains data for 2 price feeds?

4

You can see the detailed breakdown of the hex data here: New chain integration - data format and validation - #4 by benji

5

@nihar29 unfortunately we don’t have any API/SDK to do it automatically. You can make separate requests for them and you can always merge them as onchain update data is an array (albeit it’ll be more expensive). Until we add it in the future if you are ok to write code, this test deserializes an update data and if you see the format, you can simply remove one feed from it.

6

Actually I just realized that we have utilities in our Python SDK that might help you out to parse the update data and later serialize it (see this module and look for accumulator update data). Specifically we have a method that can combine two separate update data (this)