How Solana Shred Forwarding Affects Transaction Landing Rates

If you are submitting transactions through a generic public RPC and wondering why your fill rate is inconsistent, the answer is almost certainly in the propagation path — specifically, in how Solana handles shreds and how far your transaction has to travel before it reaches the validator that matters. Once you understand the shred model, the fix becomes obvious. Most teams just never bother to understand it.

What Shreds Are and Why They Matter

Solana breaks every block into shreds — small fixed-size fragments (roughly 1,228 bytes of data each) that are broadcast via a turbine tree as the leader is actively building the block. The leader does not wait until a block is complete to propagate it. Shreds stream out continuously during the 400ms slot window.

This has a critical side effect for transaction submission: the leader only accepts transactions from its own TPU (Transaction Processing Unit) port, and those transactions must arrive before the leader has moved on. By the time a transaction routes through a shared RPC node, gets relayed to a supermajority stake node, and eventually hops to the leader, a meaningful fraction of your slot window is already consumed. On a congested network, that is the difference between landing in slot N and being dropped or retried into slot N+2.

The Leader Schedule Is Public — Use It

Solana publishes the leader schedule for the entire upcoming epoch (~2.5 days). Every slot is pre-assigned. This is not a secret. You can query it with getLeaderSchedule and know, with full certainty, which validator will produce the next block and the four blocks after that.

The playbook is straightforward:

• Resolve the leader's TPU address from the cluster's gossip data (getClusterNodes maps each validator's identity pubkey to its TPU endpoint).
• Send directly to that TPU port over UDP rather than routing through an RPC node.
• Pre-warm for the next leader — while slot N is being produced, you already know the identity for slot N+4 and can establish the path.

Direct TPU submission cuts one to three network hops. In practice, on a 50ms baseline RPC relay path, direct submission gets you to 10-20ms. That matters enormously when you are racing other bots on a Serum-style order book or sniping a Raydium pool open.

Where Jito Fits

Jito's block engine adds a layer on top of raw TPU submission. Rather than sending a single transaction, you submit a bundle — an ordered, atomic sequence of up to five transactions. The Jito-Solana validator client (now running on a significant fraction of stake-weighted validators) guarantees either the full bundle lands in order or none of it does. This solves the sandwiching and partial-fill problems that make raw TPU submission fragile for MEV-sensitive strategies.

The block engine itself is a relayer: you submit to Jito's regional endpoints, and Jito forwards to the Jito-enabled leader for that slot. The trade-off is a small additional latency hop to Jito's infra versus the tip fee you pay (currently a dynamic auction, usually 10,000–100,000 lamports for competitive slots). For most arb and liquidation bots, this is an extremely favorable exchange.

A practical note: Jito leader coverage is not 100%. You need to detect whether the upcoming slot leader runs Jito-Solana or vanilla Agave, and fall back to direct TPU for non-Jito slots. A production router checks this per-slot.

Colocation and Physical Latency

Geographic proximity to the leader validator is the remaining lever after you have solved the routing problem. Solana's major validators are concentrated in Amsterdam, Frankfurt, New York, and Tokyo data centers. If your bot infrastructure is in AWS us-east-1 and the leading validator for the next 20 slots is co-hosted in Equinix AM3, you are structurally slower than a competitor running bare metal in AMS1.

The numbers are unforgiving: 10ms of additional one-way latency is 2.5% of your entire slot window. At scale, that compounds into measurable fill rate degradation. Teams running latency-critical strategies — especially on high-frequency Hyperliquid perp arbitrage where the Solana leg needs to land fast — typically run forwarding nodes in multiple regions and pick the nearest one to the current leader at submission time.

Preflight and Simulation Trade-offs

One decision that is often made wrong: skipPreflight. Sending with skipPreflight: true avoids the RPC simulation step (which adds 5-15ms) but means failed transactions consume the fee and still count against block capacity. The right policy depends on your transaction's idempotency and how frequently you expect failure.

For bots where the condition is validated off-chain (e.g., you already fetched the on-chain state and ran the check yourself), skip preflight and accept the occasional wasted fee. For anything that touches complex state with high failure variance, simulate locally using a cached account snapshot rather than hitting the RPC — you get the same protection with none of the latency.

Putting It Together: A Realistic Submission Stack

A production-grade submission stack for Solana looks like this:

1. Epoch cache — refresh the leader schedule at epoch boundary, resolve TPU addresses from gossip once per minute.
2. Per-slot routing — determine if the next leader is Jito-enabled; route to Jito bundle endpoint or direct TPU accordingly.
3. Regional forwarder nodes — bare metal or Hetzner dedicated in AMS and possibly FRA, with dynamic selection based on leader location.
4. Retry logic — resend to the next two leaders on confirmation timeout, with exponential backoff capped at two retries before abandoning.
5. Metrics — track slot distance between submission and confirmation. If your p50 is greater than 1.5 slots, something in the stack is wrong.

This is not exotic infrastructure. It is table stakes for any bot that needs to land transactions reliably under load.

---

If you are building on Solana and want a submission stack that is already dialed in, reach out — this is exactly the kind of infrastructure work we handle at TierZero.