Larger Transaction Sizes

Wallets and applications keep working exactly as they do today. The legacy and v0 transaction formats are unchanged, and nothing about how you approve, sign, or send a transaction changes.

What the upgrade buys you is headroom. Work that previously had to be split across several chained transactions — ZK proofs such as those used by Confidential Transfers, large multisigs, and batched operations — can land as a single atomic transaction. That means fewer signatures to pay for and one confirmation instead of several.

Start by upgrading dependencies (see Support for V1 Transactions), then work through whichever of these describes your application.

If you read or stream transactions — RPC consumers, indexers, explorers, Geyser pipelines (details):

• When fetching data via HTTP RPC call, set maxSupportedTransactionVersion to the integer 1 on getTransaction and getBlock.
• When streaming data via Websockets, set maxSupportedTransactionVersion to the integer 1 on blockSubscribe.
• When streaming block data from Websockets via blockSubscribe, handle the block: null with an error as a failure, not an empty block.
• Update raw transaction decoders to recognize the v1 129 (0x81) version prefix and parse its new layout.
• Regenerate Geyser / gRPC protobuf stubs, then identify v1 from the presence of Message.config before checking the versioned flag.

If you introspect a transaction's compute budget or priority fee — indexers, onchain programs, relayers, paymasters, and anyone who sponsors a fee (indexing details, onchain details, sponsor details):

• When parsing the V1 transaction payload, read transactionConfig instead of introspecting the ComputeBudget instructions.
• Normalize priority fees before comparing across versions: v0 states a price in micro-lamports per compute unit, v1 a total in lamports.

If you want to send V1 transactions (details):

• If you explicitly add ComputeBudget instructions, remove them from your transaction and use the messageConfig instead.
• If you used Address Lookup Tables (ALTs) in V0, remove them from your transaction and place the accounts directly in the instruction (up to 64 accounts) instead.
• Set compute unit limit and loaded accounts data size explicitly (the defaults are zero and your transaction will fail without them).
• Estimate both from one simulation with both limits maxed; round the data size up to the next 32 KiB page.
• Convert priority fees from micro-lamports-per-CU to total lamports.
• Pass encoding: 'base64' when simulating and sending.

The technical details below explain each of these in full. Sample code is available here.

Breaking Change: Reading Transactions and Blocks

Once v1 transactions appear onchain, any RPC consumer that has not opted in starts failing. The fix is one line:

• Pass maxSupportedTransactionVersion: 1 on getTransaction and getBlock. It must be the JSON integer 1, not the string "1".
• Passing 0 or legacy fails on v1 transactions exactly like omitting the parameter.
• The parameter declares the highest version your client can decode, NOT a ceiling and NOT a request for a particular version. Raising it to 1 does not change how legacy and v0 transactions are returned.

How each read surface behaves without the opt-in:

Opted-in responses carry a new transactionConfig object inside the message for v1 transactions (it is absent entirely for legacy and v0):

"message": {
  "instructions": ["… no ComputeBudget instruction here …"],
  "recentBlockhash": "GsdgFbNBoZmAB5uPHfk2xUFYyM4Wg2hYZBfBrxrqjxfF",
  "transactionConfig": {
    "computeUnitLimit": 30000,
    "heapSize": null,
    "loadedAccountsDataSizeLimit": 200000,
    "priorityFee": null
  }
}

Breaking Change: Indexing Transactions

ComputeBudget scanning returns nothing. Any pipeline that derives priority fees or compute unit limits by scanning instructions for the ComputeBudget program will report zero for every v1 transaction, without erroring. In v1 those values live in transactionConfig. This is the most likely path to quietly wrong analytics rather than a loud failure.

Geyser / gRPC streams have no version gate at all. There is no version field in the protobuf. A stale consumer does not error on v1; it silently misreads it as v0 with an empty compute budget. Regenerate your protobuf stubs and detect the version structurally on Message.config, field 7, checking in this order:

The order matters because the versioned boolean is true for both v0 and v1. Testing it first classifies every v1 transaction as v0 — silently, with a zeroed compute budget.

In TypeScript:

function messageVersion(message: Message): "legacy" | "v0" | "v1" {
  if (message.config !== undefined) {
    return "v1";
  }
  return message.versioned ? "v0" : "legacy";
}

And in Rust:

fn message_version(message: &Message) -> MessageVersion {
    match (&message.config, message.versioned) {
        (Some(_), _) => MessageVersion::V1,
        (None, true) => MessageVersion::V0,
        (None, false) => MessageVersion::Legacy,
    }
}

config is a submessage, and submessage fields always carry explicit presence in proto3 — so this check holds however your decoder handles defaults, and whether or not your copy of the schema marks the field optional.

Comparing fees across versions needs normalising. v0 states a priority fee as a price in micro-lamports per compute unit; v1 states a total in lamports. To put both in one dashboard, multiply the v0 price by the compute unit limit the transaction actually requested, then divide by 1,000,000:

20,000 CU × 250,000 micro-lamports/CU = 5,000 lamports   // v0
                                        5,000 lamports   // the v1 equivalent

Sending v1 Transactions

In legacy and v0, setting a resource limit is optional as the runtime provides default fallback values. In v1, omitting it sets the resource limits to zero — and a transaction that cannot run.

A v1 transaction with an empty config fails at account loading with MaxLoadedAccountsDataSizeExceeded, meaning you requested a budget of insufficient bytes. This means: always set the compute unit limit and loaded accounts data size limit explicitly. Simulate once with both limits maxed, read unitsConsumed and loadedAccountsDataSize from the result, and write those into the config (rounding the data size up to the next 32 KiB page, since the block cost model charges in 32 KiB pages and headroom below the next page boundary is free).

Size your data budget with headroom for accounts that do not exist yet. Loading an account is charged 64 bytes of base metadata plus its data length, while an account that does not exist is charged nothing at all, so creating one is a step change from 0 to at least 64 bytes. If an account is created between your simulation and your send, a data size limit measured exactly against simulation can tip over into MaxLoadedAccountsDataSizeExceeded once the transaction reaches the network.

Three more sending changes:

• Priority fee is now a total, not a price. v0 sets micro-lamports per compute unit; v1 sets an absolute total in lamports. Do not carry the per-CU multiplication across.
• ComputeBudget instructions become no-ops. They are neither parsed nor rejected — they execute successfully while doing nothing, burning 150 compute units and an instruction slot. Strip them.
• Use base64 encoding for large transactions. Submitting over 1232 bytes requires encoding: "base64". base58 stays capped at 1232 bytes regardless of transaction version, and was deliberately not raised on deprecation grounds, so the 4096-byte ceiling is only reachable over base64.

Breaking Change: Onchain Introspection of the Compute Budget

A program reads the compute budget today by scanning the Instructions sysvar for ComputeBudget instructions. In v1 those values live on the message, and nothing exposes the message config to onchain code: the Instructions sysvar carries instructions only, no sysvar holds the config, and no syscall returns it.

ComputeBudget instructions in a v1 transaction are not rejected; they execute as no-ops, meaning their internal set values are no longer reliable. At present there is no sysvar to determine a transaction's version or to extract the message config. This means that program should stop gating on introspected ComputeBudget Instructions once v1 transactions are live.

We are evaluating additional options. Check back here for updates.

Breaking Change: Sponsoring and Co-Signing Transactions

If you co-sign, sponsor the fee for, or verify a transaction somebody else built (e.g., relayers, paymasters, and gasless backends):

• Detect the version before you gate on anything. Unlike a program, a server can always tell what it is holding. Decoding the base64 a payer hands you yields the version directly the message's first byte is 0x81 for v1.

• For v1 transactions, read the priority fee and compute limits from transactionConfig, not from ComputeBudget instructions. Priority fees are a total in lamports, not micro-lamports per CU. The same decode that gave you the version gives you the config. Note: no-op ComputeBudget instructions can exist on a V1 instruction. These have no relevance to actual v1 resources requested. They should be disregarded.

• Pass maxSupportedTransactionVersion: 1 on getTransaction and getBlock. It is a ceiling, not a suggestion: leave it at 0 and reading back a v1 transaction fails with -32015 while the transaction itself is onchain.

The compute unit limit, loaded accounts data size limit, and heap size setters work for messages of any version. Priority fees differ: v1 stores a total in lamports, while legacy and v0 use micro-lamports per compute unit. Use setTransactionMessagePriorityFeeLamports for v1 and setTransactionMessageComputeUnitPrice for legacy and v0; Kit enforces this distinction with its types.