JITO · LEADER

Solana transaction sender.

Direct paths to the current leader and the Jito Block Engine, tuned for landing rate - not just submission. Co-located, leader-aware, and you own the retries.

Get started →◢ Join the community

Read the Transaction Sender docs →

◆ OVERVIEW

Sending a transaction is easy; landing it - fast, in the slot you wanted - is the hard part. rpc edge's transaction sender resolves the current and upcoming leaders from the schedule and delivers straight to their TPUs over QUIC, skipping the RPC-forwarding hops that drop transactions under load.

When you need atomicity, ordering, or to bid for inclusion, it submits Jito bundles directly to the Block Engine. Everything runs co-located with the cluster, so the path from your signed transaction to the producing leader is as short as physics allows.

transaction-sender.gauge LEADER-AWARE

// the needle stops at first-seen, then lands - illustrative

◆ CAPABILITIES

What it does.

Direct to the leader

Resolve the leader schedule and deliver to current and upcoming leaders' TPUs over QUIC - fewer hops, fewer drops.

Jito Block Engine path

Submit Jito bundles for atomic, ordered, tip-bid execution - a direct path, no relay, no reseller.

You own the retries

Set maxRetries to 0 and control resubmission within the blockhash window, so you never land a stale action.

Co-located delivery

Every QUIC packet and bundle submission starts next to the cluster, not a region away.

send.ts
// deliver straight to the leaders that build the next slots
const sig = await rpcedge.sendTransaction(tx, {
  route: "tpu",          // current + upcoming leaders' TPUs
  leaders: 3,
  skipPreflight: true,
  maxRetries: 0,         // you control retries
});

// or bid for inclusion with a Jito bundle
const res = await rpcedge.sendBundle({
  transactions: [setupTx, arbTx, cleanupTx],
  tipLamports: estimateTip(),
});

◆ WHY rpc edge

Latency is a location problem.

01

Co-located by design

Our nodes are racked beside Solana stake clusters and the Jito Block Engine. Fewer hops, less distance, lower latency - physics, not promises.

02

Shreds from many sources

We aggregate shreds across multiple upstreams and serve whichever arrives first - so you never wait on a single point of delay.

03

Tuned for HFT

Every node is performance-optimized for high-frequency streaming - kernel, network stack, and RPC layer, end to end.

◆ USE CASES

  • Arbitrage and MEV bundles that must land in a specific slot
  • Liquidations competing for inclusion under congestion
  • Any strategy where landing rate is the bottleneck

◆ RELATED

Frequently asked questions

Why send directly to the leader instead of a normal RPC?
A normal RPC forwards your transaction onward, adding hops and a chance to be dropped under load. Sending straight to the current and upcoming leaders' TPUs gets your transaction in front of the producer that matters, sooner.
When should I use Jito bundles?
Use Jito when you need atomic, all-or-nothing execution, guaranteed ordering, or you're competing in MEV and want to bid for inclusion with a tip. Use direct TPU sending for a single transaction you just want to land fast.

◆ GET ACCESS

Put Transaction Sender on your strategy.

Start free, or talk to the infra team to scope a dedicated, co-located setup tuned to your latency and volume.

Get started →◢ Join the community

JITO · LEADER

  • Direct to the leader
  • Jito Block Engine path
  • You own the retries
  • Co-located delivery