Jito vs TPU Sender vs Staked RPC for Landing Txs
Landing transactions on Solana competitively requires more than a basic sendTransaction call. This page compares three approaches: Jito bundles, direct TPU sending, and staked RPC connections.
Disclosure: This site is affiliated with Supanode. Supanode links on this page are marked. Technical details from Jito documentation and Solana protocol specifications.
Comparison
| Feature | Standard RPC | Staked connections (SWQoS) | Direct TPU | Jito bundles |
|---|---|---|---|---|
| Latency | Highest | Medium-low | Low | Low |
| Priority mechanism | Priority fee only | Stake-weighted QoS | Priority fee | Tip + priority fee |
| Atomicity | Single tx | Single tx | Single tx | Multi-tx bundle |
| MEV protection | None | None | None | Backrun protection |
| Cost | Base fee + priority | Provider fee + priority | Priority fee | Tip + priority fee |
| Reliability | Moderate | High | Variable | High (for tipped bundles) |
Standard RPC sendTransaction
The baseline. Your transaction goes through the RPC node, which forwards it to the current leader’s TPU port.
Limitations: RPC node may not forward efficiently, no prioritization beyond priority fees, subject to network congestion.
Staked connections (SWQoS)
Stake-Weighted Quality of Service gives staked validators priority in the leader’s transaction processing queue. RPC providers that operate staked validators pass this priority to their users.
Best for: consistent transaction landing without tips, production dApps that need reliability without MEV competition.
Direct TPU sending
Send transactions directly to the leader validator’s TPU (Transaction Processing Unit) port, skipping the RPC relay.
Standard: Client → RPC node → Leader TPU
Direct: Client → Leader TPU (direct UDP/QUIC)
Best for: latency-sensitive applications where you manage your own leader schedule tracking and connection pool.
Tradeoff: requires maintaining connections to upcoming leaders and handling the leader schedule yourself.
Jito bundles
Bundle multiple transactions together with a tip for atomic execution. The Jito block engine processes bundles and includes them in blocks produced by Jito-connected validators.
Best for: MEV strategies (arbitrage, liquidations), transaction sequences that must execute atomically, applications competing for the same opportunity.
Decision guide
| Scenario | Recommended approach |
|---|---|
| Standard dApp transactions | Staked connections + priority fee |
| Trading bot (non-competitive) | Staked connections + moderate priority |
| Arbitrage / MEV | Jito bundles + competitive tip |
| NFT mints / token launches | Jito bundles or high-priority staked |
| Transaction sequences (swap + transfer) | Jito bundles (atomic execution) |
FAQ
Can I combine these approaches? Yes. A common pattern sends via Jito for time-critical transactions and falls back to staked RPC for standard operations. Some applications send the same transaction through multiple channels simultaneously.
How much should I tip on Jito? Tips are competitive. For non-competitive transactions, the minimum tip (a few thousand lamports) is often enough. For MEV opportunities, tips scale with the opportunity value. Monitor recent tip levels via Jito’s API.
Is direct TPU sending still effective with SWQoS? SWQoS changes how leaders prioritize incoming connections. Unstaked TPU connections receive lower priority than staked ones. Direct TPU sending remains fast but is most effective when combined with staked connections.
Updated: