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. 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.Parameter Changes
GET /order
SettransactionVersion to v1 on GET /order.
GET /quote
SettransactionVersion 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.
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 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 takes the same values (auto, medium, high, veryHigh, or a lamport amount) on both versions.
Reading Transactions
Reading transactions back also changed: passmaxSupportedTransactionVersion: 1 to getTransaction or getBlock to include v1 transactions. See the “For Transaction Readers” section of Solana’s docs.