Skip to content

Commit f23d358

Browse files
committed
requested changes
1 parent 3a73e02 commit f23d358

File tree

1 file changed

+9
-5
lines changed

1 file changed

+9
-5
lines changed

pages/lazer/how-lazer-works.mdx

Lines changed: 9 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -28,9 +28,8 @@ The Relayer service is the ingestion layer that receives and validates all incom
2828

2929
Douro Labs operates the relayer service for the Pyth Lazer network. It follows a strict, deterministic processing model:
3030

31-
- **No price dropping outside of circuit breakers**: All validated updates are forwarded to the message queue without dropping any prices.
31+
- **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).
3232
- **FCFS processing**: Updates are processed on a first-come-first-served basis without prioritization.
33-
- **Deterministic operation**: The relayer operates according to its configured logic and does not deviate from it.
3433

3534
This ensures reliable, predictable data flow from publishers to consumers.
3635

@@ -39,8 +38,9 @@ This ensures reliable, predictable data flow from publishers to consumers.
3938
The system uses a distributed message queue for pub/sub messaging with stream persistence.
4039
This allows the system to be deployed in a multi-datacenter environment and ensures reliable message delivery between services.
4140

42-
**Message ordering**: The message queue guarantees message ordering within a single stream, ensuring that updates from publishers are processed in the order they were received by the Relayer.
43-
This ordering guarantee is critical for maintaining consistent feed state across all aggregators.
41+
**Message ordering**: The message queue ensures reliable delivery and maintains the exact sequence of messages within each data stream.
42+
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.
43+
This sequential processing is essential for keeping all aggregators synchronized with the same feed state.
4444

4545
### Routers
4646

@@ -51,7 +51,7 @@ It embeds aggregation logic to compute median prices, confidence intervals (usin
5151

5252
- **WebSocket streaming**: Provides `/v1/stream` endpoint for real-time price updates
5353
- **HTTP REST API**: Offers `/v1/latest_price` for on-demand price queries
54-
- **Channel types**: Supports real-time and fixed-rate channels (1ms, 50ms, 200ms)
54+
- **Channel types**: Supports real-time and fixed-rate channels (50ms, 200ms)
5555
- **Multi-chain support**: Generates on-chain payloads for Solana, EVM, and other chains
5656

5757
#### Aggregation logic
@@ -63,6 +63,9 @@ Each Router embeds an aggregator component that consumes publisher updates from
6363
- Determines best bid/ask values filtered to ensure market consistency.
6464
- Automatically removes stale publisher data based on configurable timeouts.
6565

66+
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.
67+
This ensures that every Router instance maintains identical feed state, providing consistent data to all consumers regardless of which Router they connect to.
68+
6669
### History Service
6770

6871
The History Service provides persistence and historical data queries.
@@ -71,3 +74,4 @@ The History Service provides persistence and historical data queries.
7174

7275
- Data persistence: Stores all publisher updates, aggregated data, and transactions.
7376
- Historical queries: Provides REST API for querying historical data.
77+
- OHLC API: Provides Open, High, Low, Close (OHLC) data for charting applications through the history service.

0 commit comments

Comments
 (0)