Solana's biggest change to the transaction format in years reaches mainnet on 9 September. Transaction V1 raises the size limit from 1,232 bytes to 4,096 bytes. It does not raise the number of accounts a transaction may touch, which stays at 64. The proposal that would raise it to 96 has sat unmerged since 11 August, blocked on a question about an older feature gate that has been sitting in Solana's runtime, switched off, for years.
What actually ships on 9 September
Jacob Creech of Anza set the date publicly on 29 August, listing four items: the first step of the rent reduction, Transaction V1 on 9 September, a further cut to slot times with no date attached, and Alpenglow in October.
Transaction V1 is specified in SIMD-0385. The headline number is the size limit. Today every Solana transaction has to fit in 1,232 bytes, and that figure is not a protocol designer's round number. It is a networking artefact, spelled out in the source:
1280 is IPv6 minimum MTU / 40 bytes is the size of the IPv6 header / 8 bytes is the size of the fragment header
1280 minus 40 minus 8 is 1,232. Solana's transaction ceiling has been the size of a packet that is guaranteed to cross the internet without fragmenting. Transaction V1 breaks that tie and sets its own limit of 4,096 bytes, roughly 3.3 times larger.
The new room is meant for things that never fitted before: zero-knowledge proofs, BLS signatures, larger multisignature instructions, cross-chain payloads. Adoption is opt-in. Legacy and v0 transactions keep working exactly as they do now.
The limit that did not move
Read the v1 format's own constants and a second number appears that almost no coverage has mentioned. In message/src/versions/v1/mod.rs:
pub const MAX_TRANSACTION_SIZE: usize = 4096;
pub const MAX_ADDRESSES: u8 = 64;
pub const MAX_INSTRUCTIONS: u8 = 64;
pub const MAX_SIGNATURES: u8 = 12;The transaction gets 3.3 times the space. The address count does not move at all.
That matters more in v1 than it would have in v0, because of a design choice the format made deliberately. The module documentation states that v1 is
designed to enable larger transactions sizes while not having the address lookup table features introduced in v0 transactions
Address lookup tables are how v0 transactions reference many accounts cheaply. The table lives on chain, and the transaction refers to entries in it with one-byte indices. Drop lookup tables and every address has to be carried inline, at the full 32 bytes.
That is the trade Transaction V1 makes: more raw bytes in exchange for the indirection. Which means the address cap and the size cap are now the same conversation, and the arithmetic is unforgiving.
Where the 4,096 bytes go
The fixed header of a v1 message is 41 bytes: a three-byte legacy header, a four-byte config mask, a 32-byte blockhash, and one byte each for the instruction and address counts. Every signature is a further 64 bytes. At the current cap, 64 addresses consume 2,048 bytes, which is exactly half the new limit.
The proposal to raise it to 96
SIMD-0596, opened on 11 August by Andrew Fitzgerald of Anza, would raise the v1 cap from 64 to 96 while leaving legacy and v0 transactions at 64. Its stated motivation is the size budget:
Raising the limit allows v1 transactions to use more accounts while leaving room for signatures, instructions, and instruction data within the transaction size limit.
96 addresses take 3,072 bytes. Subtract the 41-byte header and one 64-byte signature and roughly 919 bytes remain for instructions and their data. That is the reasoning behind the specific number, and it is why 96 rather than a rounder figure.
Fitzgerald noted when opening it that the change is not new thinking. An increase like this, he wrote, has been "considered and discussed for years", and the project was "finally at a point where we think we can activate it soon". Jacob Creech agreed the proposal could skip the usual discussion phase given how much conversation had already happened elsewhere. Another reviewer replied simply, "ship it".
Three weeks later it has not merged.
Why it is stuck
The blockage is not opposition. It is a specification gap, and the review history shows exactly where.
| Date | Reviewer | Affiliation | Outcome |
|---|---|---|---|
| 17 Aug 2026 | ptaffet-jump | Jump | Approved |
| 24 Aug 2026 | bw-solana | Anza | Commented, did not approve |
| 31 Aug 2026 | topointon-jump | Firedancer | "Looks good to me", with a question |
The repository's own bot spelled out the requirement after the Jump approval landed: the proposal cannot merge without an approval from Anza, naming three engineers who can give it. One of those three, bw-solana, is the reviewer who commented on 24 August without approving. The comment is the crux of this article:
we should specify how this interacts with
increase_tx_account_lock_limitfeature. Like does this supersede? override? noop ifincrease_tx_account_lock_limitis active?
A week later Tom Pointon, working on the Firedancer client, arrived at the same place independently: "I'm assuming this will be a new feature gate and we will rip out increase_tx_account_lock_limit?"
Two clients, the same unanswered question. So what is this older feature?
The gate nobody ever switched on
Solana's runtime already contains code to raise the account limit. It is not 96. It is 128, and it has been there long enough that the comment explaining the number points at a project most Solana users have never used:
128 was chosen because it is the minimum number of accounts needed for the Neon EVM implementation.
The runtime picks between the two values at block time:
pub fn get_transaction_account_lock_limit(&self) -> usize {
if let Some(transaction_account_lock_limit) = self.transaction_account_lock_limit {
transaction_account_lock_limit
} else if self.feature_set.snapshot().increase_tx_account_lock_limit {
MAX_TX_ACCOUNT_LOCKS
} else {
64
}
}If the gate is on, the limit is 128. If not, 64. So the obvious question is whether it is on, and that is answerable directly from mainnet rather than from anybody's summary.
What the chain says
The gate's address is 9LZdXeKGeBV6hRLdxS1rHbHoEUsKqesCC2ZAPTPKJAbK. We queried it against mainnet on 2 September 2026, alongside two features that are known to be live, so the comparison is like for like.
| Feature | Account owner | Data | State |
|---|---|---|---|
curve25519_syscall_enabled | Feature program | 9 bytes | Active, slot 275,184,000 |
enable_alt_bn128_syscall | Feature program | 9 bytes | Active, slot 275,616,000 |
increase_tx_account_lock_limit | System program | 0 bytes | Never activated |
An activated feature is owned by the Feature program and carries nine bytes: one flag and an eight-byte slot number recording when it switched on. The account lock gate is owned by the System program and holds no data at all. It has never been assigned to the Feature program, so it was never even queued for activation. It does hold 20,000,000 lamports, 0.02 SOL, which somebody sent it at some point and which has sat there ever since.
Mainnet enforces 64. It always has.
The interaction nobody has specified
bw-solana asked whether the new limit supersedes the old one, overrides it, or does nothing when the old one is active. Nobody in the thread has answered. For v1 transactions specifically, the arithmetic answers part of it, and the answer is more definite than the discussion suggests.
128 addresses at 32 bytes each is 4,096 bytes, precisely the entire v1 transaction. Before a single signature, before the blockhash, before one instruction. A v1 transaction can never reach 128 accounts, so for that format the older gate's value is not a competing limit at all. It is unreachable.
Where the two do collide is everywhere else. Legacy and v0 transactions can reach 128 locks, because lookup tables let them name accounts at one byte each rather than 32. So if both were switched on, the result would be inverted from what anyone would expect: v0 transactions would be allowed to touch 128 accounts, while the newer v1 format capped out at 96.
Why an unspecified limit is a consensus problem, not a tidiness problem
The account limit decides whether a transaction fails sanitization. If two validator clients resolve the limit differently, they disagree about whether a transaction is valid, and therefore about the contents of a block. That is not a bug that produces a wrong number. It is one that produces two chains.
The same week, the same class of problem
On 1 September a different proposal merged into the same repository. SIMD-0607 removed floating point arithmetic from Solana's inflation and rent calculations, because powf and friends are not guaranteed to return bit-identical results across clients and platforms, and those values feed into bank hashes.
The economic effect there was nil, bounded at a relative difference below 2.1e-7. The point was never the money. It was that two clients must compute the same answer.
SIMD-0596 is stuck on the same principle wearing different clothes. Not a disputed number, not a contested design, but an interaction between two rules that has not been written down, raised independently by an Anza reviewer and a Firedancer engineer within a week of each other. Both proposals are artefacts of the same shift: Solana is no longer a network where "whatever Agave does" is a sufficient specification.
What to watch
Transaction V1 activates on 9 September with the address cap at 64. Nothing about SIMD-0596 changes that date, because the proposal is still marked Draft and its feature key field is still a placeholder awaiting acceptance.
The sequence to watch, in order:
| Step | Status as of 2 September 2026 |
|---|---|
| SIMD-0596 specifies the interaction with the old gate | Not done, blocking |
| An Anza approver merges it | Waiting on t-nelson, steviez or bw-solana |
| A feature key is assigned | Placeholder in the document |
| The gate ships in an Agave release | Stable is v4.2.2; v4.4.0-alpha.2 released 28 Aug |
| Validators activate it at an epoch boundary | Network is in epoch 1027 |
As with the disinflation schedule, the useful signal is not a governance headline. It is an Agave release tag and a feature account changing owner.
Market context
SOL traded at $99.64 as of 14:22 UTC on 2 September 2026, down 2.48% over 24 hours, for a market capitalisation of $58.26B. The network was in epoch 1027 at slot 443,718,827. None of the above moves price this week. The rent reduction, which cuts lamports_per_byte from 6,960 toward a target of 696 across five steps, is the change users will actually notice first.
What other coverage left out
Reporting on Transaction V1 has been accurate on the two facts it covers: the 1,232 to 4,096 byte increase, and the absence of address lookup tables. We found no outlet that reported the 64-address cap surviving the upgrade, the proposal to raise it, or the dormant 128-account feature gate. Those are the parts that decide what developers can actually build on 9 September.