From 3087d7d20b5f594220a15be79acd5b5cf9e58a41 Mon Sep 17 00:00:00 2001 From: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Date: Tue, 28 Oct 2025 17:36:30 +0000 Subject: [PATCH] Move Lazer documentation to Pro section and remove lazer folder - Replaced placeholder content in /price-feeds/pro/how-lazer-works.mdx with detailed technical documentation from /lazer/how-lazer-works.mdx - Updated all references from 'Pyth Lazer' to 'Pyth Pro' to align with product rebrand - Removed /pages/lazer folder as content has been migrated - Existing redirects in next.config.js will handle any legacy /lazer/* URLs Co-Authored-By: aditya@dourolabs.xyz --- pages/lazer/how-lazer-works.mdx | 75 ----------------------- pages/price-feeds/pro/how-lazer-works.mdx | 75 ++++++++++++++++++++++- 2 files changed, 72 insertions(+), 78 deletions(-) delete mode 100644 pages/lazer/how-lazer-works.mdx diff --git a/pages/lazer/how-lazer-works.mdx b/pages/lazer/how-lazer-works.mdx deleted file mode 100644 index e0d12ace..00000000 --- a/pages/lazer/how-lazer-works.mdx +++ /dev/null @@ -1,75 +0,0 @@ -# How Pyth Lazer works - -Pyth Lazer is a permissioned service that provides ultra-low-latency market data to consumers. -It aggregates data from multiple publishers and distributes it to consumers through a multi-tier architecture. - -## System Services - -The architecture consists of five main types of services that work together to provide ultra-low-latency data to consumers. -Each service has multiple instances running to ensure high availability and low latency. - -### Publishers - -Publishers are the entities that provide market data to Lazer. They submit updates via authenticated WebSocket connections. -Each publisher is configured with specific permissions defining which feeds they can update. - -### Relayers - -The Relayer service is the ingestion layer that receives and validates all incoming updates from publishers. - -**Key responsibilities:** - -- **Authentication**: Validates publisher access tokens and optional Ed25519 signatures. -- **Validation**: Performs sanity checks on incoming updates by examining feed IDs, timestamps, and values to ensure data integrity and proper formatting. -- **Rate limiting**: Enforces configurable limits on publisher updates. -- **Message forwarding**: Publishes validated updates to an internal message queue. - -Douro Labs operates the relayer service for the Pyth Lazer network. It follows a strict, deterministic processing model: - -- **No price dropping outside of circuit breakers**: All validated updates are forwarded to the message queue without dropping any prices (except for when a circuit breaker is triggered). -- **FCFS processing**: Updates are processed on a first-come-first-served basis without prioritization. - -This ensures reliable, predictable data flow from publishers to consumers. - -### Message Queue - -The system uses a distributed message queue for pub/sub messaging with stream persistence. -This allows the system to be deployed in a multi-datacenter environment and ensures reliable message delivery between services. - -**Message ordering**: The message queue ensures reliable delivery and maintains the exact sequence of messages within each data stream. -This means every publisher update will be delivered at least once, and messages will be processed in the same order they arrived at the Relayer. -This sequential processing is essential for keeping all aggregators synchronized with the same feed state. - -### Routers - -The Router is the real-time distribution layer that serves data to consumers. -It embeds aggregation logic to compute median prices, confidence intervals (using interquartile range), and best bid/ask prices, funding rates, and more from multiple publisher inputs. - -**Key features:** - -- **WebSocket streaming**: Provides `/v1/stream` endpoint for real-time price updates -- **HTTP REST API**: Offers `/v1/latest_price` for on-demand price queries -- **Channel types**: Supports real-time and fixed-rate channels (50ms, 200ms, 1s) -- **Multi-chain support**: Generates on-chain payloads for Solana, EVM, and other chains - -#### Aggregation logic - -Each Router embeds an aggregator component that consumes publisher updates from the Message Queue and computes aggregated data feeds. The aggregator: - -- Computes median values resistant to outlier data from individual publishers. -- Calculates confidence intervals using interquartile range to measure data spread. -- Determines best bid/ask values filtered to ensure market consistency. -- Automatically removes stale publisher data based on configurable timeouts. - -Lazer guarantees deterministic aggregation: all aggregators produce the exact same aggregated results by relying solely on the consistent stream of price updates from the Message Queue. -This ensures that every Router instance maintains identical feed state, providing consistent data to all consumers regardless of which Router they connect to. - -### History Service - -The History Service provides persistence and historical data queries. - -**Key responsibilities:** - -- Data persistence: Stores all publisher updates, aggregated data, and transactions. -- Historical queries: Provides REST API for querying historical data. -- OHLC API: Provides Open, High, Low, Close (OHLC) data for charting applications through the history service. diff --git a/pages/price-feeds/pro/how-lazer-works.mdx b/pages/price-feeds/pro/how-lazer-works.mdx index ff350c14..9531ecd4 100644 --- a/pages/price-feeds/pro/how-lazer-works.mdx +++ b/pages/price-feeds/pro/how-lazer-works.mdx @@ -1,6 +1,75 @@ # How Pyth Pro works -Pyth Pro uses the same infrastructure as Pyth Lazer. -It is a permissioned service that provides ultra-low-latency price and market data to highly latency-sensitive users. +Pyth Pro is a permissioned service that provides ultra-low-latency market data to consumers. +It aggregates data from multiple publishers and distributes it to consumers through a multi-tier architecture. -We are working on writing a detailed technical overview how Pyth Pro infrastructure works. Details will be added here as they are completed. +## System Services + +The architecture consists of five main types of services that work together to provide ultra-low-latency data to consumers. +Each service has multiple instances running to ensure high availability and low latency. + +### Publishers + +Publishers are the entities that provide market data to Pro. They submit updates via authenticated WebSocket connections. +Each publisher is configured with specific permissions defining which feeds they can update. + +### Relayers + +The Relayer service is the ingestion layer that receives and validates all incoming updates from publishers. + +**Key responsibilities:** + +- **Authentication**: Validates publisher access tokens and optional Ed25519 signatures. +- **Validation**: Performs sanity checks on incoming updates by examining feed IDs, timestamps, and values to ensure data integrity and proper formatting. +- **Rate limiting**: Enforces configurable limits on publisher updates. +- **Message forwarding**: Publishes validated updates to an internal message queue. + +Douro Labs operates the relayer service for the Pyth Pro network. It follows a strict, deterministic processing model: + +- **No price dropping outside of circuit breakers**: All validated updates are forwarded to the message queue without dropping any prices (except for when a circuit breaker is triggered). +- **FCFS processing**: Updates are processed on a first-come-first-served basis without prioritization. + +This ensures reliable, predictable data flow from publishers to consumers. + +### Message Queue + +The system uses a distributed message queue for pub/sub messaging with stream persistence. +This allows the system to be deployed in a multi-datacenter environment and ensures reliable message delivery between services. + +**Message ordering**: The message queue ensures reliable delivery and maintains the exact sequence of messages within each data stream. +This means every publisher update will be delivered at least once, and messages will be processed in the same order they arrived at the Relayer. +This sequential processing is essential for keeping all aggregators synchronized with the same feed state. + +### Routers + +The Router is the real-time distribution layer that serves data to consumers. +It embeds aggregation logic to compute median prices, confidence intervals (using interquartile range), and best bid/ask prices, funding rates, and more from multiple publisher inputs. + +**Key features:** + +- **WebSocket streaming**: Provides `/v1/stream` endpoint for real-time price updates +- **HTTP REST API**: Offers `/v1/latest_price` for on-demand price queries +- **Channel types**: Supports real-time and fixed-rate channels (50ms, 200ms, 1s) +- **Multi-chain support**: Generates on-chain payloads for Solana, EVM, and other chains + +#### Aggregation logic + +Each Router embeds an aggregator component that consumes publisher updates from the Message Queue and computes aggregated data feeds. The aggregator: + +- Computes median values resistant to outlier data from individual publishers. +- Calculates confidence intervals using interquartile range to measure data spread. +- Determines best bid/ask values filtered to ensure market consistency. +- Automatically removes stale publisher data based on configurable timeouts. + +Pro guarantees deterministic aggregation: all aggregators produce the exact same aggregated results by relying solely on the consistent stream of price updates from the Message Queue. +This ensures that every Router instance maintains identical feed state, providing consistent data to all consumers regardless of which Router they connect to. + +### History Service + +The History Service provides persistence and historical data queries. + +**Key responsibilities:** + +- Data persistence: Stores all publisher updates, aggregated data, and transactions. +- Historical queries: Provides REST API for querying historical data. +- OHLC API: Provides Open, High, Low, Close (OHLC) data for charting applications through the history service.