Jupiter's Swap API Adds Opt-In Solana Transaction v1 Support for Integrators

Jupiter JUP$0.246-10.7% has opened Solana's larger transaction format to the apps, wallets and trading bots that build on its Swap API. Jupiter's developer account announced on October 7, 2026 that "Solana transaction v1 is now live on Jupiter's Swap API", available on request, with the older v0 format staying the default.

Transaction v1 raises the size limit of a single Solana transaction from 1,232 bytes to 4,096 bytes, according to Jupiter's transaction versions documentation. It also drops address lookup tables (ALTs), the on-chain tables that v0 transactions use to point at accounts by a short index, and lists up to 64 accounts directly in the transaction. Every pool a swap route touches adds accounts and instruction data, so the byte limit caps how elaborate a single-transaction route can be. Jupiter's post put the benefit as "complex routes fit in a single tx".

Jupiter's own products moved first. The jup.ag swap interface and the Jupiter Wallet extension began using v1 on September 28, 2026. The Swap API step extends the same format to third-party integrators, who decide for themselves whether to request it. Jupiter has not published how many integrators or how much volume use v1. For a sense of the traffic involved, Solana Compass data shows transactions involving Jupiter's v6 aggregator program carried about $24.5 billion of spot swap volume across roughly 119 million swaps between September 7 and October 6, 2026, in both transaction formats combined.

How integrators request v1: transactionVersion on /build, maxSupportedTransactionVersion on /order

Jupiter's Swap API has two entry points, and each opts in to v1 with a different parameter. On /build, which returns the pieces of a swap for the integrator to assemble, transactionVersion=1 forces a v1 transaction. On /order, where several routers compete to fill a request, maxSupportedTransactionVersion=1 sets a ceiling. It tells Jupiter the integrator can accept v1 without guaranteeing one comes back.

The two names cannot be swapped, and Jupiter's docs warn that a mistake produces no error.

An integrator who sends the wrong parameter keeps receiving v0 transactions and may not notice.

On /order, the docs say a v1 transaction comes back "only when Metis wins the route and the order is not gasless". Metis is one of the routers behind /order, and the docs add that "other routers return v0 for now". Gasless orders, where someone other than the trader pays the network fee, are always v0. That includes Jupiter's automatic fee sponsorship for wallets holding little SOL, which leads to a testing gap the docs spell out: "An integrator testing with a funded wallet may see v1 while their low-SOL users get v0."

What changes inside a v1 swap: compute budget, priority fees and @solana/kit v8

A v1 transaction sets its resource requests in a different place. In v0, a transaction declares its compute limit and priority fee through separate ComputeBudgetProgram instructions. In v1 those settings sit in the transaction's own configuration, and Jupiter's /build response changes to match: the compute budget instructions and the lookup table map come back empty, and a new computeUnitPrice field carries the price in micro-lamports per compute unit.

The integrator then has to set the compute unit limit, the loaded account data size limit and the priority fee on the message. Jupiter's docs note that v1 defaults the two limits to zero, so a transaction built without them fails. The priority fee is also expressed differently, as a total in lamports. The conversion in the docs is the compute unit price multiplied by the compute unit limit, divided by 1,000,000 and rounded up.

Signing needs newer tooling. Jupiter's docs list @solana/kit v8 or later as the only supported SDK for v1 and state that "@solana/web3.js v1 cannot sign v1 transactions". The Solana Foundation's larger transaction sizes upgrade page also lists @solana/web3.js 3.0.0-rc.3 or later, the Kit-based rebuild of web3.js announced on October 6, 2026, as a minimum version for the format.

Wallets are the other dependency. "Not all wallet extensions can sign v1 transactions yet," the docs say, and a v1 request for a wallet without support "fails at signing". Jupiter Wallet has signed v1 since the September 28 release, and Backpack added v1 signing on October 2, 2026.

Why v0 remains the Swap API default after Solana's September 15 activation

Transaction v1 has been usable on Solana for just over three weeks. The Solana Foundation's upgrade page records that the feature gate activated on mainnet at the start of epoch 1035 on September 15, 2026, at about 01:00 UTC, which we covered at the time. Two proposals sit behind the change: SIMD-0296 for the size increase and SIMD-0385 for the v1 format.

Sending v1 is optional at the protocol level, and Jupiter's API follows that. Reading is a different matter. Anza, the core developer team that announced the activation, wrote on September 15, 2026 that apps reading blocks or transactions over RPC must pass maxSupportedTransactionVersion: 1. "Without it, one V1 transaction fails the entire call," Anza wrote. Jupiter's docs repeat the requirement for integrators that read their own v1 swaps back with getTransaction and similar calls.

Jupiter's docs describe v1 as "opt-in and the forward path for new integrations" and say "new features target v1". They recommend it for integrators hitting the 1,232-byte limit, for those who want to stop resolving lookup tables, and for new builds, after checking that the SDK, the user's wallet and the RPC provider all handle the format. Each of those sits outside Jupiter's API, and existing integrations keep working on v0 until their operators choose to move.