Solana Transaction Delivery: The Missing Layer Behind Landing
What actually happens between submission and execution
Speed is often treated as the defining feature of Solana.
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.
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.
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.
Our previous post 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.
Quick Lessons for Builders
Transaction landing depends on delivery, not submission timing
Solana transaction delivery is the process of getting a transaction from submission to the block leader before the slot closes.
Each slot has a designated leader. If your transaction does not reach that leader in time, it does not land.
In practice, four things decide that outcome:
routing path quality
stake-backed priority
delivery strategy (single vs multi-path)
transaction construction
Priority fees affect ordering once the transaction arrives. Compute limits and blockhash freshness affect inclusion.
But none of that matters if the transaction never makes it to the leader.
Why Transactions with the Same Timing Have Different Outcomes
Two transactions sent at the same time do not take the same path.
One may move through prioritized connections with stable bandwidth. Another may compete through shared infrastructure alongside thousands of other transactions.
Under low load, the difference is small.
Under congestion, it becomes decisive.
On Solana, a few milliseconds is not a rounding error. It is the difference between landing in the current slot or missing it entirely.
What Happens Between Submission and the Leader
Once submitted, a transaction is forwarded to current and upcoming leaders via QUIC.
From there, everything depends on:
connection quality
routing efficiency
available bandwidth
With approximately 390ms slot times, the margin for error is minimal.
Most variance does not come from when a transaction is sent. It comes from how it is forwarded under load.
Where Public RPC Falls Short
Public RPC is built for accessibility, not for winning under load.
That tradeoff shows up in three ways:
shared bandwidth with no prioritization
limited control over routing paths
high variability during peak demand
Average performance may look fine. But under real conditions, consistency breaks down, and consistency is what execution depends on.
The Role of Stake-Weighted QoS in Delivery
Stake-weighted QoS operates at the network layer.
Leaders allocate a significant share of bandwidth to staked connections. Transactions using those connections are less likely to be delayed during congestion.
This happens before fees come into play.
Fees decide ordering. Routing decides whether your transaction even gets a chance to be ordered.
Why Connectivity and Network Positioning Matter
With approximately 390ms slots, distance is measured in milliseconds, not in geography.
What matters is:
how many hops your transaction takes
how strong those connections are
how directly you can reach the leader
Because the leader rotates continuously, performance depends on consistent access across the validator set, not proximity to a single location.
Why Single-Path Delivery Breaks Under Load
Single-path delivery relies on one route working.
Under peak demand, that assumption breaks.
If that path is congested or delayed, there is no fallback already in motion. By the time you retry, the slot is gone.
This is where tail latency matters. A system that works most of the time but fails when it matters most is not reliable.
Solana transaction delivery path: single path vs multi-path
What Changes with Multi-Path Delivery
Multi-path delivery changes the model completely.
Instead of relying on one route, transactions are sent across multiple paths at once:
toward current leaders
toward upcoming leaders
through prioritized connections
Whichever path reaches the leader first determines the outcome.
The goal is no longer to hope one path works, but to ensure at least one does.
What Teams Should Measure Instead
If you are measuring performance under average conditions, you are measuring the wrong thing.
What matters is how your infrastructure behaves under stress.
The key metrics:
slot landing distribution
tail latency during congestion
drop rate (submitted vs landed)
performance at peak demand
That is where execution is won or lost.
What Most Teams Misunderstand
The most common mistake is assuming higher fees improve landing probability.
They do not.
Fees only affect ordering after a transaction reaches the leader.
Another misconception is treating a successful submission as success. A response only confirms the transaction was received. It does not confirm that it landed.
And average performance is misleading. On Solana, worst-case outcomes define your edge.
A Practical Step to Improve Delivery
The simplest way to improve performance is to stop relying on a single path.
Adding a parallel delivery route allows you to compare real outcomes under real conditions without replacing your existing setup.
It is a small change that makes delivery visible and measurable.
Where the Ecosystem Is Moving
Execution-focused teams are moving toward delivery-aware infrastructure.
The shift is simple: from sending transactions to controlling how they are delivered.
If you want to understand why routing is the root cause before diving into the system, the previous post 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.
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.
<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>
<h2 id="at-a-glance"><strong>At a glance: </strong></h2><ul><li>TON staking from vesting contracts is now supported via Ledger Wallet using the P2P.org dApp.</li><li>Holders with vested TON can now delegate directly without altering vesting structures.</li><li>The staking flow integrates with standard Ledger self-custody signing workflows.</li></ul><p>Staking TON from vesting contracts is now supported through Ledger Wallet using the P2P.org dApp.<br><br>On the surface, this looks like a product enhancement. In practice, it enables additional participants to access TON’s validator infrastructure through existing vesting contracts.</p><p>Vesting contracts often represent long-term alignment — contributors, early ecosystem participants, and structured allocations tied to roadmap milestones. Until now, participation from those allocations has required additional coordination or operational workarounds.</p><p>This update streamlines the technical integration required for vesting-based delegation.</p><h2 id="vesting-as-active-participation"><strong>Vesting as Active Participation</strong></h2><p>In most ecosystems, vesting allocations sit idle by default.</p><p>They are designed to protect long-term alignment and prevent sudden liquidity shocks. But structurally, they also represent a meaningful portion of circulating supply that is committed to the network over time.</p><p>When vesting allocations can participate in staking, three things happen:</p><ol><li>Long-term holders engage more directly with network security.</li><li>Contributor allocations can participate in protocol-defined staking mechanisms.</li><li>Broader participation may contribute to more distributed delegation patterns within the network.</li></ol><p>It’s about enabling participation from capital that is already committed to the ecosystem.</p><h2 id="how-it-works"><strong>How It Works</strong></h2><p></p><p>The integration enables TON holders with vesting contracts to delegate directly through Ledger Wallet while preserving standard self-custody workflows.</p><p>The process:</p><ul><li>Connect Ledger to the P2P.org dApp.</li><li>Select the vesting contract.</li><li>Initiate staking directly from the vested allocation.</li><li>Confirm through Ledger’s signing interface.</li></ul><p>The staking action becomes part of the same workflow users already rely on for transaction signing and asset management.</p><p>For a detailed walkthrough, refer to the official guide:<a href="https://link.p2p.org/1cd04e?ref=p2p.org">https://link.p2p.org/1cd04e</a> </p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/03/TON7.png" class="kg-image" alt="" loading="lazy" width="2000" height="1500" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/TON7.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/TON7.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/03/TON7.png 1600w, https://p2p.org/economy/content/images/2026/03/TON7.png 2048w" sizes="(min-width: 720px) 720px"></figure><h2 id="what-this-unlocks-for-the-ton-ecosystem"><strong>What This Unlocks for the TON Ecosystem</strong></h2><p>TON’s ecosystem includes:</p><ul><li>Structured token recipients</li><li>Institutional participants</li><li>Early ecosystem supporters</li><li>Long-term contributors</li></ul><p>Many of these participants operate under vesting schedules.</p><p>By enabling staking directly from vesting contracts, the network broadens participation without altering distribution mechanics. Contributors can now align long-term token commitments with active validator support.</p><p>Over time, this supports:</p><ul><li>More distributed delegation patterns</li><li>Greater engagement from aligned stakeholders</li><li>Reinforcement of validator diversity</li></ul><p>It also reflects an ecosystem maturity shift — where staking is expected to integrate cleanly into real custody workflows rather than exist as a separate operational layer.</p><h2 id="wallet-level-participation-as-a-standard"><strong>Wallet-Level Participation as a Standard</strong></h2><p>Ledger Wallet integration is important here not because it adds exposure, but because it anchors staking within a widely used self-custody environment.</p><p>When staking is embedded into wallet workflows:</p><ul><li>Participation becomes routine.</li><li>Operational complexity decreases.</li><li>Reliability expectations increase.</li></ul><p>This is where validator infrastructure becomes directly tied to user experience.</p><p>P2P.org supports TON staking through validator operations designed for continuous, production-grade performance — particularly in flows that integrate at the wallet level.</p><figure class="kg-card kg-image-card"><img src="https://p2p.org/economy/content/images/2026/03/Frame-1410077858-1.png" class="kg-image" alt="" loading="lazy" width="1920" height="1080" srcset="https://p2p.org/economy/content/images/size/w600/2026/03/Frame-1410077858-1.png 600w, https://p2p.org/economy/content/images/size/w1000/2026/03/Frame-1410077858-1.png 1000w, https://p2p.org/economy/content/images/size/w1600/2026/03/Frame-1410077858-1.png 1600w, https://p2p.org/economy/content/images/2026/03/Frame-1410077858-1.png 1920w" sizes="(min-width: 720px) 720px"></figure><h2 id="a-step-toward-broader-participation"><strong>A Step Toward Broader Participation</strong></h2><p>Enabling staking from vesting contracts via Ledger Wallet expands TON’s staking accessibility to long-term, structured participants while preserving the design principles of vesting itself.</p><p>It aligns token distribution mechanics with validator participation.</p><p>And it reflects a broader direction in staking infrastructure — one where participation fits naturally into custody workflows rather than sitting outside them.</p><h2 id="get-started"><strong>Get Started</strong></h2><p>If you hold vested TON and use Ledger Wallet, staking is now available through the P2P.org dApp.</p><p>Read the full guide here:<u> </u><a href="https://link.p2p.org/1cd04e?ref=p2p.org">https://link.p2p.org/1cd04e</a></p><div class="kg-card kg-cta-card kg-cta-bg-grey kg-cta-minimal " data-layout="minimal">
<div class="kg-cta-sponsor-label-wrapper">
<div class="kg-cta-sponsor-label">
<span style="white-space: pre-wrap;">For Wallets and Platforms</span>
</div>
</div>
<div class="kg-cta-content">
<div class="kg-cta-content-inner">
<div class="kg-cta-text">
<p><span style="white-space: pre-wrap;">Teams interested in enabling this functionality can get in touch to explore integration options.</span></p>
</div>
<a href="https://www.p2p.org/products/api?ref=p2p.org" class="kg-cta-button " style="background-color: #000000; color: #ffffff;">
Learn more
</a>
</div>
</div>
</div>
ALL
Agoric
Aptos
Auth
Avail
Avalanche
Axelar
Babylon
Bitcoin
BTC
Cardano
Celestia
certifications
Chainlink
compliance
Cosmos
Crescent
Cyberway
DAOBet
DeFi
defi news
DVT
Dymension
Economy
Education
EigenLayer
Elrond
Ethereum
Evmos
Explain Like I'm Five
Guide
how to
HR
infrastructure
Kava
Kusama
landing
Lido
LSP
Manta
Mantle
Marlin
Matic
Moonbeam
MultiversX
Near
News
NuCypher
Oasis
Origin
Partnership
Persistence
playbook
Pocket
Polkadot
Polygon
product
products
Quicksilver
Regen
regulation
Renzo
restaking
RPC Node
Sender
Serum
slashing
Solana
SSV.Network
Staking
Starknet
Sui
symbiotic
Syncro
syncro sender
Terra
Tezos
TheGraph
Threshold
Update
validator
Vara
vault
Vega
