Skip to content

docs: [transaction] document tx.jup.ag Solana JSON-RPC submission endpoint#934

Open
0xanmol wants to merge 7 commits into
mainfrom
docs/beam-tx-jup-ag-submit
Open

docs: [transaction] document tx.jup.ag Solana JSON-RPC submission endpoint#934
0xanmol wants to merge 7 commits into
mainfrom
docs/beam-tx-jup-ag-submit

Conversation

@0xanmol

@0xanmol 0xanmol commented Jul 9, 2026

Copy link
Copy Markdown
Member

What

Beam v2 exposes transaction landing as a Solana JSON-RPC sendTransaction endpoint at https://tx.jup.ag. This rewrites the transaction submission docs around it: point any Solana client (@solana/web3.js Connection or @solana/kit) at tx.jup.ag, authenticate with the x-api-key header, and send. The legacy REST POST api.jup.ag/tx/v1/submit still works and is kept as a <Note>.

Confirmed against the jup-ag/beam source (beam_cli, scripts/beamv2-testscripts/) and live probes.

Changes

  • transaction/submit.mdx — rewritten around tx.jup.ag. Kept the 7-step web3.js/kit examples; only the submit step changes (RPC client pointed at tx.jup.ag with x-api-key). Documents it as send-only (keep your own RPC for blockhash + confirmation).
  • openapi-spec/transaction/transaction.yaml + api-reference/transaction/submit.mdx — reshaped from a REST body to the JSON-RPC envelope; server tx.jup.ag; optional auth (keyless allowed).
  • changelog/index.mdx — July 2026 entry.
  • swap/index.mdx, portal/rate-limits.mdx — endpoint identity updated to tx.jup.ag.
  • .claude/rules/* — recorded the convention change (supersedes the 2026-04-07 REST-URL guidance) and the open questions below.

Verification

Live mainnet transaction through tx.jup.ag using the exact documented web3.js flow:

  • Tx 41Zdsg…L6KEperr: null, confirmed
  • Tip of exactly 1,000,000 lamports (0.001 SOL) routed to HFqp6… (one of the 16 documented tip accounts)
  • Auth probes: no x-api-key = keyless (accepted), invalid key = 401, getHealth = "Method not found" (send-only)

Open questions for reviewers

  1. Does the Swap API-key permission map to the tx.jup.ag host? Left portal/api-keys.mdx's "Swap covers /tx/v1/submit" line unchanged pending confirmation.
  2. Are the dedicated rate-limit bucket RPS numbers identical on tx.jup.ag? (Assumed yes — same gateway.)
  3. Deprecation timeline for the REST POST /tx/v1/submit.

Follow-ups (not in this PR)

  • Update the /build code examples in swap/build/index.mdx and the mention in swap/quote-and-swap.mdx once tx.jup.ag is confirmed GA (they use the still-working legacy REST endpoint).

🤖 Generated with Claude Code

…point

Beam v2 exposes transaction landing as a Solana JSON-RPC sendTransaction
endpoint at tx.jup.ag. Point any Solana client at it with the x-api-key
header instead of POSTing to the REST /tx/v1/submit (kept as legacy).
Verified end-to-end with a live mainnet transaction.
@mintlify

mintlify Bot commented Jul 9, 2026

Copy link
Copy Markdown

Preview deployment for your docs. Learn more about Mintlify Previews.

Project Status Preview Updated (UTC)
Jupiter 🟢 Ready View Preview Jul 9, 2026, 6:30 AM

💡 Tip: Enable Workflows to automatically generate PRs for you.

Both verified against tx.jup.ag with live transactions: the @solana/kit
send path lands, and a tip-less transaction returns "Transaction must
include a Jupiter tip instruction".
@0xanmol

0xanmol commented Jul 9, 2026

Copy link
Copy Markdown
Member Author

Verified the primary /build example end-to-end against the live endpoint, not just a memo transaction:

  • Real SOL→USDC swap built with /build (tipAmount), submitted through tx.jup.ag, confirmed on-chain: 2uv3LT…0.3916 USDC received.
  • Both SDK send paths land: @solana/web3.js sendRawTransaction and @solana/kit sendTransaction.
  • Missing tip is rejected with Transaction must include a Jupiter tip instruction (now documented).

The documented flow is validated by real swaps producing token output.

sendAndConfirmTransaction and sendYoloModeTransaction are role-gated to
internal callers (-1012 Access denied with an external key); only
sendTransaction (and sendJitoBundle) are available externally. Drop the
sendAndConfirmTransaction mention from llmsDescription and record the
verified access matrix.
The 20/50/100 dedicated bucket in the api-gateway quota.toml is keyed by
the REST paths /tx/v1/submit and /swap/v2/submit on api.jup.ag. tx.jup.ag
is a separate direct-to-beam load balancer, not fronted by that gateway,
so it does not inherit the bucket. Revert the mistaken tx.jup.ag
relabelling on the rate-limits page and scope the submit.mdx note to the
REST path.
@0xanmol

0xanmol commented Jul 9, 2026

Copy link
Copy Markdown
Member Author

Correction to open question #2 (rate limits), verified in developer-platform:

My earlier "assumed yes, same gateway" was wrong. The 20/50/100 dedicated bucket lives in api-gateway/auth-service/config/quota.toml, keyed by the REST paths /tx/v1/submit and /swap/v2/submit on host api.jup.ag (which the gateway rewrites to tx.juprpc.com/submit). tx.jup.ag is a separate direct-to-beam load balancer and does not appear in that repo, so it is not fronted by this gateway and does not inherit the bucket.

Fixed in the docs: reverted the tx.jup.ag relabel on the rate-limits page, and the submit page now scopes the bucket to the REST path and notes tx.jup.ag routes around the gateway.

Still open (for whoever owns the tx.jup.ag LB / cloud-compute-infrastructure): what are tx.jup.ag's actual rate limits? Docs won't state a number until confirmed.

Per Kyle/groovie in-thread: advertise only sendTransaction (sendJitoBundle
is internal-only, sendAndConfirmTransaction is being deprecated); tx.jup.ag
will require an API key, so drop the keyless advertising and make the
OpenAPI auth required; rate limits are a single anti-abuse limit across all
tiers with the number still TBD, not the tiered REST buckets.
groovie confirmed the beam require_role(Internal) check. My earlier probe's
-32602 on sendJitoBundle was a params-deserialization error before the role
gate, not proof of external access. Only sendTransaction is external.
…yet)

Verified with real funds: a valid signed swap sent with no x-api-key
landed + finalized, same as the keyed send. The API-key requirement Kyle
described is not live yet; docs advertise it as forward guidance.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant