Solana Sets 9 September for Transaction V1 and a 4,096-Byte Limit

Solana's Transaction V1 format is due to activate on mainnet on 9 September, lifting the maximum serialized transaction from 1,232 bytes to 4,096. Jacob Creech named the date in late August, alongside a staged cut to account rent and an October target for the Alpenglow consensus change. The format has run on testnet since epoch 1025 on 1 September. It is opt-in, and legacy transactions keep working. The people who have to move are the ones reading the chain rather than writing to it.

What fits in 4,096 bytes

The jump is about 3.3x, and the size is the point. A zero-knowledge proof for a confidential transfer, the kind that hides amounts while still proving they balance, no longer has to be split across calls. Large multisigs fit as well; Cryptobriefing puts the practical case at 20 to 30 signers, which covers most institutional treasuries. BLS signature aggregation, used for cross-chain attestations and validator signing, becomes workable inside a single transaction. Two proposals carry the work: SIMD-0296 sets the ceiling and SIMD-0385 defines the v1 message.

Something goes away in exchange. Address Lookup Tables, the mechanism that let a transaction reference accounts by index to stay under the old limit, are not supported in v1. Solana Compass notes that 64 inline addresses come to 2,048 bytes, well inside the new envelope, so at that size the workaround is not needed. Applications now choose a format per transaction.

The changes that fail quietly

Wire-format changes break tooling, and the awkward ones do not throw an error. Solana Compass's migration notes are the only account reviewed here that goes to this level of detail. On its reading, getTransaction and getBlock calls that omit maxSupportedTransactionVersion: 1 come back as error -32015, and blockSubscribe hands a null block to any subscriber without explicit v1 support. The one that costs money is quieter still: indexers scraping ComputeBudgetProgram instructions for fee data will report zero on every v1 transaction, because v1 replaces those instructions with a fixed-offset config mask. The checklist attributes its own summary line to Kendra Ross.

"Agave 4.2 breaks things that don't error," Ross said.

Three accounts, three slot times

The numbers around the upgrade do not settle. crypto.news's 18 August overview of Agave 4.2 describes a 400ms slot baseline stepping down to 200ms. Its own 30 August report says the target had already moved to 350ms, with 300, 250 and 200 to follow. Solana Compass, writing on 29 August, says slots went to 300ms on 28 August. None of the three mentions the others, and we could not establish which value is live today.

Account rent is looser too. The 18 August piece presents SIMD-0437 as one drop from 6,960 to 696 lamports per byte, a 90% cut taking a standard token account from about $0.16 to $0.016. The two later accounts describe five stages instead, the first moving 6,960 to 6,333, roughly 9%. The endpoint matches; the shape does not. That same 29 August piece calls Creech an Anza developer, while crypto.news gives him as the Solana Foundation's vice president of technology.

Who has to move by Wednesday

An opt-in format forces nobody to upgrade on the day, and that is what makes the date awkward. Nothing breaks for a wallet still sending legacy transactions. It breaks for whoever reads those blocks afterwards, a group that runs from RPC providers to explorers to custody systems. Mina's Mesa fork left every zkApp verification key out of date this week and nobody published how many applications were caught by it; the same counting problem sits here. Solana's own governance has been busy elsewhere, with two proposals aimed at cutting SOL emissions still moving through the process. What Wednesday settles is whether the first v1 transactions on mainnet arrive faster than the tools built to read them.