> ## Documentation Index
> Fetch the complete documentation index at: https://pond.dflow.net/llms.txt
> Use this file to discover all available pages before exploring further.

# V1 Migration Guide

> How to migrate to Solana v1 transactions on the Trading API

DFlow will support the v1 transaction format once Solana activates it on mainnet, targeting Sept 9th. 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](https://solana.com/upgrades/larger-transaction-sizes).

These docs are provided in advance to help users prepare. **We encourage upgrading as soon as possible.**

<Note>
  Integrations that do not set `transactionVersion` continue to receive v0
  transactions.
</Note>

## 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. Priority fees change from a per-compute-unit price to a lamport total, and compute budget configuration moves from ComputeBudget instructions into the transaction message.

|                       | 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                       |
| Priority fee          | Per-compute-unit price             | Total, in lamports             |
| Compute budget        | Set via ComputeBudget instructions | Set in the transaction message |

## Parameter Changes

### GET /order

Set `transactionVersion` to `v1` on [`GET /order`](/resources/trading-api/order/order).

```typescript theme={null}
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`](/resources/trading-api/imperative/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`](/resources/trading-api/imperative/swap).

```typescript theme={null}
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 the message header yourself from `computeUnitLimit`, `loadedAccountsDataSizeLimit`, and `prioritizationFeeLamports` instead.

## Deserializing Transactions

Classic `@solana/web3.js` can read v1 transactions 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](/spot/recipes/quickstart) for a v1 example.

## Priority Fees

In v0, DFlow encodes your priority fee as two values in the transaction: a compute unit limit and a price per compute-unit in micro-lamports. In v1, DFlow encodes the same fee as a single lamport total in the transaction's config. This changes how DFlow constructs the transaction, not how you request one: `prioritizationFeeLamports` on [`GET /order`](/resources/trading-api/order/order) takes the same values (`auto`, `medium`, `high`, `veryHigh`, or a lamport amount) on both versions.

## Reading Transactions

Reading transactions back also changed: pass `maxSupportedTransactionVersion: 1` to `getTransaction` or `getBlock` to include v1 transactions. See the ["For Transaction Readers" section](https://solana.com/upgrades/larger-transaction-sizes) of Solana's docs.

## API Routes

* [GET /order](/resources/trading-api/order/order)
* [GET /quote](/resources/trading-api/imperative/quote)
* [POST /swap](/resources/trading-api/imperative/swap)
* [POST /swap-instructions](/resources/trading-api/imperative/swap-instructions)