- 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): passtransactionVersion=1("0"or"1", default"0"). This forces v1, and you assemble the transaction yourself. -
Meta-Aggregator (
/order): passmaxSupportedTransactionVersion=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/orderreturns v0. Read the responsetransactionVersionfor what you got, and/executelands either.
/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/kitv8 or later (it exposessetTransactionMessageConfig).@solana/web3.jsv1 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
computeUnitPricein micro-lamports per CU. v1’spriorityFeeLamportsis an absolute lamport total, so convert it:
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./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.
- A v1-capable SDK (
@solana/kitv8 or later). - A wallet that can sign v1 transactions.
- An RPC that accepts v1 (
maxSupportedTransactionVersion: 1on reads).
Learn more
Related
- Build: request
transactionVersionand assemble instructions yourself - Order & Execute:
maxSupportedTransactionVersionon the managed path - Reduce Transaction Size: techniques when you still hit limits
