|
1 | 1 | # How Pyth Pro works |
2 | 2 |
|
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. |
5 | 5 |
|
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