Skip to content

Commit 344cd91

Browse files
devin-ai-integration[bot]aditya@dourolabs.xyz
authored andcommitted
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: [email protected] <[email protected]>
1 parent 79f126d commit 344cd91

File tree

2 files changed

+72
-78
lines changed

2 files changed

+72
-78
lines changed

pages/lazer/how-lazer-works.mdx

Lines changed: 0 additions & 75 deletions
This file was deleted.
Lines changed: 72 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -1,6 +1,75 @@
11
# How Pyth Pro works
22

3-
Pyth Pro uses the same infrastructure as Pyth Lazer.
4-
It is a permissioned service that provides ultra-low-latency price and market data to highly latency-sensitive users.
3+
Pyth Pro is a permissioned service that provides ultra-low-latency market data to consumers.
4+
It aggregates data from multiple publishers and distributes it to consumers through a multi-tier architecture.
55

6-
We are working on writing a detailed technical overview how Pyth Pro infrastructure works. Details will be added here as they are completed.
6+
## System Services
7+
8+
The architecture consists of five main types of services that work together to provide ultra-low-latency data to consumers.
9+
Each service has multiple instances running to ensure high availability and low latency.
10+
11+
### Publishers
12+
13+
Publishers are the entities that provide market data to Pro. They submit updates via authenticated WebSocket connections.
14+
Each publisher is configured with specific permissions defining which feeds they can update.
15+
16+
### Relayers
17+
18+
The Relayer service is the ingestion layer that receives and validates all incoming updates from publishers.
19+
20+
**Key responsibilities:**
21+
22+
- **Authentication**: Validates publisher access tokens and optional Ed25519 signatures.
23+
- **Validation**: Performs sanity checks on incoming updates by examining feed IDs, timestamps, and values to ensure data integrity and proper formatting.
24+
- **Rate limiting**: Enforces configurable limits on publisher updates.
25+
- **Message forwarding**: Publishes validated updates to an internal message queue.
26+
27+
Douro Labs operates the relayer service for the Pyth Pro network. It follows a strict, deterministic processing model:
28+
29+
- **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).
30+
- **FCFS processing**: Updates are processed on a first-come-first-served basis without prioritization.
31+
32+
This ensures reliable, predictable data flow from publishers to consumers.
33+
34+
### Message Queue
35+
36+
The system uses a distributed message queue for pub/sub messaging with stream persistence.
37+
This allows the system to be deployed in a multi-datacenter environment and ensures reliable message delivery between services.
38+
39+
**Message ordering**: The message queue ensures reliable delivery and maintains the exact sequence of messages within each data stream.
40+
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.
41+
This sequential processing is essential for keeping all aggregators synchronized with the same feed state.
42+
43+
### Routers
44+
45+
The Router is the real-time distribution layer that serves data to consumers.
46+
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.
47+
48+
**Key features:**
49+
50+
- **WebSocket streaming**: Provides `/v1/stream` endpoint for real-time price updates
51+
- **HTTP REST API**: Offers `/v1/latest_price` for on-demand price queries
52+
- **Channel types**: Supports real-time and fixed-rate channels (50ms, 200ms, 1s)
53+
- **Multi-chain support**: Generates on-chain payloads for Solana, EVM, and other chains
54+
55+
#### Aggregation logic
56+
57+
Each Router embeds an aggregator component that consumes publisher updates from the Message Queue and computes aggregated data feeds. The aggregator:
58+
59+
- Computes median values resistant to outlier data from individual publishers.
60+
- Calculates confidence intervals using interquartile range to measure data spread.
61+
- Determines best bid/ask values filtered to ensure market consistency.
62+
- Automatically removes stale publisher data based on configurable timeouts.
63+
64+
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.
65+
This ensures that every Router instance maintains identical feed state, providing consistent data to all consumers regardless of which Router they connect to.
66+
67+
### History Service
68+
69+
The History Service provides persistence and historical data queries.
70+
71+
**Key responsibilities:**
72+
73+
- Data persistence: Stores all publisher updates, aggregated data, and transactions.
74+
- Historical queries: Provides REST API for querying historical data.
75+
- OHLC API: Provides Open, High, Low, Close (OHLC) data for charting applications through the history service.

0 commit comments

Comments
 (0)