Skip to main content
Solana transaction v1 (the “larger transaction sizes” upgrade, SIMD-0385) is live on mainnet. The Swap API builds it on request. v1 is opt-in and the forward path for new integrations. v1 gives you:
  • Bigger transactions: 4096 bytes, up from 1232.
  • No lookup tables: up to 64 accounts inline, so there is nothing to resolve or compile against.
  • Room for your own instructions: CPI, memos, or transfers alongside the swap.

v0 vs v1

Both cap at 64 accounts. v0 reaches that by referencing ALT addresses at 1 byte each; v1 inlines full addresses, which now fit in the larger envelope.

Requesting v1

The parameter differs by endpoint:
  • Router (/build): pass transactionVersion=1 ("0" or "1", default "0"). This forces v1, and you assemble the transaction yourself.
  • Meta-Aggregator (/order): pass maxSupportedTransactionVersion=1 ("0" or "1", default "0"). This is a ceiling, not a force. You get v1 only when Metis wins the route and the order is not gasless; otherwise /order returns v0. Read the response transactionVersion for what you got, and /execute lands either.
Today v1 on /order is supported only on Metis. Other routers return v0 for now, and we are working toward v1 across them, including JupiterZ. Two cases to plan for:
  • Gasless orders are always v0. This includes automatic sponsorship, which can fire for low-SOL takers without you asking, and the integrator payer. An integrator testing with a funded wallet may see v1 while their low-SOL users get v0.
  • A non-Metis win is v0. If another router gives the best price, you get a v0 transaction.
transactionVersion and maxSupportedTransactionVersion are not interchangeable. /order ignores transactionVersion and /build ignores maxSupportedTransactionVersion; the wrong name is silently ignored, with no error.

Response differences

When /build builds v1, the response changes shape: You set the compute unit limit and loaded accounts data size limit yourself. On the Meta-Aggregator, /order returns a built transaction and transactionVersion; sign it and hand it to /execute.

Building a v1 transaction

  • Build, deserialize, and sign v1 transactions with @solana/kit v8 or later (it exposes setTransactionMessageConfig). @solana/web3.js v1 cannot sign v1 transactions.
  • Set the compute budget on the message config, not as instructions: computeUnitLimit, loadedAccountsDataSizeLimit (v1 defaults both to zero, so a transaction without them fails), and the priority fee. As on v0 /build, simulate the transaction to size the compute unit limit rather than hardcoding the maximum.
  • The API returns computeUnitPrice in micro-lamports per CU. v1’s priorityFeeLamports is an absolute lamport total, so convert it:
Not all wallet extensions can sign v1 transactions yet. Requesting v1 for a wallet that does not support it fails at signing. Know which wallets support v1 upfront and request it only for those. This matters most on the Meta-Aggregator path, where the end user’s wallet signs the transaction /order returns.
The compute unit price clamp reads computeBudgetInstructions, which is empty on v1, so it does nothing there. Validate computeUnitPrice against your own ceiling before converting it to priorityFeeLamports.
The example requests v1 from /build, simulates to size the compute unit limit, sets the budget on the config, signs, sends, and confirms.
@solana/kit (v8 or later)
Reading v1 transactions back needs maxSupportedTransactionVersion: 1 on getTransaction and similar RPC calls, or you get an “unsupported version” error. This applies to your confirmation and indexing code too.

When to use v1

Use v1 when you:
  • Hit the 1232-byte size limit, with or without custom instructions.
  • Want to avoid resolving and compiling against Address Lookup Tables.
  • Are building a new integration, since new features target v1.
First confirm your whole signing path supports it:
  • A v1-capable SDK (@solana/kit v8 or later).
  • A wallet that can sign v1 transactions.
  • An RPC that accepts v1 (maxSupportedTransactionVersion: 1 on reads).

Learn more