Reduced exposure toMEV.
Standard transaction submission goes through an RPC operator. That operator can read your transaction before it lands — and some forward pending transactions to MEV searchers who front-run or sandwich you. Private send skips the RPC layer entirely: your signed transaction goes straight to the current slot leader. RPC operators never see it, so they can't leak it.
Direct-to-leader submission — also known as TPU send — has been an option for advanced Solana clients for a while. Private send packages it as a one-flag option on a hosted endpoint.
One flag. Different path.
// Sign the transaction with your wallet — same as always.
const signed = wallet.sign(tx);
// POST to /v1/send with one extra header.
const res = await fetch('https://api.venum.dev/v1/send', {
method: 'POST',
headers: {
'X-API-Key': process.env.VENUM_API_KEY,
'X-Senders': 'tpu', // ← skip every channel except direct-to-leader
'Content-Type': 'application/json',
},
body: JSON.stringify({ transaction: signed.toBase64() }),
});
const { signature } = await res.json();
// Track exactly like a normal send — same lifecycle stream.
// Or use exclusion form for "everything except RPC operators":
// X-Senders: -rpc
// Channels: tpu, jito, secondary, rpc. Empty header = all (default fan-out).What gets closed off.
You build and sign your transaction with your own keys. Same as any Solana flow — no key custody, no signing service.
The signed bytes go straight to the current slot leader's submission port. RPC operators are not on the path — they never receive a copy of your transaction.
The leader includes your transaction in the next block they produce, exactly like any other transaction. From the chain's perspective, the result is identical.
Track confirmation through /v1/stream/tx or /v1/tx/:signature — same surface as Fast Send. The only difference is the submission channel.
No overclaims.
A standard RPC operator can choose to forward pending transactions to MEV searchers. Private send removes the operator from the path entirely — there is nothing for them to leak.
Solana doesn't expose a public mempool, but RPC operators effectively act as one. Direct-to-leader skips that quasi-public surface.
Same endpoint, same wire format. Add an X-Senders: tpu header and the submission channel changes — no SDK swap, no separate URL.
Same endpoint. Different trade-off.
| Dimension | Private send · X-Senders: tpu | Fast Send · /v1/send |
|---|---|---|
| Path to leader | Direct submission to slot leader | Through RPC operator first |
| Operator visibility | Operator not on the path | Operator can read pending tx |
| Searcher front-run via RPC | Closed off | Possible if operator forwards |
| In-block reorder protection | Not provided (use bundles for that) | Not provided |
| Atomic multi-leg semantics | Not provided (use bundles) | Not provided |
| Fallback if leader misses | No fallback (single channel) | Multi-RPC retry standard |
| Tip required | No | No |
| Use case | Single-tx submissions where RPC-layer leakage is the main concern | High-availability landing across many channels |
Use Private Send when RPC-layer leakage is the dominant concern (most retail-side MEV). Use Fast Send when landing rate is the dominant concern (high-availability flows). Both run through /v1/send — the X-Senders header is the only difference.
Common questions.
How does private send actually reduce MEV exposure?
Is this the same as a Jito bundle?
Does it prevent every kind of MEV?
How is the landing rate compared to a standard RPC submission?
How do I use it?
Is private send available on every tier?
Ship it with one flag.
Get a free Venum API key, point your existing /v1/send call at it, and add X-Senders: tpu. Same wire format. Different path.