Error price feed: Gaps in public price feed

Price Feeds
1

‘https://hermes.pyth.network/v2/updates/price/stream?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43’

• :link: Chain (e.g. Ethereum mainnet, Solana devnet, etc.)
Solana Mainnet

• :stopwatch: Timestamp of the issue (block time or UTC)
Gaps in data so we log and track all data. this is how much gaps we get and it gets worse with time.

2025-06-04T10:07:42Z
1749031662

2025-06-04T10:07:43Z
1749031663

2025-06-04T10:12:50Z
1749031970

2025-06-04T10:12:51Z
1749031971

2025-06-04T10:21:54Z
1749032514

2025-06-04T10:34:01Z
1749033241

2025-06-04T10:34:50Z
1749033290

2025-06-04T10:45:22Z
1749033922

2025-06-04T10:47:23Z
1749034043

2025-06-04T10:06:06Z
1749031566

2025-06-04T10:09:18Z
1749031758

2025-06-04T10:13:18Z
1749031998

2025-06-04T10:17:19Z
1749032239

2025-06-04T10:21:51Z
1749032511

2025-06-04T10:34:27Z
1749033267

2025-06-04T10:44:18Z
1749033858

2025-06-04T10:47:24Z
1749034044

2025-06-04T10:47:49
1749034069

2025-06-04T10:47:50Z
1749034070

Example for the streaming one that kept breaking down:

curl -X ‘GET’
‘https://hermes.pyth.network/v2/updates/price/stream?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43’
-H ‘accept: application/json’ --http1.1
data:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d00760e4a25bf5f623f3386cba8f6a49e3c5928a025de9546d08e3e14493a1dc4072e88b01a52e8d86b5488991ee552e14889c9e15b89b1920741dd2861ac83a27301033740fdcb27395f695a65518fa598103153fa89dc645b63eebe934230209203ed59b47edd864559ea828e74533ee89badb7fe37ad33b96f37f1b1bed627cd78f6010475036ef9b293dd9e534e2dd375cc03f2fd95dd31fbdf3d4949257d650b7020086405cee9e9c0b16cda66acc4b15fef3bb0b45f459aeb790530a39df56f0a23fd0106924db4e607d82c45a465c5f3653573ab43c5f44e9b469aa9911710988e0154183c4f6e70df5dc8d43996377a216317aef46e8cf2368178f94b7002ef595824be0008b8a528ea9f92f1dec6810333354b06f9a44fbb10eeed8dc2bc0f518429e018ed5aff41e60faca0a3df98b62439f3f56266a6c85b010d0cb8c74a9d6e452602e9010a9b2d5473df63c5eaebc8c1073002158428cee5ac9801d30b528a85e5ee379afe13ff8cbd95951b33fe03df5eba25c3a04ba620c1197a38afd897752ed1d6b78d010b74b42c350dc4c9f669b98115de621807e3996f4912cea42da49216f3ce8e2f11376ef94f74132cc28c3fd1831fac354f339c24e92c9482591731a2dc50b2477e010d197e99d27de64896d6b27ed8bd16a308a6507e0c12c97b4fa76850fdab1c1a28483d59921042b2242e92776f694f35597ce8a233f6c5e607ce2d01bc010102c6000ee6de48023ebdab7a3fec5dc7e8a9dafb4b0e416cca81708a6dad1db3679f28ab5fdd1205435439f4c00d9b35d9ca247664175d71a9049e59a77c054b976754d6010f96454eb53f4de6db8b5997c339b1090d5d7ef4b6dc0a9470d74ed1cc54412dd5144d708a8b03013225c57512abc3dd0d8ebdb7cb377a09d640282669560b86b100100c5f23cb9c8047c75ac3217e952cbc75af66650fe62c6d0f6b422160ffa5b2a2259194f3f0e1879998168cf552fd398beedba9c190f501f24f02aa8bf40970c60011ea5a3740d9b7b0bf54fd5debce6b7c4ababe40c5c6bb351de97b77fcdea297aa6705b616908074a3680206eb46272e9211dd433a42b0421a34c5dcbf9df8e2b501126121106c8aa1f6b25aba95f4dc8ed0a3964760b1d542f56e37dce1781ec425d418927c150e26a975c058b33f8c1af8fbe22b24e23c5da22655ca3ebf142a21ce016841e74200000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d902014155575600000000000d345aaa000027102cc52522bf49430ad67780c7ebeadcdb013d35f401005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43000009620bd8c2bf0000000124a62711fffffff8000000006841e742000000006841e741000009665b3f76c000000001006ef4500c944d5e62d2e0dec821cb3523b2a9e7b9492dad4d6626dc08f99788dfcea56c58d9559bd6f796e38b837231abd868a14ab9a7473b7c68cc289202057206ad4ed2a6650169b808cd0217f0b46ad7a2159d5f514a3342f8987e153265d9cda2a23897907e9813e028ebbefb49de4a04590da653a58b7c1d242a2f1da520b2c872950a8db588dfdad8a17d89e5e8dcfaa5b9b725137ffeaaecdbf7ff617560beaec6c79714ca72bc4ccb67593ad04b71a151b4da527c361cb9cca22559405595fe9b1cd147b14e1d1433648126dba1df1a062b9b29857957a12c33a51200a5806d6cee404f650789310f46d5f07ee15a3658”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316710199999”,“conf”:“4909836049”,“expo”:-8,“publish_time”:1749149506},“ema_price”:{“price”:“10335222200000”,“conf”:“4302238800”,“expo”:-8,“publish_time”:1749149506},“metadata”:{“slot”:221534890,“proof_available_time”:1749149507,“prev_publish_time”:1749149505}}]}

data:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d001dc9c51d9f0317c7c74d34b74cc6eda6f4158ed719881410d8524f8c793d9dc57277efd5080764da7a558097e17015706b126514befeef544c48c29a5dce43f00002bb28b3dcada54ec8d2aaac0a7ef557c3e895143003163ec2ac935a22bacac2f65b75acdd0470e2f7cdae807cfc614ddf61e732af192725ca313d0a4b7421ef3f0003560cfc8c3583f99cee1dcfcf414d0ecd0ac863b09dd66f67a1b1ec420e2fe8936b28628837f5e8f1d845b1311a9ca70011173cdea58fc4f093f640c5437a340100041c5cc17559b6a2ab29202a6bf902ec1f731195892303a3f26b825055d682a617222e4a28a14f395ab304dc4a5b63516808b3eb060004b69f4fd8dc1af8c8c47800064f8609b4af9ecd62b90af4f7c79db18e73a20d86a38912763a0a0f693ee872655baa6017da10a2d82ca1576ccd93976f14938f74f8322745763b806ff2f4845601088877f2ebf7a92efad7f458eca8db5c3d07fc7585fe37b52d0f5243460c7058207f5a07aaaad9a84938d80c0cc5615a75b925786e3c81525ba4e5c214c056e1cc000a98e5c795727915c025c8d03f633d0684e36c231552c5b3217848f128fec91baa370900a7240fda2fd818c9eb71016e5b8349086eed7429aa333e35677fd5628c000bf094d0ae614df5e8d253cf3db41e1d2728a95e9282f8c9e61a05d0a03d899b3b1fc025cee6e04df4a1609d9bbda0da28116b73d9c6daaef9ee8d38bc252db96d010d1836c4591d42683b7bfcbeab7895d37732b5128b6f20f2bfe06db8b3fe78ad2829d3ef3d835dd3f8225d7be47144a62b38ff90e3fb78419bb914b7a38660b506010e2c6e4d868a0970a52da73e614165b321bf6f191cc4c209e9488807a00eec36dc2fefb04efda9e83216e8537b091ccaa94624009391563a023bcfb7f9640cb048000f8d72884e7cfbcf969b3739225510c3b6a925ec8ad0a3d5271fd1a3ddfb4ce69c5f2f6828e3669a0daf4781600409085acba17ece75c40ca302eb995dddce071101104297798fd9e64d26da2cb904b74df77aea8464ac3b9847f3d59a97ad34a43546456849cd6e2e9f392251c37fab73c6913e90060490b9590011861e1029963d190111b0523875a4f516380d6ec7dbb37462c286354f7f53a560c06ff421db26ceb28e6da8cb8b2187d55ce24ab7e0638cc95f26fde3bf9068dadfc8cc9531eb6942c5006841e74200000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d903014155575600000000000d345aab000027109a8197e552dd636a3002f9cfdc902cb8789c95ef01005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43000009620bc130ce000000013c327290fffffff8000000006841e742000000006841e742000009665b25862000000001007067cc0c1e0308ac3b12f3b2a8e27c41885d3cf84ef19e4003ade8d6f3d5913c7cbdb080480a26757e59849cb5894c136572792202abc5cfd38eb8d6f1d95151e813597c9e22b12ec34176c3d45dafa7830b5a8ef10840a48fbc45a7a105f693b81e568eab892a5e3f4bd79e4f0a5bfb500046235034ddecde050a3e13de3e484f408a17999c04c5a823f2835ae56beab10f120fa70fcf1cf68735d1e3d4d32456081f631251558317376a29105b4729b0bc6b300ac7c73b4181efea4969228cdb7992825a1c90f1d096a566fba497abdd890307b7edfa8b1a14164e47999fde88fac5a0aa536f41b98f0a31bd3a9bbdc9eab48d”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316708655310”,“conf”:“5304906384”,“expo”:-8,“publish_time”:1749149506},“ema_price”:{“price”:“10335220500000”,“conf”:“4302333900”,“expo”:-8,“publish_time”:1749149506},“metadata”:{“slot”:221534891,“proof_available_time”:1749149507,“prev_publish_time”:1749149506}}]}

data:{“binary”:{“encoding”:“hex”,“data”:[“504e41550100000003b801000000040d007afc5e654db32909e1a9ab09e64c9927f4985b86a8de9ef4dc6cc22e38d48bcc70ab92cd1aac2f1afd4d335b25cb9bb28a9e1f573bfa667b0bba7885b16f25c60102e0aebbb6d3b06ed493c5b57d95e3437d4446053775e2e2c6918d3a9b521c0e9332989327ab83c1f462bcdee8bdf69620c6270bcbc6523cf167943e217198064101030929d1cf757e64ffa2bb13a12cc648c1d035f36bdb2af3143f1fc55b65b4cd392655cacf65a8c7255e56dee6970b76aacf857d84dd8c6872695959f5b625681e0004a11cb3ac16db430eb50c8af8d177a9208c4d113a5090a800ad6b3ce6f984c03241bb940d97c9dfb7ea76e5fd337628f0c6db1cb005f5641ab977d7e314df6933010647f567cc030b0ec7bac854c73d3f039bd35849ff07ec2ee3b2641f2d605317110f51d27e5317df09b4589c1dcbe203cdbddc2a0c24b20e4b3b39494fc815b4640008373c65d2d4c72b47f908e4a457dd2d8e4fd33f4cd59c304f33ae806736acceb251e63a7622ce73282da15840bad610f378d4aec5baa000fb75aaa8e2fd122770000af8d99184394912fdd6aad7513137fb4dabeb84fd214ea83d3300347feabe998b6380f8250d6805c6fb0408c400d6ed595e40df112bc6fe898c64273a391612ac010b2db12a76c0caf5865989a70af60028184283789b024c263fa6dd3810325eae973db5094c621f985b8ad2c3b108c7b69d195fab8584bb875f4007e776c7354bb0000dd7d0e045584f0017de2fa4426f030c285ba7782cdffe570f31b2fd3ad6e7bbb01b0cf41c8e270b55253693d12c648ac3780d6d1004e08fce7d17ee349947a1b3000ec2502b45ee72c0dcb122150b222bf145d0e0d36a7fe4e7668bc90a2a391836d040d5e5563d73751bcb258845e3114384bd44c1fc965f34027551d5877b5af499000f91a92aaedbb7c0d2d41f3ef13d85792dbad06c1a15ebe4148d7d9eb7fa875ff5677139e55c8a34f72f1c1b03ecd05f9fbc783eb5bc2b1c8fee719f1dd108509d001074836c1fac49e3151e2ac5e320be7ca5985edc0a4b9f9bb191242636d1be77bb7467d0be8b1f892b91320cadcb4aa1f009ebe6163007de39749db166c566d8f60011cdd5e801ea672fe43ada7a8e8c30973c3dd1123296a84feabd85b6233e9f728f7528b11eaf045792f1730a31e3159a1c1a5c6245abd079d10f3a61310e4fc568016841e74300000000001ae101faedac5851e32b9b23b5f9411a8c2bac4aae3ed4dd7b811dd1a72ea4aa71000000000826d904014155575600000000000d345aac0000271063036a46ca40542b4037d842b5152c760c1c152901005500e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b4300000961fcc34605000000012d3487c7fffffff8000000006841e743000000006841e742000009665b0888400000000100718bfc0cb9593def04dda130fa85b133f427f158d2fcaf25018abb60aa1fee6cee8402b86e5a837695197d52b8c408832ecafcecefc20fdf86e2e9ec9a631f36d350733d2bf45792788b851a3ad7daa859e2946501ca29f4440596cc16018758c50708174faeca9db33397b4bbb88ce32af3f8e3e545c100d715baa5e4025ad060a35ec9b5d524e45dca71926f3e2dc5e682b551b81384aeb7539370fd8d6b4fbfed1a843f3b7c9cc3c13c53ded518e90f07f55f0e78ea4a4df8ba20616199cc57145f7bc29e37ab87f7fae60b19cf588c222839428ac94e732f3d8b33c525d259de84946daba31b76b43ec4714b15cf4e7d39ce”]},“parsed”:[{“id”:“e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43”,“price”:{“price”:“10316457133573”,“conf”:“5053384647”,“expo”:-8,“publish_time”:1749149507},“ema_price”:{“price”:“10335218600000”,“conf”:“4302408700”,“expo”:-8,“publish_time”:1749149507},“metadata”:{“slot”:221534892,“proof_available_time”:1749149508,“prev_publish_time”:1749149506}}]}

curl: (18) transfer closed with outstanding read data remaining

• Name of the dApp/Project that you are building
Prefer not say. It not a good image of having a broken app due to Data price feed.

• Contact (Telegram/Email/Discord)
@unicornDegen

The more context you provide, the faster we can help.

So we meet the team in Lisabon. We have an app that scalling. The gap in the price feed keeps returning 0 as price. So as a trading app if the data comes back as 0, that means is an error and incorrect.
In the app user places bets, betting on the price of what will be solana , app track the price and when it come time to settle we get 0 , and it comes that the user has lost. but they haven’t.

2

gm thank you for your question!

Will try to get back to you as soon as possible

And also we’ll try to backfill the data gaps if possible. Would you be okay if I provide you with a csv of the missing data?

3

the history is not the problem. I have 200 User daily waiting to onboard and I can’t if I have don’t certainty that there wont be gaps, or gaps will be filled with 5min timeframe of appearing.

the list of data I gaps I gave an example from above.

4

do you mind reaching out to @mariopyth on telegram?

would like to learn more about your usecase.

5

Hi @chrisbuildthis,

These gaps happen when the validators don’t reach consensus on that specified time (due to one validator being down/having issues) and while they are rare they are plausible. Please note that in these cases, for instance if a price is missing at time 1749031662, you can use the first price after 1749031664 in this case as the unique price at that time on-chain using this method and fetching it via Hermes using this endpoint will give you that data.

As a meta comment, this happens due to the Solana consensus designs which Pythnet is based on that a validator becomes the leader for 1.6 seconds and if they are down, no block is produced. We totally understand that this not good andare working on improving the reliability of every single validator and changing this behaviour in the network.

1 Like
6

OK so that is a 2min gap.
The question it still not clear if the gap is always there ?

or do i need to search for the next timestamp that return me a data ?

7

Already speaking to everyone in the same TG group. they suggested to post here for better awareness.

8

@chrisbuildthis

It’s a 2 second gap.

No it is not clear or deterministic. If all validators are healthy there’d be no gap. This happens if there is an issue with a validator (like a network issue/…) which is not predictable.

The API I shared looks forwards to give you the first price update after the asked timestamp. if you subscribe to prices you can enable the verbose flag and you always get prev_publish_time and you can assume that the update is valid between the previous publish time and the current publish time.

9

Hi @ali , just want to confirm about this, https://hermes.pyth.network/v2/updates/price/1749031662?ids[]=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43

For this absent timestamp (1749031662), this kind of request seems like to return the nearest price in the up coming seconds. Is it true that this behavior is always valid? Let’s say T+0 to T+9 are all absent and there’s a price at T+10, when i pass T+0 to hermes endpoint, Will it return a T+10 price and publish_time?

10

In case I can not get the answer, sorry to ping moderators here @KemarTiti @Aditya520 .

11

Hey @whsia — yes, you’ve got it right.

The /v2/updates/price/{timestamp} endpoint will return the first available price update with publish_time >= requested_timestamp. So in your example:

• Request: T+0
• If T+0 through T+9 have no data and T+10 does → you get the T+10 price
• The response’s publish_time field will be T+10, so you always know the actual timestamp of the returned data

This is intentional — ensures you can always retrieve a valid, verifiable price for settlement even during gaps.

For streaming use cases, Ali mentioned using the verbose flag to get prev_publish_time — you can then assume the price is valid for the entire window between prev_publish_time and publish_time.

Let me know if you need anything else!

12

@KemarTiti thanks for the reply. I have two more questions:

  1. I’m try to do some on chain calculation based on past few seconds. For example, I want some price points at past 30 seconds. I knew I could call benchmarks endpoint to easily get the prices at certain times in 1 request (/v1/updates/price/{timestamp}/{interval) and multiple calls by using hermes endpoint (/v2/updates/price/{publish_time}).

    Do you know if there’s any delay between benchmarks endpoint and hermes endpoint? like which is reliable for quickly retrieving some prices from past few seconds? or both are solid endpoints to achieve my goal.

  2. Is it true that the response data array length will always be 1 if i only give one priceId to hermes endpoint (/v2/updates/price/{publish_time})

13
  1. Benchmarks vs Hermes for recent prices

For your use case (past 30 seconds), Hermes (/v2/updates/price/{publish_time}) is ideal:

• Hermes = real-time source of truth, optimized for recent data — but only caches ~10 minutes of history
• Benchmarks = historical archive, covers older data but may have a small indexing delay (seconds to a minute) for very recent updates

So for “past 30 seconds” → Hermes is your best bet. For anything older than ~10 min → Benchmarks is required.

If you need multiple timestamps in quick succession, you could also stream via /v2/updates/price/stream with parsed=true and cache the last N seconds locally — avoids multiple round-trips.

For on-chain settlement you’ll need Hermes anyway since it returns the signed VAA.

  1. Response array length

Yes — the parsed array will contain exactly one element per priceId you request. One priceId = one element in the response.

1 Like
14 
  1. https://hermes.pyth.network/v2/updates/price/1774301950?ids%5B%5D=e62df6c8b4a85fe1a67db44dc12de5db330f7ac66b72dc658afedf0f4a415b43

    You said the hermes endpoint only caches around 10 minutes. However, I still can get the result more than 10 minutes ago like the above url. Is it just not reliable for retrieving historical prices to feed into contract’sparsePriceFeedUpdates?

15

It is not a perfect number/science shared but empirically what has been seen.
Have you tried for 20min ? 60min?
But overall, if you get a cached price from Hermes or benchmarks they are safe to use

1 Like