docs(developer-hub): add Migrate from Core guide for Pyth Pro#3595
docs(developer-hub): add Migrate from Core guide for Pyth Pro#3595
Conversation
Technical migration guide covering architecture changes, behavioral differences (confidence calc, aggregation, staleness, timestamps), endpoint changes, and abbreviated EVM/SVM/TypeScript code comparisons with links to full integration guides. Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
|
The latest updates on your projects. Learn more about Vercel for GitHub.
5 Skipped Deployments
|
🤖 llms.txt Content ReviewAnalyzed documentation changes — no updates to curated content required. Products reviewed:
Files analyzed |
![chatgpt-codex-connector[bot]](https://avatars.githubusercontent.com/in/1144995?s=60&v=4){kind=small}
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 3957e805ef
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
|
|
||
| **Update frequency** becomes configurable. Core updates every 400ms (fixed). Pro lets you choose per subscription: `real_time`, `fixed_rate@200ms`, or `fixed_rate@50ms`. | ||
|
|
||
| **On-chain verification** uses a different signature scheme. Core verifies data using **Wormhole VAA** (guardian multi-sig) through the Pyth Receiver contract. Pro uses **Ed25519 signature verification** through the Pyth Lazer verifier contract. |
There was a problem hiding this comment.
This sentence states that Pyth Pro verification uses Ed25519 universally, but that is not true for EVM consumers in this repo: the EVM format is documented as secp256k1 ECDSA and the verifier contract uses ECDSA.tryRecover (apps/developer-hub/src/components/BinaryFormatCards/index.tsx, lazer/contracts/evm/src/PythLazer.sol). As written, Core→Pro EVM migrations can adopt the wrong cryptographic assumptions and implement incompatible verification logic.
Useful? React with 👍 / 👎.
| | ---------------- | ------------------------------------------------------------------- | | ||
| | Streaming | `wss://pyth-lazer-{0,1,2}.dourolabs.app/v1/stream` | | ||
| | REST (latest) | `POST https://pyth-lazer.dourolabs.app/v1/latest_price` | | ||
| | REST (historical)| `GET https://history.pyth-lazer.dourolabs.app/{channel}/history` | |
There was a problem hiding this comment.
The migration table points historical requests to history.pyth-lazer.dourolabs.app, but the existing Pro docs consistently define the History API base URL as https://pyth.dourolabs.app/v1 (see content/docs/price-feeds/pro/api/index.mdx, api/history.mdx, and faq.mdx). This inconsistency can send migrators to an undocumented host/path and break integrations if that alias is unavailable.
Useful? React with 👍 / 👎.
![devin-ai-integration[bot]](https://avatars.githubusercontent.com/in/811515?s=60&v=4){kind=small}
| **Data delivery** remains similar. With Core, you fetch price updates from **Hermes** (an off-chain relay for Pythnet data) and submit them on-chain in the same transaction. | ||
| With Pro, prices stream directly from publishers via WebSocket. On-demand queries are also available via REST. | ||
|
|
||
| **Update frequency** becomes configurable. Core updates every 400ms (fixed). Pro lets you choose per subscription: `real_time`, `fixed_rate@50`, `fixed_rate@200ms` or `fixed_rate@1000ms`. |
There was a problem hiding this comment.
🟡 Incorrect channel name fixed_rate@50 is missing the ms suffix
Line 34 lists the channel name as fixed_rate@50 instead of fixed_rate@50ms. Every other reference in the repository — including within this same file at lines 208 and 237, as well as api/rest.mdx:30, subscribe-to-prices.mdx:84, and payload-reference.mdx:324 — consistently uses fixed_rate@50ms. A developer copying this channel name from the Architecture Changes section would use an invalid channel value that won't match any supported subscription channel.
| **Update frequency** becomes configurable. Core updates every 400ms (fixed). Pro lets you choose per subscription: `real_time`, `fixed_rate@50`, `fixed_rate@200ms` or `fixed_rate@1000ms`. | |
| **Update frequency** becomes configurable. Core updates every 400ms (fixed). Pro lets you choose per subscription: `real_time`, `fixed_rate@50ms`, `fixed_rate@200ms` or `fixed_rate@1000ms`. |
Was this helpful? React with 👍 or 👎 to provide feedback.
| Before diving into what changes, here's what doesn't: | ||
|
|
||
| - **Same data quality** — first-party publisher data from 120+ sources including major exchanges and market makers | ||
| - **Same data fields** — price, confidence interval, exponent, and timestamp are available in both Core and Pro |
There was a problem hiding this comment.
Pro doesn't have "confidence interval" like core
|
|
||
| **Update frequency** becomes configurable. Core updates every 400ms (fixed). Pro lets you choose per subscription: `real_time`, `fixed_rate@50`, `fixed_rate@200ms` or `fixed_rate@1000ms`. | ||
|
|
||
| **On-chain verification** uses a different signature scheme. Core verifies data using **Wormhole VAA** (guardian multi-sig) through the Pyth Receiver contract. Pro uses **Ed25519 signature verification** through the Pyth Lazer verifier contract. |
There was a problem hiding this comment.
i'd also mention there is no push model in Pro for on-chain verification, only pull
| <Callout type="warning"> | ||
| Pyth Pro EVM contracts don't store the prices on-chain. The prices are parsed from the payload and verified on-chain. | ||
| That's why Pyth Pro does **not** revert on stale prices. You must check `feedUpdateTimestamp` | ||
| yourself to determine whether a price is fresh or carried forward. See | ||
| [Payload Reference — Price Availability | ||
| Semantics](/price-feeds/pro/payload-reference#core-price-properties) for | ||
| details. | ||
| </Callout> |
There was a problem hiding this comment.
said another way - there is no push model in Pro for on-chain verification, only pull model. (from what i've seen, people are familiar with this verbiage.)
| <Callout type="warning"> | ||
| Connect to **all three** WebSocket endpoints (`pyth-lazer-0`, `pyth-lazer-1`, | ||
| `pyth-lazer-2`) for redundancy. Individual endpoints go down briefly during | ||
| deployments. | ||
| </Callout> |
There was a problem hiding this comment.
I'd mention that this is automatically handled by our TS SDK
2 participants
Summary
content/docs/price-feeds/pro/migrate-from-core.mdx— a technical migration guide for developers moving from Pyth Core to Pyth Prometa.jsonto include the page in the How-To Guides nav sectionTest plan
pnpm dev🤖 Generated with Claude Code