Skip to main content
/submit sends your signed transactions through Jupiter’s proprietary transaction landing infrastructure. This is the same infrastructure that powers Jupiter’s own swap products, now open to any integrator. It accepts any valid signed Solana transaction with a SOL tip, costs zero API credits, and works on all plans including keyless access.

Why /submit is competitive

Jupiter’s transaction landing stack is purpose-built for high throughput and low latency:
  • 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.
  • High-performance, scalable infrastructure. Built to handle the volume of Jupiter’s own products, where millions of swaps land daily.

How it works

  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. POST the base64-encoded signed transaction to https://api.jup.ag/tx/v1/submit
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.

Requirements

/submit has its own dedicated rate limit bucket (Keyless 20, Free 50, Paid 100 RPS), separate from your general API limit. See Rate Limits.

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.
  • Use tipAmount with /build: pass tipAmount as a query parameter to have the tip instruction included automatically, rather than adding it manually.
  • Set maxRetries: 0 on RPC fallback: if you run /submit in parallel with sendRawTransaction, let your application control retry logic rather than the RPC node, so you can refresh the blockhash between attempts.
  • Poll for confirmation: use confirmTransaction with the blockhash and lastValidBlockHeight from your transaction. If the blockhash expires without confirmation, rebuild with a fresh blockhash and resubmit.
  • /submit does not simulate: we send directly to the TPU for fastest possible delivery. If you require simulation, do it before making a request to /submit.
  • 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.

How /submit differs from /execute

API reference

Endpoint: POST https://api.jup.ag/tx/v1/submit See the POST /submit API reference for the full specification.