tx.jup.ag is a Solana RPC-compatible endpoint that forwards your signed transactions to the Solana cluster through Jupiter’s proprietary landing infrastructure, the same stack that powers Jupiter’s own swap products. Point any Solana client at it, authenticate with your Jupiter API key, and call sendTransaction as you would against any RPC node. It accepts any valid signed Solana transaction with a SOL tip.
How it works
tx.jup.ag is Solana RPC-compatible where possible: it implements the standard sendTransaction method, so any Solana client library can talk to it with only an endpoint change. It is send-only, so it does not serve getLatestBlockhash, simulateTransaction, or confirmation queries; keep your usual RPC for those.
- Build your transaction (using
/build, or assemble your own) - Include a SOL tip transfer instruction (minimum 0.001 SOL) to one of 16 tip receiver accounts
- Sign the transaction
- Send it with
sendTransactiontohttps://tx.jup.ag, passing your API key in thex-api-keyheader
/build transactions, use the tipAmount parameter to have the tip instruction included automatically. For non-Jupiter transactions, add a standard SOL transfer instruction to one of the tip receiver accounts.
The request is a standard JSON-RPC call, so any language works:
result. This means the transaction was accepted and forwarded, not that it landed, so confirm on your own RPC. A transaction without a valid tip is rejected with Transaction must include a Jupiter tip instruction.
Requirements
The
sendTransaction config (the second param) takes:
Tips and fees
Every transaction must include the Jupiter tip instruction (minimum 0.001 SOL) or it is rejected. The Jupiter tip is flat: tipping more does not improve landing. Add priority fees when the network is congested. Whether to add a Jito tip depends onswqosOnly:
Code example
Using /build
Use/build with the tipAmount parameter to automatically include a tip instruction in the response.
Adding tip instruction manually
For non-Jupiter transactions (another swap protocol, a program call, a transfer), add a standard SOL transfer to one of the 16 tip receiver accounts. Randomise which account you send to on each transaction to reduce write-lock contention.Best practices
- Randomise tip accounts: there are 16 tip receiver accounts. Randomise which one you send to on each transaction to reduce write-lock contention across concurrent submissions.
- Run in parallel with your own RPC: submitting the same signed transaction through both
tx.jup.agand your existing RPC is a zero-risk way to compare landing. Whichever confirms first wins; the duplicate is dropped by the network. - Poll for confirmation on your own RPC:
tx.jup.agis send-only. Confirm with the blockhash andlastValidBlockHeightfrom your transaction. If the blockhash expires without confirmation, rebuild with a fresh blockhash and resubmit. - Simulate on your own RPC first:
tx.jup.agdoes not simulate, so run any preflight simulation against your own RPC before submitting. - Colocate for lowest latency: Jupiter’s API gateway runs in six AWS regions. Deploy your servers in the nearest region to minimise round-trip time.
Why it lands fast
Jupiter’s transaction landing stack is purpose-built for high throughput and low latency:- Direct to Beam.
tx.jup.agroutes straight to the landing infrastructure. The legacyapi.jup.ag/tx/v1/submitproxies through the API gateway first, sotx.jup.agremoves that hop. - SWQoS via high-stake validator. Jupiter operates one of the highest-staked validators on Solana. Solana’s Stake-Weighted Quality of Service (SWQoS) reserves ~80% of a leader’s TPU capacity for staked validators proportional to their stake. Higher stake means more reserved bandwidth when forwarding transactions to the current leader.
- Beam (custom TPU forwarder). Jupiter’s own TPU client bypasses standard RPC nodes and sends transactions directly to leaders via staked QUIC connections. This removes intermediaries that could be malicious actors and eliminates RPC processing overhead.
- DoubleZero. Dedicated fiber network for validator communication, with FPGA-based spam filtering and transaction deduplication at the network edge. Cleaner transaction set, faster propagation between validators.
- Ultra-low-latency fiber. Private fiber links from Tokyo to Frankfurt reduce physical propagation time between Jupiter’s infrastructure and leader validators globally.
How this differs from /execute
API reference
Endpoint:POST https://tx.jup.ag, JSON-RPC method sendTransaction.
See the transaction submission API reference for the request and response shape.
The legacy REST endpoint
POST https://api.jup.ag/tx/v1/submit still accepts the same signed transactions, but tx.jup.ag is the recommended path going forward.Related
- Build: build custom transactions with
/build(usetipAmountfor automatic tip inclusion) - Order & Execute: the standard swap flow using
/order+/execute - Reduce Latency: use
mode=faston/buildfor faster routing - Latency and Server Locations: API gateway regions and colocation guidance
