Sending is easy. Landing is the job.
Any RPC endpoint will accept your sendTransaction call. Whether that transaction actually lands -
in the slot you wanted, before a competitor's - is a different question entirely. On a busy network,
the gap between "submitted" and "landed" is where strategies live or die.
To close that gap you have to think like the network does: about who's producing the next block, how it picks what to include, and how your bytes physically get there.
The leader schedule is your map
Solana doesn't choose a block producer at random each slot - the leader schedule is known for the whole epoch in advance. At any moment you can compute which validator is the current leader and which validators lead the next several slots.
That's a gift for transaction delivery: you don't have to broadcast and hope. You can send your transaction directly to the current leader and the next few upcoming leaders, so whoever produces the next block already has it in hand.
You always know who's about to build the next block. Landing fast is mostly the discipline of sending straight to them instead of broadcasting and hoping.
The TPU: the door to the leader
Each leader exposes a TPU - Transaction Processing Unit - the ingress that accepts transactions over QUIC. A naive path bounces your transaction through an RPC node that forwards it onward; every hop is time and a chance to be dropped under load.
A purpose-built sender skips the detour: it resolves the current and upcoming leaders from the schedule, opens QUIC connections to their TPUs, and delivers directly. Fewer hops, less distance, and your transaction is in front of the producer that matters.
// deliver straight to the leaders that will build the next slots
const sig = await rpcedge.sendTransaction(tx, {
route: "tpu", // direct to current + upcoming leaders' TPUs
leaders: 3, // fan out to the next few producers
skipPreflight: true, // you already simulated; don't pay for it again
maxRetries: 0, // you control retries; see below
});Three reasons transactions don't land
Most "my transaction vanished" stories come down to one of these:
| Cause | Fix |
|---|---|
| Expired blockhash | A blockhash is valid ~150 slots (~60–90s). Fetch a fresh one and submit promptly |
| Priority fee too low | Under congestion, leaders prioritize by compute-unit price - bid appropriately |
| Never reached the leader | Deliver directly to the current/upcoming leaders' TPUs instead of forwarding |
Get all three right and your landing rate stops being a mystery.
Priority fees: buying your place in line
When a leader has more transactions than it can fit, it orders by priority fee - the compute-unit price you attach. A higher fee raises your position in that prioritization. It doesn't guarantee inclusion, and overpaying is just a donation, so the goal is to fee dynamically: read current network conditions and set a competitive-but-not-wasteful compute-unit price per transaction.
Priority fees and direct delivery are complementary. The fee improves your standing once your transaction is in front of the leader; direct TPU delivery is what gets it there in the first place.
When you need Jito: bundles, ordering, and the auction
Direct TPU sending is the right tool for a single transaction you just want to land fast. But some strategies need more than speed - they need atomicity and ordering. That's the Jito Block Engine.
A Jito bundle is a set of transactions that execute all-or-nothing, in the exact order you specify. You attach a tip to a Jito tip account, and the Block Engine runs an auction - the highest-tipping bundles win inclusion and ordering. That's the mechanism behind competitive MEV on Solana: you're not just sending, you're bidding for the right to be included exactly how you want.
// atomic, ordered, tip-bid execution via the Jito Block Engine
const result = await rpcedge.sendBundle({
transactions: [setupTx, arbTx, cleanupTx], // all-or-nothing, in order
tipLamports: estimateTip(), // bid for inclusion
});Reach for Jito when you need atomic multi-transaction execution, guaranteed ordering, or you're competing for inclusion and want to bid. Reach for direct TPU when you just need one transaction to land fast and cheap.
Retries are a strategy, not a default
Blindly retrying a transaction can mean paying twice or landing a stale action. A good sender gives
you control: resubmit the same signed transaction to fresh leaders within the blockhash window,
stop the moment it lands or the blockhash expires, and never silently re-send something your
strategy no longer wants. Set maxRetries: 0 on the RPC and own the retry loop yourself.
Land transactions like you mean it.
rpc edge's transaction sender delivers to current and upcoming leaders' TPUs and the Jito Block Engine - co-located, tuned for landing rate.
Location, again
Every part of this is a delivery race, and delivery races are won by proximity. A sender a region away from the leaders is paying network distance on every QUIC packet and every bundle submission. rpc edge runs its transaction sender beside Solana stake clusters and the Jito Block Engine, so the path from your signed transaction to the producing leader is as short as physics allows.
The takeaway
Treat sending as a delivery problem. Use the leader schedule to send straight to the producers that matter, fee dynamically so you earn your place in line, and reach for Jito bundles when you need atomicity, ordering, or to bid for inclusion. Own your retries, and put the sender next to the cluster. That's the difference between hoping a transaction lands and engineering it to.