-
Notifications
You must be signed in to change notification settings - Fork 336
feat: add "How compatibility layer works" #3717
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,45 @@ | ||
| --- | ||
| title: How the Pyth Pro Compatibility Layer Works | ||
| description: Understand how Pyth Core consumers can receive Pyth Pro data with no integration changes. | ||
|
Comment on lines
+1
to
+3
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Adding this page at the docs root without updating a Useful? React with 👍 / 👎. |
||
| --- | ||
|
|
||
| The Pyth Pro compatibility layer lets consumers of the Pyth Core contract interface receive Pyth Pro data without changing their integration. The update payload format and the on-chain contract ABI are identical to Core — only the source of the data and the entities that sign it are different. | ||
|
|
||
| ## Architecture Diagram | ||
|
|
||
| ```mermaid | ||
| flowchart LR | ||
| R1[Router 1] --> H[Lazer Hermes] | ||
| R2[Router 2] --> H | ||
| R3[Router 3] --> H | ||
| R4[Router 4] --> H | ||
| R5[Router 5] --> H | ||
| H --> C[Consumer] | ||
| C --> P[Compatibility Contract] | ||
| ``` | ||
|
|
||
| ## Data Flow | ||
|
|
||
| Each tick, routers take the latest aggregated Pyth Pro prices and construct a Merkle tree using the same leaf format Pythnet uses for Pyth Core. Each router signs the Merkle root independently. Lazer Hermes collects roots and price messages from all routers and serves the latest update — the signed root plus per-price Merkle proofs — through the same HTTP and streaming endpoints as Hermes. Consumers fetch the update and submit it to the compatibility contracts, which verify the router signatures meet quorum and then verify each price against the root using its Merkle proof. | ||
|
|
||
| The shape of this flow mirrors Pyth Core. The difference is where the Merkle root comes from and who signs it: on Core, Pythnet produces the root and Wormhole guardians sign it; here, the routers do both. | ||
|
|
||
| ## Components | ||
|
|
||
| ### Routers | ||
|
|
||
| Routers build a Merkle tree over Pyth Pro prices each tick and sign the root. The leaf format matches Pythnet's exactly, which is what makes the resulting update payload byte-compatible with Pyth Core. Five routers, operated independently, each sign the root using the same signature scheme Wormhole guardians use on Core. | ||
|
|
||
| On Pyth Core, Wormhole guardians observe a Merkle root produced on Pythnet and sign it. With the compatibility layer, the routers both produce and sign the root. | ||
|
|
||
| ### Lazer Hermes | ||
|
|
||
| Lazer Hermes exposes the same API as Hermes — the same endpoints and the same response shapes — at a different URL. It collects signed roots and price messages from all five routers and serves the latest update with the signed root and per-price Merkle proofs. Existing Hermes clients work unchanged when pointed at the Lazer Hermes URL. | ||
|
|
||
| ### Compatibility Contracts | ||
|
|
||
| New contracts are deployed at new addresses on the same chains as the existing Pyth Core contracts. They expose the same ABI, so existing integrations work without code changes. The contracts are configured to accept signatures from the five routers with a **3/5** quorum, compared to Core's **13/19** Wormhole guardian quorum. | ||
|
|
||
| ## What This Means for Consumers | ||
|
|
||
| Migrating a Pyth Core integration to Pyth Pro data through the compatibility layer requires two changes: point the client at the Lazer Hermes URL, and use the compatibility contract address in place of the existing Pyth Core contract address. SDK code, payload parsing, and update submission all stay the same. | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🚩 New doc page is not registered in any meta.json navigation manifest
The new file
content/docs/pyth-pro-compatibility-layer.mdxis not listed in the rootcontent/docs/meta.json(which only contains["price-feeds", "express-relay", "entropy", "api-reference"]), nor in any othermeta.json. This means the page won't appear in the sidebar navigation and is only reachable by direct URL. However, the existing top-level standalone docs (security.mdx,whitepaper.mdx) follow the same pattern — they are also absent frommeta.json. Given the content is specifically about Pyth Pro, it could arguably live undercontent/docs/price-feeds/pro/and be registered incontent/docs/price-feeds/pro/meta.json, which would make it discoverable in the Pyth Pro docs sidebar. Worth confirming whether this page is intentionally an orphan or should be navigable.Was this helpful? React with 👍 or 👎 to provide feedback.