A v1 Solana transaction would be allowed to lock 96 accounts, not 64
Victoria Shinder1 min readSIMD-0596 proposes raising the maximum number of account addresses a version 1 Solana transaction may reference, from 64 to 96. The limit counts everything in the transaction's account list: signers, program IDs, and both writable and read-only accounts. Legacy and v0 transactions keep the 64-account limit.
The proposal is by Andrew Fitzgerald of Anza, created 11 August 2026, and it extends SIMD-0385. Its motivation is stated plainly: the runtime caps v1 transactions at 64 account locks, and raising the cap lets a transaction reference more accounts while still leaving room for signatures, instructions and instruction data inside the transaction size limit.
⚠ Status is Draft, and the header field for the feature key still carries the placeholder text that is filled in once a proposal is accepted. Nothing here is scheduled.
What it means
Account locks are Solana's concurrency unit, and that is why this number is interesting. The runtime schedules transactions in parallel by looking at which accounts each one writes. A transaction that references more accounts holds more locks, so a higher ceiling lets individual transactions do more — and gives the scheduler bigger, less divisible units to pack.
The limit that actually binds is the transaction size, not the count. The motivation says so: 96 addresses have to fit alongside signatures, instruction data and everything else inside the size limit. Raising the count does not create room; it lets a builder spend the room differently.
Only v1 moves, and the split is the part to note for tooling. Anything constructing legacy or v0 transactions is unaffected. Code that assumes a single account-list ceiling across formats now has two numbers to know.