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

# Transactions

> v1 transactions, the compute budget in the header, priority fees, tips and the cost estimate.

## v1 only

Every transaction the router builds is **v1** ([SIMD-0385](https://github.com/solana-foundation/solana-improvement-documents/pull/385), active on mainnet since slot 447,120,000). There is no v0 and no legacy form: `txVersion: 0` and `asLegacyTransaction: true` answer `400`.

| v1 | |
| - | - |
| Size | Up to 4,096 bytes |
| Accounts | Up to 64 distinct keys, no address lookup tables (`addressLookupTableAddresses` is always `[]`) |
| Compute budget | In the message header, not as instructions (`computeBudgetInstructions` is always `[]`) |

<Warning>
  The user's signer must be able to sign v1 transactions. Check your SDK before you integrate: older `@solana/web3.js` 1.x releases can read v1 but cannot build or sign it. Use a v1-capable SDK (for example `@solana/kit` 8 or later).
</Warning>

## Getting a transaction

The build answers instructions by default. Two ways to a transaction:

* **Let the router serialize it**: send `"serialize": true`. You get `swapTransaction` (base64, unsigned) and `lastValidBlockHeight`. The blockhash is the router's, at most a few seconds old; send before it expires.
* **Assemble it yourself**: put `setupInstructions`, then every instruction of `swapInstructions`, then `cleanupInstruction`, then `otherInstructions`, and set the header from `transactionConfig`. Or post them to [`POST /tx/v1`](/api-reference/router/tx-v1), which serializes any instructions you give it as an unsigned v1 transaction (useful to add your own instructions).

The swap instruction has no deadline of its own: only the blockhash expires the transaction.

## Compute budget

`transactionConfig` carries what goes in the v1 header:

| Field | Meaning |
| - | - |
| `computeUnitLimit` | Compute units the transaction declares, sized from the route |
| `loadedAccountsDataSizeLimit` | Bytes of accounts the transaction may load |
| `priorityFeeLamports` | The **total** priority fee, in lamports |
| `heapSize` | When the route needs more heap |

A limit left out of a v1 header counts as **zero**, not as a default: keep every field the router gives you. The compute-unit limit is sized from the route's steps (`walkSteps` in the quote); if you strip `walkSteps` from a `quoteResponse`, the build declares the maximum for those hops and you pay priority fee on it.

## Priority fee

The first of these that the build body sets decides the fee:

| Field | Value |
| - | - |
| `prioritizationFeeLamports` | A number: the total in lamports |
| `computeUnitPriceMicroLamports` | Micro-lamports per compute unit |
| `prioritizationFeeLamports: "auto"` | The chain's recent 75th percentile, clamped between 10,000 and 1,000,000 micro-lamports per unit |
| `prioritizationFeeLamports: {"priorityLevelWithMaxLamports": {"maxLamports": N}}` | Same as `auto`, at most `N` lamports |

Nothing set means no priority fee: absent is not `auto`. The fee is charged on the declared compute-unit limit, not on the units the swap ends up using. `costs.priorityFeeSource` says where the number came from (`client`, `chain`, `floor`, `ceiling`, `none`).

## Tips

* `prioritizationFeeLamports: {"jitoTipLamports": N}` adds a transfer of `N` lamports to a Jito tip account in `otherInstructions` (and no priority fee from that field).
* `tipWallet` + `tipLamports` tip any wallet you choose, and win over the Jito field.

## What the user pays

`costs` estimates the lamports the transaction costs the user, as decimal strings:

| Field | |
| - | - |
| `baseFeeLamports` | 5,000 per signature |
| `priorityFeeLamports`, `priorityFeeMicroLamportsPerCu`, `priorityFeeSource` | The priority fee |
| `tipLamports` | The tip |
| `rentLamports`, `rentRefundedLamports` | Rent of accounts the setup creates, and rent returned by the closes |
| `totalLamports` | Base + priority + tip + rent − refunded |

`rentLamports` is an **upper bound**: it counts every account the setup creates as if the user had none of them. A user who already has the token account pays less.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.