How a Solana transaction actually lands: leaders, shreds, gRPC and Jito

A Solana transaction lands when the current leader receives it, executes it inside one of its slots, and the rest of the cluster votes on the block that contains it. There is no public mempool. Your RPC node forwards the packet straight to the leader over QUIC, the leader streams the block out as shreds through Turbine, and validators replay it and vote. Landing rate comes down to three things: reaching the leader in time, being worth including, and still being valid when you get there.

I build trading bots and run the gRPC and shred infrastructure under them. When a transaction does not land, the cause is almost always somewhere on the path below.

Tap the diagram to jump · ← → to step

1. Step 01Build and sign

   Your bot builds the transaction, attaches a recent blockhash and signs it. The blockhash is the expiry timer: about 150 blocks later the transaction can no longer be included.

2. Step 02Send it

   Solana has no public mempool. You hand the transaction to an RPC node with sendTransaction, or to the Jito block engine as a bundle that carries a tip.

3. Step 03Forward to the leader

   The RPC node reads the leader schedule and forwards the packet over QUIC to the TPU of the current leader and the next ones in line. The block engine forwards winning bundles to leaders that run the Jito client.

4. Step 04Execute and shred

   The leader verifies signatures, orders work by priority fee per compute unit, executes, and records the result in Proof of History. The block leaves as shreds through the Turbine tree while the slot is still running.

5. Step 05Replay and stream

   Validators rebuild the block from shreds and replay it. A node with a Geyser plugin pushes the transaction to its gRPC subscribers at this point. Your bot sees it at processed commitment.

6. Step 06Vote and confirm

   Validators vote on the block. When two thirds of stake has voted for it the transaction is confirmed. When enough later blocks are built on top it is finalized.

← Prev▶ PlayNext →

What happens between sendTransaction and the leader?

Your bot signs a transaction that includes a recent blockhash and calls sendTransaction on an RPC node. By default the node first runs a preflight simulation, then hands the transaction to its send service. The signature you get back is not a receipt. It is the first signature on the transaction you already signed, and it only tells you the RPC node accepted the bytes.

The RPC node then looks at the leader schedule, which is computed ahead of time for the whole epoch, and forwards the transaction over QUIC to the TPU (Transaction Processing Unit) port of the current leader and the leaders coming up next. It keeps rebroadcasting on a timer until it sees the transaction land or the blockhash expires, unless you set maxRetries yourself.

Two things can go wrong here before any fee matters:

• The connection is throttled. Leaders apply stake-weighted quality of service to incoming QUIC connections. Peers with stake get capacity in proportion to that stake, and everyone without stake shares what is left. An unstaked RPC node on a busy day is in the crowded lane.
• The packet arrives late. With slots of about 400 ms and four slots per leader, network distance to the leader is a real part of the budget.

How does the leader decide what goes into the block?

The leader's TPU is a pipeline: fetch packets, verify signatures, schedule and execute, record the results into the Proof of History stream, then broadcast.

The scheduler does not work in arrival order. It ranks transactions by priority, which is roughly the fee paid per compute unit requested. Your priority fee is the compute unit price you set (in micro-lamports) multiplied by the compute unit limit you request, on top of the base fee per signature.

Fee is not the only constraint. Every transaction declares the accounts it will read and write. Two transactions that write the same account cannot run in parallel, and there is a cap on how much compute a single writable account can take in one block. This is why fees are local: a hot pool can be expensive to touch while the rest of the chain is cheap. You bid against everyone else writing to the same pool, not against the whole network.

What are shreds, and why does Turbine matter to a bot?

The leader does not wait for the end of the slot to publish. As it executes transactions it groups them into entries, cuts the entries into small fixed-size pieces called shreds, and sends them out while the slot is still running. Each shred fits in one UDP packet and is signed by the leader. Coding shreds, built with erasure coding, go out alongside the data shreds so a validator can rebuild the block when packets are lost.

Turbine is the protocol that spreads those shreds. Validators are arranged in a layered tree weighted by stake, and each node forwards what it receives to the nodes below it. Your place in that tree and your network distance to the leader decide how early you see a block.

Shreds are the first place a transaction becomes visible to anyone other than the leader. If you receive them directly and decode them back into entries, you see transactions before any node has replayed the block. The trade-off is that you get raw transactions only: no logs, no balance changes, and no confirmation that they succeeded.

Where does gRPC fit in?

A validator or RPC node rebuilds the block from shreds, then replays it, executing every transaction against its own copy of the accounts. Geyser is the plugin interface that lets a node push those updates out as they happen. Yellowstone gRPC is the plugin most providers run. It exposes transactions, account writes, slots and blocks as a filtered stream.

So the order of visibility for the same transaction is:

1. Shreds: earliest, raw, no execution results.
2. Geyser gRPC at processed commitment: slightly later, with full results, logs and account state.
3. WebSocket and polling RPC: later again.

A copy-trading bot that needs to know what a wallet did reads gRPC. A sniper that only needs to know a pool exists can act from shreds.

What does Jito change?

Jito adds a second path to the leader. Instead of sending a transaction to an RPC node, you send a bundle to the Jito block engine. A bundle is a short ordered list of transactions, up to five, that executes in sequence and atomically: either all of them land in the same block, or none do. You attach a tip, which is a plain SOL transfer to one of Jito's tip accounts inside the bundle.

The block engine simulates bundles, runs an auction on the tips, and forwards the winners to the leader. That only works when the current leader runs the Jito validator client. A large share of stake does, but not all of it, so a bundle sent during a non-Jito leader's slots waits for the next one that qualifies.

What you buy with a bundle is ordering and atomicity, plus protection from paying for a failed attempt, because a bundle that would fail is not included. It is not a guarantee. You can still lose the auction.

What do the terms mean?

• Slot: the unit of time in which one leader may produce one block, about 400 ms.
• Leader: the validator assigned to produce blocks for a given slot. The schedule is fixed per epoch and weighted by stake, and each leader gets four consecutive slots.
• TPU: Transaction Processing Unit, the leader's pipeline for receiving, verifying, executing and broadcasting transactions.
• Shred: a packet-sized fragment of a block. Data shreds carry the entries, coding shreds allow recovery of lost data.
• Turbine: the protocol that relays shreds through a stake-weighted tree of validators.
• Geyser / gRPC: Geyser is the validator plugin interface for streaming account, transaction, slot and block updates. Yellowstone gRPC is the common plugin that serves them over gRPC.
• Jito bundle: up to five transactions submitted through the Jito block engine that execute in order, all or nothing, and compete on a tip.
• Priority fee: an optional fee equal to compute unit price times compute unit limit. It raises your rank in the leader's scheduler.

What actually improves landing rate?

In the order I check them on a bot that is missing trades:

1. Keep a fresh blockhash in memory. Do not fetch one per trade. Refresh it in the background and track its last valid block height so you know when to stop retrying.
2. Own the retry loop. Set maxRetries to 0 and resend the same signed transaction on a short interval until you see it confirmed or the blockhash expires. It is the same signature every time, so it cannot execute twice.
3. Get a staked path to the leader. Stake-weighted QoS means a staked connection gets through when an unstaked one is dropped. RPC providers sell this, or you peer your own RPC node with a staked validator.
4. Send on more than one path. RPC, a direct TPU client and Jito can all run in parallel. Keep the Jito tip in a bundle-only transaction, otherwise you can pay the tip on the normal path without the bundle guarantees.
5. Price the fee for the accounts you touch. Query recent prioritization fees for the specific writable accounts in your transaction, not a global average.
6. Request only the compute you need. Simulate, then set the compute unit limit close to actual usage. The priority fee is charged on the limit you request, and an oversized request is harder to fit in a block.
7. Skip preflight on the hot path, on purpose. It saves a simulation before forwarding. It also means a failing transaction can land and cost you the fee, so simulate somewhere else.
8. Put the sender close to the leaders. Network distance is spent out of a 400 ms slot.
9. Measure slot sent against slot landed. Without that number per transaction you are tuning blind.

One caveat: Alpenglow, the consensus redesign validators approved in 2025, replaces Turbine with a protocol called Rotor and changes how blocks are finalized. This page describes the Turbine pipeline. Check which one mainnet runs when you read this.

FAQ

Does Solana have a mempool?

Not a public one. RPC nodes forward transactions directly to the current and upcoming leaders. There is no shared pool of pending transactions that everyone can read.

Why did I get a signature back if my transaction never landed?

The signature is part of the transaction you signed, and the RPC node returns it as soon as it accepts the bytes. It says nothing about inclusion. The transaction may have been dropped before the leader, outbid on the accounts it writes, or expired with its blockhash. Confirm with signature status or a gRPC stream.

Is a Jito tip the same as a priority fee?

No. A priority fee is part of the transaction's fee and is what the leader's scheduler ranks by. A Jito tip is a separate SOL transfer to a Jito tip account, and it only counts in the block engine's bundle auction. A high tip does not help a transaction sent through a normal RPC node.

What is the difference between a shred stream and a gRPC stream?

A shred stream gives you fragments of a block as the leader broadcasts them, before any node has replayed it. It is the earliest signal, with no logs or results. A Geyser gRPC stream comes from a node that has replayed the block, so it arrives a little later and includes status, logs and account changes.

How long is a Solana transaction valid?

Until its recent blockhash expires, which is about 150 blocks after the block that produced the blockhash. In practice that is around a minute. After that you have to sign a new one with a new blockhash.