Main Issue: Missing parsePriceFeedUpdatesUnique function Chain: BNB Smart Chain
Have been developing under the assumption the parsePriceFeedUpdatesUnique is a globally used method, however when going to do the final deploy on BNB Mainnet, i realized parsePriceFeedUpdatesUnique is not available on the implementation (0x4D7E825f80bDf85e913E0DD2A2D54927e9dE1594).
Is this an oversight? Wondering whether it’s planning to be added or maybe should be documented that it’s only available on limited chains. Noticed thats it’s also missing from the Polygon implementation.
Thanks for flagging this! I checked the deployed contracts directly and you’re right.
On the current Pyth Core contracts for BNB Smart Chain and Polygon, parsePriceFeedUpdatesUnique(...) is not exposed, while parsePriceFeedUpdates(...) is.
I also checked upgraded Core deployments on other EVM chains, and parsePriceFeedUpdatesUnique(...) is available there. So this is currently a difference between older vs upgraded deployments, not an issue specific to your integration.
For now, on BSC/Polygon you should use parsePriceFeedUpdates(...). We should make the chain/deployment support for parsePriceFeedUpdatesUnique(...) clearer in the docs.
More broadly, Pyth is already migrating the relevant product surface from Pyth Core to Pyth Pro. As reflected in the recent Core→Pro migration messaging on the forum, Core is on the path toward deprecation, so we are not planning to backport this function to the legacy Core deployments on BSC/Polygon. If you are building something new, the recommended path is to migrate to Pyth Pro rather than depend on additional Core contract upgrades. See docs: Pyth Core Upgrade | Pyth Developer Hub
If you have questions about the right migration path or fallback pattern on BSC/Polygon, feel free to reply here.
okay.
The problem with parsePriceFeedUpdatesis that people can submit any price feed data from the hermes API so long as it’s within the minPublishTime and maxPublishTime.
The reason I wanted to use the parsePriceFeedUpdatesUniquewas so that it reverted unless the submitted data was the earliest data from the minPublishTime from the hermes API.
I don’t think there’s any way to guarantee that with the parsePriceFeedUpdatesfunction alone is there? Or even a workaround I can use on chain that will only accept the earliest available data >= minPublishTime?
On the legacy Core contracts that only expose parsePriceFeedUpdates(...), the contract checks that the submitted update is within the [minPublishTime, maxPublishTime] window, but it does not enforce that the update is the earliest one after minPublishTime.
That stricter guarantee is exactly what parsePriceFeedUpdatesUnique(...) adds on the upgraded contracts. Internally, it uses the previous publish time to ensure the returned update is the first one satisfying the lower bound.
So on the older BSC/Polygon Core deployments, there is no equivalent purely on-chain workaround that reproduces that same uniqueness guarantee using parsePriceFeedUpdates(...) alone.
The practical workaround is an off-chain two-step flow:
Query the historical update stream off-chain and find the first update with publishTime >= minPublishTime
Submit that update on-chain and pin the time window tightly — ideally with minPublishTime == maxPublishTime == exactPublishTime
That lets your contract enforce “accept this exact publish time”, but the “find the earliest valid update” step still has to happen off-chain.
More broadly, we are not planning to add parsePriceFeedUpdatesUnique(...) to the legacy Core deployments on BSC/Polygon. Pyth is already migrating the relevant product surface from Pyth Core to Pyth Pro, and Core is on the path toward deprecation. If you are building or migrating now, the recommended path is to move to Pyth Pro rather than depend on further Core contract upgrades — especially since the Core surface you’re relying on is slated to be retired in roughly 45 days.
Okay, pretty disappointing, thats not a reliable solution so the best I have is to reduce the acceptable max window.
Also, i cant see snywhere in the docs that core is being deprecated in favor of pro. Just that the core contracts are being upgraded and that the interfaces/integrations are unchanged, but that an api key is required and the Hermes endpoint changes from july 31.
Are you positive we should be moving to pro instead of using the upgraded core instructions?
The docs are confusing and apparently inconsistent especially in light of what you are saying. At least say in big font on the api reference that relying on this function will break your contracts in 45 days?
Just some feedback for whoever is in charge of docs.
I should say that i appreciate with how helpful you’ve responded here. Although I really wish the implementation was fixed on bsc. It’d save me a tonne of time and I would be happy to help you guys out with anything you might need.