<p>Many trading teams operating on Sui and Hyperliquid may not know how much on-chain data latency is costing them. Not because they are making bad decisions. Not because their strategies are flawed. Because the infrastructure baseline they are measuring against was never fast enough to begin with.</p><p>When every team in your market is working from the same delayed data feed, the cost of that delay becomes invisible. There is no benchmark to reveal it. No P&L line that says “latency loss.” The opportunity simply does not appear, and the team moves on, assuming the strategy underperformed.</p><p>This is the hidden cost of on-chain data latency. And on chains with sub-second finality like Sui and Hyperliquid, it is larger than most teams realize.</p><h2 id="what-on-chain-data-latency-actually-means">What on-chain data latency actually means</h2><p>On-chain data latency is the gap between when something happens on the network and when your systems see it.</p><p>It sounds simple. In practice, it compounds across every layer of public infrastructure. A transaction is processed by a validator. Before it reaches your system, it has to propagate through the network, reach a public checkpoint or RPC endpoint, pass through shared infrastructure serving hundreds of other clients, and finally arrive at your stack. Each hop adds delay. Shared infrastructure adds queuing. Rate limits add throttling.</p><p>The result is that by the time your system sees the data, the network has moved on. Other teams have already acted. The window you were trying to trade is closed.</p><p>On Ethereum, where block times are measured in seconds, this gap is inconvenient but manageable. On Sui and Hyperliquid, where block times are measured in hundreds of milliseconds, the math changes entirely. A latency gap of 150 to 170 ms is not a rounding error on a chain that finalizes every 200 to 400 ms. It is the difference between seeing a state change before and after the next block.</p><h2 id="the-baseline-problem">The baseline problem</h2><p>The reason most teams do not notice this cost is straightforward: everyone is using the same infrastructure.</p><p>When trading teams and market makers are all consuming data from the same public endpoints, on-chain data latency becomes a shared condition rather than a competitive disadvantage. No individual team feels the pain acutely because no individual team has a faster alternative to compare against.</p><p>This is the baseline problem. The loss is real, but it is diffuse. It shows up as strategies that should work in theory but underperform in practice. It shows up as fill rates that are slightly worse than expected. It shows up as opportunities that seem to close just before your orders land.</p><p>Teams attribute these outcomes to market conditions, strategy parameters, and execution quality. Rarely to data infrastructure. Because the data infrastructure question was never asked.</p><p>The question only gets asked when a team benchmarks against a faster feed and sees the gap directly.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/06/syncro_data_stream_baseline_problem.jpg" class="kg-image" alt="Two scenarios side by side. Left: all trading teams consuming from the same public endpoint with no competitive edge visible. Right: one team connected directly to the validator, receiving data before the others, still on the public endpoint, with the latency gap clearly visible." loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/06/syncro_data_stream_baseline_problem.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/06/syncro_data_stream_baseline_problem.jpg 1000w, https://p2p.org/economy/content/images/2026/06/syncro_data_stream_baseline_problem.jpg 1600w" sizes="(min-width: 720px) 720px"><figcaption><i><em class="italic" style="white-space: pre-wrap;">The cost of on-chain data latency is invisible when every team is on the same baseline. It only becomes measurable when one team has faster access for comparison.</em></i></figcaption></figure><h2 id="what-the-gap-looks-like-in-practice">What the gap looks like in practice</h2><p>On Sui, transaction events surface at public checkpoints after the network has processed and propagated them. A team consuming data from a public RPC is seeing the network state as it was, not as it is. On a chain where validators process transactions in single-digit milliseconds at the certificate processing stage, the gap between what a validator knows and what a public endpoint delivers is measured in tens of milliseconds. That is enough time for multiple state changes to occur.</p><p><em>On Hyperliquid, the dynamic is sharper. The public API delivers order book data at approximately 260 ms</em>, with snapshots only, rate-limited to 100 requests per minute*. For a market maker or quant fund trying to model counterparty flow, that feed is not just slow. It is structurally limited in important ways. Snapshot-based delivery without user attribution makes it difficult to conduct entire classes of signal research on public infrastructure.*</p><p>The teams that have moved to validator-speed real-time blockchain data streams on these networks are not just faster. They are operating with a fundamentally different information set.</p><h2 id="why-this-is-a-business-problem-not-a-technical-problem">Why this is a business problem, not a technical problem</h2><p>On-chain data latency is easy to frame as an infrastructure concern. For execution-critical teams, it is a bottom-line concern.</p><p>For MEV searchers on Sui, being 15 ms* behind the fastest available feed means running strategies against a state that has already been acted on. Every search that resolves to a closed opportunity is a search that costs gas and returns nothing. The latency is not a technical inefficiency. It is a direct cost per failed search.</p><p>For market makers on Hyperliquid, quoting on stale orderbook data means setting spreads that do not reflect current conditions. A market maker quoting on data that is 200 ms* old on a venue that moves in 100 ms* intervals is not providing liquidity. They are subsidising better-informed counterparties with tighter access to the same data.</p><p>For arbitrage desks operating across pairs or venues, the window for a viable round-trip closes as soon as faster participants act on the same signal. On-chain data latency determines whether you see that signal in time to act, or whether you see it after the round-trip is already unviable. In each case, the latency cost is not a line item. It is embedded in the gap between theoretical and realised returns. It is hard to surface without a faster point of comparison.</p><h2 id="when-the-cost-becomes-visible">When the cost becomes visible</h2><p>The cost of on-chain data latency only becomes visible through comparison. And the comparison only becomes possible when a faster alternative exists and is accessible.</p><p>For most of the history of on-chain trading on Sui and Hyperliquid, accessible, documented, validator-speed data feeds have been hard to come by, particularly for teams without institutional-scale infrastructure budgets. The barrier to entry was high enough that most teams never made the comparison.</p><p>That is changing. Validator-speed real-time blockchain data streams are now available at flat monthly pricing, with free trials designed to make comparisons easy. The benchmark is the product. Run it alongside your existing feed. Measure the gap. Decide whether the edge is worth the cost.</p><p>For most execution-critical teams, the answer becomes clear quickly.</p><h2 id="the-infrastructure-principle-behind-the-edge">The infrastructure principle behind the edge</h2><p>The latency advantage of validator-speed data comes from one architectural decision: sourcing data at the point of origin rather than consuming it downstream.</p><p>Public endpoints are downstream consumers of validator output. They receive data after it has propagated through the network, been confirmed, and been made available to shared infrastructure. The delay is structural. It cannot be optimised away by tuning polling intervals or upgrading RPC tiers. It is inherent to the architecture.</p><p>A real-time blockchain data stream sourced directly from an active validator node eliminates that structural delay. On Sui, this means surfacing transaction events at certificate processing, before public checkpoints. On Hyperliquid, this means reading order flow data directly from disk files on private Sentry infrastructure that peers with the validator over a private network, before block data propagates publicly.</p><p>The result is not incremental improvement on the same architecture. It is a different position entirely in the data delivery chain.</p><h2 id="what-to-do-with-this">What to do with this</h2><p>If your team is operating on Sui or Hyperliquid and has never benchmarked your data feed against validator-speed delivery, the first step is straightforward: run the comparison.</p><p>Syncro Data Stream by P2P.org is a real-time blockchain data stream for Sui and Hyperliquid, built directly on P2P.org’s active validator infrastructure. New clients receive a one-week free trial to validate latency and data quality against their existing setup. No credit card required.</p><p>The trial is designed to answer one question: how much latency is your current feed adding, and does it matter for how you operate?</p><p>Check the full technical documentation for Sui Data Stream <a href="https://docs.p2p.org/docs/syncro-data-sui-overview?ref=p2p.org" rel="noreferrer">here</a> and Hyperliquid <a href="https://docs.p2p.org/docs/syncro-data-hyperliquid-overview?ref=p2p.org" rel="noreferrer">here</a>.</p><p>To benchmark Syncro Data Stream for Sui against your existing feed, visit the <a href="https://www.p2p.org/products/syncro-sui-transaction-data-stream?ref=p2p.org" rel="noreferrer">Syncro Data Stream Sui page</a>.</p><p>To benchmark Syncro Data Stream for Hyperliquid against your existing feed, visit the <a href="https://www.p2p.org/products/syncro-hyperliquid-data-stream?ref=p2p.org" rel="noreferrer">Syncro Data Stream Hyperliquid page</a>.</p><p>For a full overview of what Syncro Data Stream delivers and how it is built, read the <a href="https://p2p.org/economy/syncro-data-stream-real-time-blockchain-data-stream/" rel="noreferrer">launch's product introduction post</a>.</p><hr><h2 id="about-p2porg">About P2P.org</h2><p>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.</p><hr><h2 id="disclaimer">Disclaimer</h2><p>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.</p>
from p2p validator
<h2 id="what-actually-happens-between-submission-and-execution">What actually happens between submission and execution</h2><p>Speed is often treated as the defining feature of Solana.</p><p>What is less understood is what happens between submission and landing, and why two transactions sent at the same time can end up with completely different outcomes.</p><p>For teams running execution-critical workflows such as arbitrage, liquidations, or high-frequency strategies, performance is not defined by how fast a transaction is sent. It is defined by whether it gets to the leader in time.</p><p>These are the observations we made while building Syncro Sender, P2P.org's Solana transaction sender built for execution-critical teams. We are sharing them here because the patterns we found are not specific to our infrastructure. They reflect how Solana transaction delivery works at the network level.</p><p>Our <a href="https://p2p.org/economy/solana-transaction-landing-speed-routing/">previous post</a> reframes the problem: Solana transaction landing is not a speed problem, it is a routing problem. This post goes one level deeper and explains the system behind it: what the delivery path actually looks like, where it breaks, and what changes when you build infrastructure around it.</p><h2 id="quick-lessons-for-builders">Quick Lessons for Builders</h2><ul><li>Transaction landing depends on delivery, not submission timing</li><li>Routing quality matters more than endpoint speed</li><li>Stake-weighted connections determine delivery priority</li><li>Single-path submission breaks under congestion</li><li>Tail latency defines real execution performance</li></ul><h2 id="what-is-solana-transaction-delivery">What Is Solana Transaction Delivery</h2><p>Solana transaction delivery is the process of getting a transaction from submission to the block leader before the slot closes.</p><p>Each slot has a designated leader. If your transaction does not reach that leader in time, it does not land.</p><p>In practice, four things decide that outcome:</p><ul><li>routing path quality</li><li>stake-backed priority</li><li>delivery strategy (single vs multi-path)</li><li>transaction construction</li></ul><p>Priority fees affect ordering once the transaction arrives. Compute limits and blockhash freshness affect inclusion.</p><p>But none of that matters if the transaction never makes it to the leader.</p><h2 id="why-transactions-with-the-same-timing-have-different-outcomes">Why Transactions with the Same Timing Have Different Outcomes</h2><p>Two transactions sent at the same time do not take the same path.</p><p>One may move through prioritized connections with stable bandwidth. Another may compete through shared infrastructure alongside thousands of other transactions.</p><p>Under low load, the difference is small.</p><p>Under congestion, it becomes decisive.</p><p>On Solana, a few milliseconds is not a rounding error. It is the difference between landing in the current slot or missing it entirely.</p><h2 id="what-happens-between-submission-and-the-leader">What Happens Between Submission and the Leader</h2><p>Once submitted, a transaction is forwarded to current and upcoming leaders via QUIC.</p><p>From there, everything depends on:</p><ul><li>connection quality</li><li>routing efficiency</li><li>available bandwidth</li></ul><p>With approximately 390ms slot times, the margin for error is minimal.</p><p>Most variance does not come from when a transaction is sent. It comes from how it is forwarded under load.</p><h2 id="where-public-rpc-falls-short">Where Public RPC Falls Short</h2><p>Public RPC is built for accessibility, not for winning under load.</p><p>That tradeoff shows up in three ways:</p><ul><li>shared bandwidth with no prioritization</li><li>limited control over routing paths</li><li>high variability during peak demand</li></ul><p>Average performance may look fine. But under real conditions, consistency breaks down, and consistency is what execution depends on.</p><h2 id="the-role-of-stake-weighted-qos-in-delivery">The Role of Stake-Weighted QoS in Delivery</h2><p>Stake-weighted QoS operates at the network layer.</p><p>Leaders allocate a significant share of bandwidth to staked connections. Transactions using those connections are less likely to be delayed during congestion.</p><p>This happens before fees come into play.</p><p>Fees decide ordering. Routing decides whether your transaction even gets a chance to be ordered.</p><h2 id="why-connectivity-and-network-positioning-matter">Why Connectivity and Network Positioning Matter</h2><p>With approximately 390ms slots, distance is measured in milliseconds, not in geography.</p><p>What matters is:</p><ul><li>how many hops your transaction takes</li><li>how strong those connections are</li><li>how directly you can reach the leader</li></ul><p>Because the leader rotates continuously, performance depends on consistent access across the validator set, not proximity to a single location.</p><h2 id="why-single-path-delivery-breaks-under-load">Why Single-Path Delivery Breaks Under Load</h2><p>Single-path delivery relies on one route working.</p><p>Under peak demand, that assumption breaks.</p><p>If that path is congested or delayed, there is no fallback already in motion. By the time you retry, the slot is gone.</p><p>This is where tail latency matters. A system that works most of the time but fails when it matters most is not reliable.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/03/Solana-transaction-delivery-path.png" class="kg-image" alt="Solana transaction delivery path: single path vs multi-path" loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/Solana-transaction-delivery-path.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/Solana-transaction-delivery-path.png 1000w, https://p2p.org/economy/content/images/2026/03/Solana-transaction-delivery-path.png 1600w" sizes="(min-width: 720px) 720px"><figcaption><span style="white-space: pre-wrap;">Solana transaction delivery path: single path vs multi-path</span></figcaption></figure><h2 id="what-changes-with-multi-path-delivery">What Changes with Multi-Path Delivery</h2><p>Multi-path delivery changes the model completely.</p><p>Instead of relying on one route, transactions are sent across multiple paths at once:</p><ul><li>toward current leaders</li><li>toward upcoming leaders</li><li>through prioritized connections</li></ul><p>Whichever path reaches the leader first determines the outcome.</p><p>The goal is no longer to hope one path works, but to ensure at least one does.</p><h2 id="what-teams-should-measure-instead">What Teams Should Measure Instead</h2><p>If you are measuring performance under average conditions, you are measuring the wrong thing.</p><p>What matters is how your infrastructure behaves under stress.</p><p>The key metrics:</p><ul><li>slot landing distribution</li><li>tail latency during congestion</li><li>drop rate (submitted vs landed)</li><li>performance at peak demand</li></ul><p>That is where execution is won or lost.</p><h2 id="what-most-teams-misunderstand">What Most Teams Misunderstand</h2><p>The most common mistake is assuming higher fees improve landing probability.</p><p>They do not.</p><p>Fees only affect ordering after a transaction reaches the leader.</p><p>Another misconception is treating a successful submission as success. A response only confirms the transaction was received. It does not confirm that it landed.</p><p>And average performance is misleading. On Solana, worst-case outcomes define your edge.</p><h2 id="a-practical-step-to-improve-delivery">A Practical Step to Improve Delivery</h2><p>The simplest way to improve performance is to stop relying on a single path.</p><p>Adding a parallel delivery route allows you to compare real outcomes under real conditions without replacing your existing setup.</p><p>It is a small change that makes delivery visible and measurable.</p><h2 id="where-the-ecosystem-is-moving">Where the Ecosystem Is Moving</h2><p>Execution-focused teams are moving toward delivery-aware infrastructure.</p><p>The shift is simple: from sending transactions to controlling how they are delivered.</p><p>If you want to understand why routing is the root cause before diving into the system, the <a href="https://p2p.org/economy/solana-transaction-landing-speed-routing/">previous post</a> covers that ground. This post is the next step: the mechanism behind the problem, and what it takes to solve it at the infrastructure level.</p><p>Syncro Sender is built on these principles. Validator-level routing, multi-path delivery, and SWQoS-enabled connections, deployed across Amsterdam, Frankfurt, New York, London, Tokyo, and Singapore. Add it as a parallel submission path alongside your current setup and compare landing performance on real flow.</p><p><a href="https://www.p2p.org/products/syncro-solana-transaction-sender?ref=p2p.org">Start here.</a></p><h2 id="key-takeaway">Key Takeaway</h2><p>On Solana, speed does not decide outcomes.</p><p>Delivery does.</p><h2 id="faq">FAQ</h2><h3 id="what-is-solana-transaction-delivery-1">What is Solana transaction delivery?</h3><p>It is the process of getting a transaction from submission to the block leader in time for inclusion in a slot.</p><h3 id="why-do-transactions-fail-to-land-on-solana">Why do transactions fail to land on Solana?</h3><p>Because they arrive too late, compete under congestion, or fail due to constraints like blockhash expiry or prioritization.</p><h3 id="do-priority-fees-improve-transaction-landing">Do priority fees improve transaction landing?</h3><p>No. They affect ordering after arrival, not whether the transaction reaches the leader in time.</p><h3 id="what-improves-transaction-delivery-performance">What improves transaction delivery performance?</h3><p>Better routing, prioritized connections, multi-path delivery, and optimized infrastructure placement.</p>
from p2p validator