Skip to main content
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.
  1. Build your transaction (using /build, or assemble your own)
  2. Include a SOL tip transfer instruction (minimum 0.001 SOL) to one of 16 tip receiver accounts
  3. Sign the transaction
  4. Send it with sendTransaction to https://tx.jup.ag, passing your API key in the x-api-key header
For /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:
A successful response returns the signature in 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 on swqosOnly:

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.ag and 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.ag is send-only. Confirm with the blockhash and lastValidBlockHeight from your transaction. If the blockhash expires without confirmation, rebuild with a fresh blockhash and resubmit.
  • Simulate on your own RPC first: tx.jup.ag does 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.ag routes straight to the landing infrastructure. The legacy api.jup.ag/tx/v1/submit proxies through the API gateway first, so tx.jup.ag removes 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.