<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
<p>Today, <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> launches Syncro Data Stream: a real-time blockchain data stream for Sui and Hyperliquid, built directly on P2P.org's active validator infrastructure.</p><p>Syncro Data Stream is designed for latency-sensitive teams where on-chain data latency directly affects trading performance. Trading teams, market makers, quant funds, and arbitrage desks operating on Sui or Hyperliquid now have access to validator-speed data delivery through a dedicated WebSocket endpoint, at flat monthly pricing with a one-week free trial.</p><p>For trading teams that have been making do with shared public endpoints and checkpoint-based feeds, this changes what is available at a documented, accessible price point.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/05/syncro-data-stream-data-path-diagram.jpg" class="kg-image" alt="Diagram showing two data delivery paths from a validator node: the Syncro Data Stream path via private Sentry and dedicated WebSocket, and the public path via network gossip and shared RPC endpoint" loading="lazy" width="1600" height="900" srcset="https://p2p.org/economy/content/images/size/w600/2026/05/syncro-data-stream-data-path-diagram.jpg 600w, https://p2p.org/economy/content/images/size/w1000/2026/05/syncro-data-stream-data-path-diagram.jpg 1000w, https://p2p.org/economy/content/images/2026/05/syncro-data-stream-data-path-diagram.jpg 1600w" sizes="(min-width: 720px) 720px"><figcaption><i><em class="italic" style="white-space: pre-wrap;">Syncro Data Stream sources data at the validator and delivers it to clients before it reaches public infrastructure. The public path adds network propagation and shared endpoint delays on top.</em></i></figcaption></figure><h2 id="what-is-syncro-data-stream">What is Syncro Data Stream?</h2><p>Syncro Data Stream is a real-time blockchain data stream sourced directly from P2P.org's active validators. Unlike shared public endpoints and standard RPC providers, Syncro Data Stream delivers on-chain data before it propagates to public infrastructure, at the earliest point of network availability.</p><p>The product launches on two networks simultaneously, Sui Network and Hyperliquid Network.</p><figure class="kg-card kg-video-card kg-width-regular kg-card-hascaption" data-kg-thumbnail="https://p2p.org/economy/content/media/2026/05/p2p-org-syncro-data-stream-Sui-Hyperliquid-promotional-video_thumb.jpg" data-kg-custom-thumbnail=""> <div class="kg-video-container"> <video src="https://p2p.org/economy/content/media/2026/05/p2p-org-syncro-data-stream-Sui-Hyperliquid-promotional-video.mp4" poster="https://img.spacergif.org/v1/1920x1080/0a/spacer.png" width="1920" height="1080" playsinline="" preload="metadata" style="background: transparent url('https://p2p.org/economy/content/media/2026/05/p2p-org-syncro-data-stream-Sui-Hyperliquid-promotional-video_thumb.jpg') 50% 50% / cover no-repeat;"></video> <div class="kg-video-overlay"> <button class="kg-video-large-play-icon" aria-label="Play video"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"> <path d="M23.14 10.608 2.253.164A1.559 1.559 0 0 0 0 1.557v20.887a1.558 1.558 0 0 0 2.253 1.392L23.14 13.393a1.557 1.557 0 0 0 0-2.785Z"></path> </svg> </button> </div> <div class="kg-video-player-container"> <div class="kg-video-player"> <button class="kg-video-play-icon" aria-label="Play video"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"> <path d="M23.14 10.608 2.253.164A1.559 1.559 0 0 0 0 1.557v20.887a1.558 1.558 0 0 0 2.253 1.392L23.14 13.393a1.557 1.557 0 0 0 0-2.785Z"></path> </svg> </button> <button class="kg-video-pause-icon kg-video-hide" aria-label="Pause video"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"> <rect x="3" y="1" width="7" height="22" rx="1.5" ry="1.5"></rect> <rect x="14" y="1" width="7" height="22" rx="1.5" ry="1.5"></rect> </svg> </button> <span class="kg-video-current-time">0:00</span> <div class="kg-video-time"> /<span class="kg-video-duration">0:58</span> </div> <input type="range" class="kg-video-seek-slider" max="100" value="0"> <button class="kg-video-playback-rate" aria-label="Adjust playback speed">1×</button> <button class="kg-video-unmute-icon" aria-label="Unmute"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"> <path d="M15.189 2.021a9.728 9.728 0 0 0-7.924 4.85.249.249 0 0 1-.221.133H5.25a3 3 0 0 0-3 3v2a3 3 0 0 0 3 3h1.794a.249.249 0 0 1 .221.133 9.73 9.73 0 0 0 7.924 4.85h.06a1 1 0 0 0 1-1V3.02a1 1 0 0 0-1.06-.998Z"></path> </svg> </button> <button class="kg-video-mute-icon kg-video-hide" aria-label="Mute"> <svg xmlns="http://www.w3.org/2000/svg" viewBox="0 0 24 24"> <path d="M16.177 4.3a.248.248 0 0 0 .073-.176v-1.1a1 1 0 0 0-1.061-1 9.728 9.728 0 0 0-7.924 4.85.249.249 0 0 1-.221.133H5.25a3 3 0 0 0-3 3v2a3 3 0 0 0 3 3h.114a.251.251 0 0 0 .177-.073ZM23.707 1.706A1 1 0 0 0 22.293.292l-22 22a1 1 0 0 0 0 1.414l.009.009a1 1 0 0 0 1.405-.009l6.63-6.631A.251.251 0 0 1 8.515 17a.245.245 0 0 1 .177.075 10.081 10.081 0 0 0 6.5 2.92 1 1 0 0 0 1.061-1V9.266a.247.247 0 0 1 .073-.176Z"></path> </svg> </button> <input type="range" class="kg-video-volume-slider" max="100" value="100"> </div> </div> </div> <figcaption><p dir="ltr"><span style="white-space: pre-wrap;">Syncro Data Stream delivers real-time blockchain data for Sui and Hyperliquid, sourced directly from P2P.org's active validator nodes before it reaches any public endpoint.</span></p></figcaption> </figure><h3 id="syncro-data-stream-for-sui-network">Syncro Data Stream for Sui Network</h3><p>The stream delivers Sui transaction events at certificate processing, before transactions reach public checkpoints and RPC feeds. This is the stage at which the validator has processed the transaction, but before it has been confirmed and published to the broader network. Each client receives a WebSocket endpoint with isolated credentials and IP-based access controls, providing real-time data streaming optimised for execution speed.</p><h3 id="syncro-data-stream-for-hyperliquid-network">Syncro Data Stream for Hyperliquid Network</h3><p>The stream delivers full Hyperliquid order flow from P2P.org's active validator and private sentry nodes, within milliseconds of block creation. Every order across every asset: open, modify, cancel, and fill, with side, price, quantity, status, order ID, and user attribution. Block events, system metrics, and heartbeat data arrive on a dedicated channel, keeping operational signals out of the market data path. Per-asset subscriptions or full firehose, with WebSocket JSON or ESP binary delivery.</p><p>Both products are available at $2,000 per month each, with a one-week free trial for new clients.</p><h2 id="why-on-chain-data-latency-matters">Why on-chain data latency matters</h2><p>For most applications, receiving transaction data a few hundred milliseconds after it hits public infrastructure is acceptable. For latency-sensitive teams, it is not.</p><p>On-chain data latency is the gap between when something happens on the network and when your systems see it. For trading teams, that gap determines whether an opportunity is still open or already taken. For market makers, it determines whether a quote reflects the current state or stale state. For arbitrage desks, it determines whether a price discrepancy still exists by the time an order reaches the book.</p><p>Public APIs and shared RPC endpoints introduce on-chain data latency in two ways. First, data has to propagate from the validator through the network before it reaches a public endpoint. Second, shared infrastructure adds queuing and rate limiting that compound the delay under load. The result is that by the time your systems see the data, multiple other teams have already acted on it.</p><p>This is not a marginal problem. On chains with sub-second finality like Sui and Hyperliquid, where block times are measured in hundreds of milliseconds, even a 5 ms latency gap relative to the fastest available feed can be meaningful. In these environments, opportunities can open and close within milliseconds</p><p>Syncro Data Stream reduces that gap to a single validator-to-client hop, delivering data before it touches any public infrastructure.</p><h2 id="built-on-active-validator-infrastructure">Built on active validator infrastructure</h2><p>The differentiator for Syncro Data Stream is not just speed. It is where the data originates.</p><p>P2P.org operates active validators on both Sui and Hyperliquid, giving us direct access to network data at the infrastructure level. For Sui, our data stream is integrated with our validator operations, allowing us to surface transaction events earlier than standard public data sources.</p><p>For Hyperliquid, we use a dedicated low-latency data delivery setup within our private infrastructure, designed to reduce unnecessary overhead and provide clients with timely access to block and transaction data.</p><p>P2P.org is not a trading firm. Syncro Data Stream is a read-only data stream. P2P.org has no visibility into client strategies, positions, execution logic, or customer data. For teams evaluating infrastructure providers that also trade, this distinction matters.</p><h2 id="who-syncro-data-stream-is-for">Who Syncro Data Stream is for</h2><p>Syncro Data Stream is built for teams that have outgrown shared public infrastructure and need dedicated, validator-speed data delivery.</p><h3 id="high-frequency-and-systematic-traders">High-frequency and systematic traders</h3><p>For directional and arbitrage teams, execution quality depends on latency. Public endpoint latency puts teams at a structural disadvantage relative to teams with faster access. Syncro Data Stream is designed to help close that gap, providing a low-latency baseline that supports tighter entry and exit timing across Sui and Hyperliquid.</p><h3 id="market-making-and-liquidity-provision">Market making and liquidity provision</h3><p>Relying on delayed data leads to adverse selection. Syncro Data Stream delivers validator-speed order flow with granular user attribution, allowing market makers to maintain tighter spreads, manage inventory risk more effectively, and meaningfully shift the information baseline for teams that need to quote accurately under fast-moving conditions.</p><h3 id="quantitative-research-and-alpha-generation">Quantitative research and alpha generation</h3><p>Aggregated feeds mask market microstructure. Syncro Data Stream for Hyperliquid provides the complete, non-summarised order flow across every asset with persistent user IDs. This high-fidelity stream can enable modelling approaches that are difficult to achieve on snapshot-based feeds, supporting predictive signal research and counterparty analysis.</p><p>For Hyperliquid specifically, Syncro Data Stream is positioned as an open, documented, validator-speed offering with transparent pricing at $2,000 per month and a one-week free trial, designed for teams that need accessible, production-ready sentry-level data.</p><h2 id="part-of-the-syncro-infrastructure-product-line">Part of the Syncro infrastructure product line</h2><p>Syncro Data Stream joins Syncro Sender, P2P.org's Solana transaction landing service, as part of the Syncro infrastructure line.</p><p>Syncro Sender routes Solana transactions through P2P.org's staked validator connections and multi-path delivery to reach the block leader before traffic coming through public RPCs. It is already in production with leading trading teams.</p><p>Syncro Data Stream and Syncro Sender address two sides of the same problem: getting your systems closer to the chain than shared public infrastructure allows. Sender handles the execution side on Solana. Syncro Data Stream handles the data side on Sui and Hyperliquid. For teams operating across multiple networks, both products run on the same <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> validator infrastructure and follow the same dedicated endpoint model.</p><h2 id="getting-started">Getting started</h2><p>Both Syncro Data Stream products are available now. Provisioning is straightforward: share your IP for allowlisting, receive your dedicated WebSocket endpoint and credentials, and connect your systems. Most teams are live within days of signing.</p><p>New clients receive a one-week free trial to validate integration, latency, and data quality against their existing setup. No credit card required.</p><p>Full technical documentation is available at <a href="https://docs.p2p.org/?ref=p2p.org">docs.p2p.org</a>.</p><p>To get started with Syncro Data Stream for Sui, 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 get started with Syncro Data Stream for Hyperliquid, 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><hr><h2 id="about-p2porg">About P2P.org</h2><p>P2P.org has operated blockchain infrastructure since 2018 across dozens of proof-of-stake networks, serving a broad base of institutional partners. Syncro is P2P.org's crypto trading infrastructure product line, built on the same validator infrastructure that powers our staking business.</p><hr><h2 id="disclaimer"><em>Disclaimer</em></h2><p>This material is provided for informational purposes only and does not constitute investment, financial, legal, or tax advice. <a href="http://p2p.org/?ref=p2p.org">P2P.org</a> 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="introduction">Introduction</h2><p>If your execution depends on transaction landing, set up speed matters.</p><p>Syncro Sender is designed to integrate directly into your existing flow with minimal changes. You can start sending transactions in minutes using either a public or a private endpoint.</p><p>This guide walks through how to set up Syncro Sender and start sending transactions immediately. For a full technical reference, see the <a href="https://docs.p2p.org/docs/syncro-sender-overview?ref=p2p.org">Syncro Sender documentation</a>.</p><h2 id="what-you-need-before-starting">What You Need Before Starting</h2><p>Before using Syncro Sender, make sure you have:</p><ul><li>A signed Solana transaction</li><li>Base64 encoded transaction data</li><li>A standard RPC endpoint for reads such as blockhash and confirmation</li></ul><p>Syncro Sender is used for transaction delivery, not simulation or state queries.</p><h2 id="step-1-choose-your-endpoint">Step 1: Choose Your Endpoint</h2><p>Syncro Sender supports two access modes.</p><h3 id="public-endpoint-no-api-key">Public endpoint (no API key)</h3><ul><li>No authentication required</li><li>Requires a tip of 0.0001 SOL (100,000 lamports) inside the transaction</li><li>Rate limited to 1 request per second</li><li>Best for quick testing</li></ul><p>Available endpoints:</p><ul><li>Frankfurt: <code>http://sfls-geo-fra.l2.p2p.org/public</code></li><li>New York: <code>http://sfls-geo-nyc.l2.p2p.org/public</code></li><li>London: <code>http://sfls-geo-lon.l2.p2p.org/public</code></li><li>Tokyo: <code>http://sfls-geo-tky.l2.p2p.org/public</code></li><li>Singapore: <code>http://sfls-geo-sgp.l2.p2p.org/public</code></li><li>Amsterdam: <code>http://sfls-eu1.l2.p2p.org/public</code></li></ul><h3 id="private-endpoint-api-key">Private endpoint (API key)</h3><ul><li>Requires API key authentication</li><li>Requires a tip of 0.001 SOL (1,000,000 lamports). For the first month, the tip is reduced to 0.0001 SOL as part of the production benchmark period</li><li>Supports up to 50 requests per second</li><li>Supports full RPC methods</li></ul><p>To get access, request it via the <a href="https://www.p2p.org/products/syncro-solana-transaction-sender?ref=p2p.org">Syncro Sender page</a> or contact the team.</p><h2 id="step-2-add-a-tip-to-your-transaction">Step 2: Add a Tip to Your Transaction</h2><p>A tip is required for both public and private endpoints.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/03/how-a-tip-enabled-transaction-reaches-the-block-leader.png" class="kg-image" alt="Step by step diagram showing how a tip-enabled Solana transaction is built, signed, base64 encoded, submitted to a Syncro Sender geo-routed endpoint, and delivered to the block leader through multi-path validator routing including current leader, staked path, and upcoming leader connections." loading="lazy" width="2000" height="1304" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/how-a-tip-enabled-transaction-reaches-the-block-leader.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/how-a-tip-enabled-transaction-reaches-the-block-leader.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/03/how-a-tip-enabled-transaction-reaches-the-block-leader.png 1600w, https://p2p.org/economy/content/images/2026/03/how-a-tip-enabled-transaction-reaches-the-block-leader.png 2240w" sizes="(min-width: 720px) 720px"><figcaption><span style="white-space: pre-wrap;">How a tip-enabled transaction reaches the block leader.</span></figcaption></figure><h3 id="minimum-tip">Minimum tip</h3><ul><li>Public: 100,000 lamports (0.0001 SOL)</li><li>Private: 1,000,000 lamports (0.001 SOL)</li></ul><h3 id="how-to-add-the-tip">How to add the tip</h3><p>Add a System Program transfer instruction to a valid tip account:</p><pre><code class="language-jsx">transaction.addInstruction( SystemProgram.transfer( yourPublicKey, 'BPZrtYhdoAhiHWV5EgGLoV7bZFbMamBZurGDq4DmST8v', 100000 ) );transaction.addInstruction( SystemProgram.transfer( yourPublicKey, 'BPZrtYhdoAhiHWV5EgGLoV7bZFbMamBZurGDq4DmST8v', 100000 ) ); </code></pre><h2 id="common-errors"><strong>Common errors</strong></h2><ul><li>Missing tip → request fails</li><li>Insufficient tip → request fails</li></ul><p>Error example:</p><pre><code class="language-jsx">"Insufficient tip: provided X lamports, required Y lamports" </code></pre><h1 id="step-3-send-your-transaction"><strong>Step 3: Send Your Transaction</strong></h1><h2 id="public-endpoint-request"><strong>Public endpoint request</strong></h2><pre><code class="language-jsx">curl -X POST <https://sfls.l2.p2p.org/public> \\ -H "Content-Type: application/json" \\ -d '{ "jsonrpc": "2.0", "id": 1, "method": "sendTransaction", "params": ["<BASE64_ENCODED_TX_WITH_TIP>", {"encoding": "base64"}] }' </code></pre><p><strong>Private endpoint request</strong></p><pre><code class="language-jsx">curl -X POST <https://sfls.l2.p2p.org> \\ -H "Content-Type: application/json" \\ -H "Authorization: Bearer YOUR_API_KEY" \\ -d '{ "jsonrpc": "2.0", "id": 1, "method": "sendTransaction", "params": ["<BASE64_ENCODED_TX>", {"encoding": "base64"}] }' </code></pre><p><strong>Response</strong></p><pre><code class="language-jsx">{ "jsonrpc": "2.0", "result": "<TRANSACTION_SIGNATURE>", "id": 1 } </code></pre><h1 id="step-4-test-and-compare-performance">Step 4: Test and Compare Performance</h1><p>Once integrated, test Syncro Sender alongside your current setup.</p><p>Focus on:</p><ul><li>landing success rate</li><li>time to confirmation</li><li>consistency under load</li></ul><p>Use your standard RPC to monitor transaction status. Private endpoint users can also use Syncro Sender for all standard Solana RPC requests, including status checks and confirmation queries.</p><h3 id="performance-best-practices">Performance Best Practices</h3><p>To get the best results:</p><ul><li>Use <code>skipPreflight: true</code> to reduce latency</li><li>Use base64 encoding</li><li>Reuse HTTP connections with keep alive</li><li>Add a priority fee for validator scheduling</li></ul><h3 id="retry-strategy">Retry strategy</h3><ul><li>429 → wait and retry</li><li>500 → retry with backoff</li><li>400 → fix request</li><li>network error → retry</li></ul><p>Submitting the same transaction multiple times is safe.</p><h2 id="common-mistakes-to-avoid">Common Mistakes to Avoid</h2><ul><li>Sending transactions without a tip</li><li>Using Syncro Sender for read requests on the public endpoint</li><li>Not adding priority fees for competitive execution</li><li>Opening new connections for every request</li><li>Ignoring rate limit headers</li></ul><h2 id="when-to-use-public-vs-private">When to Use Public vs Private</h2> <!--kg-card-begin: html--> <table> <thead> <tr> <th>Use case</th> <th>Recommendation</th> </tr> </thead> <tbody> <tr> <td>Testing</td> <td>Public endpoint</td> </tr> <tr> <td>Production trading</td> <td>Private endpoint</td> </tr> <tr> <td>High frequency workflows</td> <td>Private endpoint</td> </tr> </tbody> </table> <!--kg-card-end: html--> <h2 id="what-this-setup-actually-changes">What This Setup Actually Changes</h2><p>Syncro Sender does not change your transaction logic.</p><p>It changes how your transactions are delivered.</p><p>That means:</p><ul><li>better routing</li><li>higher landing probability</li><li>more consistent execution</li></ul><h2 id="get-started">Get Started</h2><p>You can start immediately using the public endpoint.</p><p>For production use cases, request access to the private endpoint.</p><p>For the full technical reference and advanced configuration options, visit the <a href="https://docs.p2p.org/docs/syncro-sender-overview?ref=p2p.org">Syncro Sender documentation</a>.</p><p>👉 Syncro Sender: <a href="https://www.p2p.org/products/syncro-solana-transaction-sender?ref=p2p.org">https://www.p2p.org/products/syncro-solana-transaction-sender</a> <br>👉 Docs: <a href="https://docs.p2p.org/docs/syncro-sender-overview?ref=p2p.org">https://docs.p2p.org/docs/syncro-sender-overview</a></p><h2 id="faq">FAQ</h2><h3 id="do-i-need-an-api-key-to-use-syncro-sender">Do I need an API key to use Syncro Sender?</h3><p>No. The public endpoint requires only a tip of 0.0001 SOL in the transaction.</p><h3 id="what-happens-if-i-do-not-include-a-tip">What happens if I do not include a tip?</h3><p>The transaction will be rejected with an error.</p><h3 id="can-i-use-syncro-sender-for-read-requests">Can I use Syncro Sender for read requests?</h3><p>Only on private endpoints with this feature enabled.</p><h3 id="how-do-i-check-if-my-transaction-landed">How do I check if my transaction landed?</h3><p>Use a standard Solana RPC method such as <code>getSignatureStatuses</code>.</p><h3 id="what-encoding-should-i-use">What encoding should I use?</h3><p>Base64 encoding is required and recommended.</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
<h2 id="intro">Intro</h2><p>Every Solana transaction sender promises speed. Few explain where that speed actually comes from.</p><p>Solana transaction landing is about speed. But speed is not just how fast a transaction is sent. It depends on how transactions are routed through staked validator paths that give your flow priority bandwidth to the block leader, before competing with everyone else.</p><p>The difference is not small. It determines whether a transaction lands or misses entirely.</p><h2 id="the-hidden-bottleneck-behind-solana-transaction-landing">The Hidden Bottleneck Behind Solana Transaction Landing</h2><p>When a transaction is submitted on Solana, it is sent toward the block leader. But how it gets there determines whether it lands.</p><p>Transactions are forwarded by RPC nodes to the current and upcoming leaders via TPU and QUIC. However, routing conditions such as bandwidth, prioritization, and connection quality define the result.</p><p>Two transactions submitted at the same time can produce very different outcomes depending on how they are routed.</p><p>This is where Solana transaction landing performance is decided.</p><h2 id="why-public-rpc-infrastructure-limits-solana-transaction-landing">Why Public RPC Infrastructure Limits Solana Transaction Landing</h2><p>Public RPC endpoints are designed for accessibility, not execution performance. They introduce structural limitations that affect Solana transaction landing speed.</p><h3 id="1-limited-routing-paths">1. Limited routing paths</h3><p>Public RPC nodes forward transactions to leaders, but through a constrained set of routes. If those paths are congested, transactions arrive later than competing flow.</p><h3 id="2-shared-infrastructure">2. Shared infrastructure</h3><p>Traffic from thousands of users competes for the same resources. There is no prioritization for execution-critical transactions.</p><h3 id="3-unstaked-bandwidth">3. Unstaked bandwidth</h3><p>Public RPC nodes forward transactions through connections without stake backed priority. This limits bandwidth and increases delays during periods of high demand.</p><p>For general usage, this is sufficient. For trading, arbitrage, and liquidations, this becomes a limiting factor.</p><figure class="kg-card kg-image-card kg-card-hascaption"><img src="https://p2p.org/economy/content/images/2026/03/solana-transaction-landing-routing-vs-rpc.png" class="kg-image" alt="Solana transaction landing comparison between RPC single path and multi path validator routing" loading="lazy" width="1536" height="1024" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/solana-transaction-landing-routing-vs-rpc.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/solana-transaction-landing-routing-vs-rpc.png 1000w, https://p2p.org/economy/content/images/2026/03/solana-transaction-landing-routing-vs-rpc.png 1536w" sizes="(min-width: 720px) 720px"><figcaption><span style="white-space: pre-wrap;">Solana transaction landing comparison between RPC single path and multi path validator routing</span></figcaption></figure><h2 id="solana-transaction-landing-speed-comes-from-routing">Solana Transaction Landing Speed Comes From Routing</h2><p>The key idea is simple.</p><p>Solana transaction landing speed is determined by routing, not just submission latency. Infrastructure must:</p><ul><li>route through high-priority paths</li><li>reduce contention with shared traffic</li><li>reach the leader through optimal connections</li><li>increase delivery probability under congestion</li></ul><p>This is a network design problem. Not an API problem.</p><h2 id="stake-weighted-qos-and-priority-access">Stake Weighted QoS and Priority Access</h2><p>Solana includes <a href="https://solana.com/developers/guides/advanced/stake-weighted-qos?ref=p2p.org">Stake Weighted Quality of Service (SWQoS)</a>, a mechanism that prioritizes traffic based on validator stake.</p><p>In practice:</p><ul><li>staked connections receive priority bandwidth</li><li>transactions routed through them reach validators faster</li><li>during congestion, this advantage becomes decisive</li></ul><p>SWQoS is a critical factor in Solana transaction landing, especially for execution focused teams. Transactions submitted through unstaked public RPCs compete at a structural disadvantage.</p><h2 id="network-proximity-and-transaction-landing">Network Proximity and Transaction Landing</h2><p>Latency still matters, but not only in geographic terms. Network proximity defines performance:</p><ul><li>direct validator connections</li><li>optimized routing paths</li><li>fewer intermediaries</li></ul><p>Even small differences in latency can determine whether a transaction lands in the first slot or misses the opportunity entirely. Learn more about how <a href="https://docs.solanalabs.com/validator/anatomy?ref=p2p.org">Solana's validator architecture</a> affects transaction delivery.</p><h2 id="multi-path-routing-and-execution-reliability">Multi-Path Routing and Execution Reliability</h2><p>Relying on a single route assumes that the path will succeed. In practice, this is not reliable.</p><p>Multi-path routing improves Solana transaction landing by sending transactions through multiple routes simultaneously:</p><ul><li>current leader</li><li>upcoming leader</li><li>validator level paths</li><li>fallback connections</li></ul><p>The first successful path determines the outcome. This improves consistency and landing probability, especially during congestion.</p><h2 id="from-infrastructure-to-execution-results">From Infrastructure to Execution Results</h2><p>Improving Solana transaction landing requires a Solana sender built with the right infrastructure: one that uses Stake Weighted QoS-enabled paths, routes through validator-level connections, minimizes delays and contention, and supports multi-path delivery.</p><p>Without this, execution strategies are limited by infrastructure performance. <a href="https://www.p2p.org/products/syncro-solana-transaction-sender?ref=p2p.org">Syncro Sender</a> is a Solana sender built specifically for execution critical workflows, using validator-level routing and multi-path delivery to reach the block leader first.</p><p>For a deeper look at how it works, see the <a href="https://p2p.org/economy/solana-transaction-landing-syncro-sender/">Syncro Sender overview</a>.</p><h2 id="what-teams-should-measure-instead">What Teams Should Measure Instead</h2><p>For execution focused teams, this changes how infrastructure should be evaluated.</p><p>Instead of asking: How fast is the endpoint?</p><p>The better question is: How are transactions routed, and do they have priority access?</p><h2 id="apply-this-to-your-own-transaction-flow">Apply This to Your Own Transaction Flow</h2><p>If you are running execution critical workflows on Solana, speed is only part of the equation. The real question is how that speed is achieved.</p><p>Test <a href="https://www.p2p.org/products/syncro-solana-transaction-sender?ref=p2p.org">Syncro Sender</a> alongside your current setup and compare Solana transaction landing performance using real transaction flow. You can get started in minutes via the <a href="https://docs.p2p.org/docs/syncro-sender-quick-start?ref=p2p.org">quick start documentation</a>.</p><h2 id="takeaway">Takeaway</h2><p>On Solana, speed defines execution.</p><p>But speed does not come from sending faster.</p><p>It comes from routing smarter.</p><p>That is what defines Solana transaction landing.</p><h1 id="faq-section">FAQ Section</h1><h2 id="what-is-the-solana-transaction-landing">What is the Solana transaction landing?</h2><p>Solana transaction landing refers to whether a submitted transaction successfully reaches the block leader and is included in a block. It is the key metric that determines execution success on Solana.</p><h2 id="why-do-solana-transactions-fail-to-land">Why do Solana transactions fail to land?</h2><p>Solana transactions fail to land when they arrive too late to the block leader or lose priority against competing transactions. This is often caused by congestion, limited routing paths, or insufficient priority bandwidth.</p><h2 id="what-affects-solana-transaction-landing-speed">What affects Solana transaction landing speed?</h2><p>Solana transaction landing speed is affected by routing paths, validator connections, network congestion, and whether the transaction is sent through a Solana sender with Stake Weighted QoS-enabled infrastructure.</p><h2 id="does-public-rpc-affect-transaction-landing-on-solana">Does public RPC affect transaction landing on Solana?</h2><p>Yes. Public RPC infrastructure can limit Solana transaction landing performance due to shared bandwidth, limited routing paths, and a lack of stake-backed priority connections.</p><h2 id="what-is-stake-weighted-qos-in-solana">What is Stake-Weighted QoS in Solana?</h2><p>Stake-weighted Quality of Service is a mechanism that prioritizes traffic based on validator stake. Transactions routed through staked connections receive higher priority and are more likely to reach the block leader faster.</p><h2 id="why-is-routing-important-for-solana-transaction-landing">Why is routing important for Solana transaction landing?</h2><p>Routing determines how quickly and reliably a transaction reaches the block leader. Even if two transactions are submitted simultaneously, the one with the better routing will be processed first.</p><h2 id="what-is-multi-path-routing-in-solana">What is multi-path routing in Solana?</h2><p>Multi-path routing is the practice of sending a transaction through multiple validator routes simultaneously. This increases the probability that at least one path reaches the leader early.</p><h2 id="how-can-i-improve-solana-transaction-landing-performance">How can I improve Solana transaction landing performance?</h2><p>To improve Solana transaction landing, use a Solana sender that provides validator-level routing, stake-weighted QoS access, optimized network proximity, and multi-path delivery, such as <a href="https://www.p2p.org/products/syncro-solana-transaction-sender?ref=p2p.org">Syncro Sender by P2P.org</a>.</p>
from p2p validator