V1 Migration Guide

How to migrate to Solana v1 transactions on the Trading API

DFlow supports the v1 transaction format on the Trading API. This guide covers how to migrate existing v0 code to v1, and the differences between the two. For more details, see the official Solana documentation.

We encourage upgrading as soon as possible.

v1 is strictly opt-in. Integrations that do not set transactionVersion continue to receive v0 transactions.

v0 vs v1

v1 increases the transaction size limit from 1232 to 4096 bytes. It removes address lookup tables in favor of inline account addresses and rejects duplicate addresses. Compute budget configuration moves from ComputeBudget instructions into transactionConfig.

	v0	v1
Transaction size	1232 bytes	4096 bytes
Account addresses	64, via lookup tables	64, inline
Address lookup tables	Supported	Not supported
Duplicate addresses	Allowed	Rejected
Compute budget	Set via ComputeBudget instructions	Set in transactionConfig

Conditionally Serving v1 Transactions

Some wallets don’t support v1 transactions yet. Check whether the user’s wallet supports v1. Request v1 if it does and v0 if it doesn’t. A wallet connected through @solana/wallet-adapter reports the transaction versions it supports in adapter.supportedTransactionVersions. If that property is missing, the wallet supports legacy transactions only.

const supportsV1 = wallet?.adapter.supportedTransactionVersions?.has(1) ?? false;

params.set("transactionVersion", supportsV1 ? "v1" : "v0");

Parameter Changes

GET /order

Set transactionVersion to v1 on GET /order.

const params = new URLSearchParams({
  inputMint: "So11111111111111111111111111111111111111112", // SOL
  outputMint: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", // USDC
  amount: "1000000000", // 1 SOL, atomic units (9 decimals)
  userPublicKey: userKeypair.publicKey.toBase58(),
  transactionVersion: "v1",
});

const orderResponse = await fetch(
  `${API_BASE_URL}/order?${params.toString()}`,
  { headers }
).then((x) => x.json());

GET /quote

Set transactionVersion to v1 on GET /quote. This endpoint does not return a transaction; the parameter controls the size limit the route is simulated against, and should match the transactionVersion passed to POST /swap.

const params = new URLSearchParams({
  inputMint: "So11111111111111111111111111111111111111112", // SOL
  outputMint: "EPjFWdd5AufqSSqeM2qN1xzybapC8G4wEGGkZwyTDt1v", // USDC
  amount: "1000000000", // 1 SOL, atomic units (9 decimals)
  transactionVersion: "v1",
});

const quoteResponse = await fetch(
  `${API_BASE_URL}/quote?${params.toString()}`,
  { headers }
).then((x) => x.json());

POST /swap

transactionVersion works the same way as on GET /order, described above.

POST /swap-instructions

Under v1, computeBudgetInstructions in the response comes back empty. Build the compute budget into transactionConfig yourself from computeUnitLimit, loadedAccountsDataSizeLimit, and prioritizationFeeLamports instead.

Deserializing Transactions

Classic @solana/web3.js can read v1 transactions from 1.99.0, but can’t build, sign, or send them. Signing and sending a v1 transaction requires @solana/kit 8.0.0+ (or @solana/web3.js@rc, the emerging v3). See the Send Orders recipe for a v1 example.

Reading Transactions

Reading transactions back also changed: pass maxSupportedTransactionVersion: 1 to getTransaction or getBlock to include v1 transactions. See the “For Transaction Readers” section of Solana’s docs.

API Routes

• GET /order
• GET /quote
• POST /swap
• POST /swap-instructions