What Is a Validator Data Stream and Why Does It Matter on Sui and Hyperliquid

Post preview image

If you have ever wondered why some trading teams on Sui and Hyperliquid consistently see on-chain data before others, the answer is usually the same: they are not consuming from a public endpoint. They are consuming from a validator data stream.

This post explains what a validator data stream is, how it works technically, and what to look for when evaluating providers. Less pitch, more architecture. For teams where data latency is a direct trading-outcome concern, the infrastructure layer is worth understanding clearly.

What is a validator data stream?

A validator data stream is a real-time feed of on-chain data sourced directly from a validator node, delivered to subscribers before that data propagates to public infrastructure.

To understand why this matters, it helps to understand what a validator actually does. Validators are the nodes responsible for processing transactions and producing blocks. They are the first point of contact for new on-chain activity. Before a transaction appears in a public checkpoint, before it reaches a shared RPC endpoint, before any downstream service sees it, the validator has already processed it.

A validator data stream taps into that processing at the earliest possible point. Rather than waiting for data to travel through the network and become available to public consumers, a subscriber receives it directly from the validator the moment it is processed.

The result is a structural latency advantage. Not an optimized version of the same architecture. A different position in the data delivery chain.

How do public RPCs and checkpoints work?

To appreciate what a validator data stream delivers, it is worth understanding the alternative clearly.

When a trading team consumes data through a public RPC endpoint, they are consuming data that has already completed a significant journey. A validator processes a transaction. That transaction propagates through the network via gossip. Other nodes receive and validate it. It is included in a block. The block is finalized and published. A checkpoint is created. The checkpoint becomes available through public RPC infrastructure.

Each of those steps takes time. On Sui, public checkpoints reflect the network state after finalization, not at certificate processing. On Hyperliquid, the public API delivers order book snapshots at approximately 260 ms* from block creation, rate-limited to 100 requests per minute*.

Shared RPC infrastructure adds further latency on top of network propagation. Public endpoints serve many clients simultaneously. Under load, queuing and rate limiting compound the delay. A team consuming from a public endpoint during peak activity is not just delayed by network propagation. They are delayed by everyone else using the same pipe simultaneously.

For most applications, this is acceptable. For execution-critical trading, it is not.

Two parallel flowcharts comparing the public RPC data journey and the validator data stream path. The public path shows five hops through network propagation, other nodes, block finalization, and a shared RPC endpoint before reaching the subscriber. The validator data stream path shows one hop from the validator through a dedicated WebSocket directly to the subscriber.
The public RPC path adds five hops between the validator and your systems. A validator data stream reduces that to one.

How does a validator data stream work differently?

A validator data stream bypasses the propagation and shared infrastructure layers entirely by sourcing data at the point of origin.

The architecture varies slightly by network, but the core principle is consistent. The data stream runs directly on or adjacent to an active validator node. Data is captured as the validator processes it, before it enters the public propagation path, and delivered to the subscriber over a dedicated WebSocket connection with isolated credentials and IP-based access controls.

On Sui, this means capturing transaction events at certificate processing. This is the stage at which the validator has processed the transaction, but before it has been confirmed and published to the broader network. Two streaming endpoints are typically available: one covering pending transactions as they are processed, and one covering accepted transactions received from other validators before consensus. The result is the delivery approximately 15* ms ahead of public checkpoints.

On Hyperliquid, the architecture goes one step further. The data path runs from an active validator to dedicated private sentry infrastructure. The sentry node peers with the validator over a private network, receiving block data before it propagates through public gossip. Critically, the sentry reads data directly from the validator's internal output, before it passes through the node API, rather than consuming it through the node’s internal API. This eliminates an additional latency layer inherent to API-based delivery, where internal call overhead sits between the data being written and the data being sent. The result is delivery of full order flow within 115 to 135* ms of block creation.

In both cases, each subscriber receives a dedicated connection. There is no shared infrastructure, no queuing behind other clients, and no rate limiting that degrades performance under load.

What data does a validator data stream deliver?

The data surface available through a validator data stream is also meaningfully different from what public endpoints provide.

Public RPCs typically deliver snapshots: the state of the chain at a given point in time, available on request. They are built for read access, not for streaming. They do not deliver continuous event feeds, and they do not provide the granular per-event data that execution-critical strategies require.

A validator data stream delivers a continuous real-time feed of on-chain events as they occur. On Sui, this means transaction events at the moment of processing, with deduplication handled on-node. On Hyperliquid, this means the full order flow surface: every order across every asset, with order ID, side, price, quantity, status, and user attribution. Block events with height, timestamp, and apply duration. System metrics and heartbeat data on a dedicated channel, separated from the market data path so operational signals do not interfere with trading logic.

The user attribution component deserves particular attention. Aggregated public feeds do not identify the counterparty behind each order. A validator data stream that delivers user-attributed order flow enables counterparty modelling and signal research that is difficult to achieve on snapshot-based infrastructure. This is not a performance improvement. It is a meaningfully different class of data.

Why does the infrastructure layer matter for trading teams?

The trading infrastructure stack is usually discussed at the strategy and execution layer. What signals to act on? How to route orders. How to manage risk. The data layer is assumed to be a solved problem.

It is not.

The data layer determines what information is available, when it is available, and how complete it is. A strategy built on public endpoint data is constrained by the latency and completeness of that data. It is limited to acting on what has already surfaced, and to modelling counterparties it can identify. It cannot benchmark its latency because it has no faster feed to compare against.

A validator data stream changes all three constraints simultaneously. It delivers data earlier, more completely, and with attribution that public feeds do not provide.

For MEV searchers on Sui, earlier data means seeing opportunities while they are still open rather than after faster teams have closed them. For market makers on Hyperliquid, earlier and more complete data means quoting on the current state rather than the state that is already 200* ms old. For quant funds building signal pipelines, user-attributed order flow means modelling approaches that were previously unavailable.

None of these teams need to rebuild their strategies. They need to change where the data comes from.

How to evaluate a validator data stream?

Not all validator data streams are equal. A few things are worth checking before committing to a provider.

The first is whether the provider actually operates an active validator on the network in question. Some feeds marketed as validator-grade may actually route through third-party nodes. The latency advantage comes specifically from being on the validator itself, not from proximity to one. Confirm the provider operates an active validator on the relevant network before evaluating anything else.

The second is the delivery architecture. For Hyperliquid specifically, the way data is captured and delivered at the node level has a meaningful impact on latency. Architectures that minimise internal overhead between data being written and data being delivered will have an advantage at the node level. It is worth asking providers specifically how their data is captured and delivered from the validator.

The third is the operational model. A dedicated endpoint with isolated credentials and IP allowlisting is not just a security feature. It means your latency is not affected by other clients consuming the same stream. A shared endpoint, however fast the validator, reintroduces the queuing problem that public infrastructure creates.

Finally, the benchmark. Any serious validator data stream provider should offer a free trial specifically designed to let you run their feed alongside your existing setup and measure the gap directly. If the latency advantage is real, the benchmark will show it.

Further reading

For a broader look at why on-chain data latency is a business problem rather than a technical one, read The Hidden Cost of On-Chain Data Latency on Sui and Hyperliquid.

For a full overview of what Syncro Data Stream delivers and how it is built, read the launch post.

Full technical documentation is available at docs.p2p.org.

To get started with Syncro Data Stream for Sui, visit the Syncro Data Stream Sui page.

To get started with Syncro Data Stream for Hyperliquid, visit the Syncro Data Stream Hyperliquid page.


About P2P.org

P2P.org has operated blockchain infrastructure since 2018 across 40+ proof-of-stake networks, serving 190+ institutional partners. Syncro is P2P.org’s crypto trading infrastructure product line, built on active validator nodes across Solana, Sui, and Hyperliquid.


Disclaimer

This material is provided for informational purposes only and does not constitute investment, financial, legal, or tax advice. P2P.org accepts no liability for any actions taken based on it. Latency and performance figures referenced are estimates based on internal benchmarks and may vary depending on network conditions, geography, and client infrastructure. Past performance is not indicative of future results.

Subscribe to P2P-economy

Get the latest posts delivered right to your inbox

Subscribe
Read more