Scenario
Block propagation and regional arrival lag.
Endpoint A subscribes with Yellowstone/Geyser Subscribe blocks over gRPC; endpoint B subscribes with Solana blockSubscribe over WebSocket. Datasets from all regions are merged by number + hash to detect the leader and followers for each block.
Of the possible 31 regions, 31 were selected for data collection: Oregon, N. California, Mexico, Columbus, OH, N. Virginia, Montreal, São Paulo, Ireland, Zaragoza, London, Paris, Frankfurt, Zurich, Milan, Stockholm, Cape Town, Tel Aviv, Dubai, Mumbai, Hyderabad, Bangkok, Kuala Lumpur, Singapore, Jakarta, Hong Kong, Taipei, Seoul, Osaka, Tokyo, Melbourne, and Sydney.
Each location probe breaks its processing loop if / when the endpoint response is too-many-requests, a.k.a. HTTP code 429 etc. Also, codes 401 and 403.
At the time of the report generation: 60 of 62 datasets were available from 31 selected regions x 2 endpoints.
2 datasets were not available at the time of the report generation: A.aws-me-central-1, B.aws-me-central-1.
Additional info about RPC Inspector Pro technology is in the FAQ and documentation
Findings
Summary by Dataset
Summary by Block
Includes only "complete" blocks (blocks seen by every probe). The p95 of the values in the column "p95" is: 251.8 ms.
Details
Per block, leading endpoint-region vs. every other arrival for the same block hash, incl. blocks not seen by every probe. Regional "wall clocks" are treated as globally synchronized. 16 datasets do not have rows in this table. Review Errors below for more info.
Errors
Info about errors incl. 429. Up to 4 retained error responses per endpoint, per region. Scenario-derived availability notes may also appear.