More Accounts per Transaction
October 2026 • Solana Foundation
Every transaction names the accounts it reads or writes, plus its signers and program IDs. That list is capped at 64 entries today. For v1 transactions the cap rises to 96, a 50% increase.
The higher limit matters when one atomic operation touches many accounts. A swap router can route through more liquidity pools in a single transaction, which opens up more complex routes and potentially better execution prices. Legacy and v0 transactions stay at 64 accounts. A separate change raises how deeply programs can call each other; see Deeper CPI Nesting.
| Expected Mainnet Activation Date | After Agave 4.5 (tentative); date to be determined |
| Devnet Activation | Not yet testable. SIMD-0596 is a draft, no feature gate exists, and no Agave release includes it |
| Breaking Change? | No |
| Indexing Changes Required? | Yes, for decoders that cap v1 transactions at 64 accounts |
| Feature Gate | To be determined |
| Proposal | SIMD-0596 |
Does This Affect Me?
For UsersNo action needed.+
Nothing changes about how you use wallets or applications.
For DevelopersNothing breaks onchain. SDKs, decoders, and wallets that hardcode 64 need an update before anyone can use 96.+
Transactions that fit in 64 accounts keep working unchanged, in every format. The extra room is opt-in and only available in the v1 format.
| If you | Breaking? | What you have to do |
|---|---|---|
| Send legacy or v0 transactions | No | Nothing. They stay at 64 accounts. |
| Need more than 64 accounts in one transaction | No | Build v1 transactions. After activation they can name up to 96 accounts. |
| Use address lookup tables to fit many accounts | No | Consider moving to v1. It has no lookup tables, but 4096 bytes and 96 accounts cover most cases that needed them. Optional; v0 keeps working. |
| Maintain an SDK or library that builds or decodes v1 transactions | Yes | Raise any hardcoded limit before activation from 64 to 96. |
| Build v1 transactions with an SDK like Kit | Check | Update your dependencies once your SDK ships 96-account support. Older versions reject valid transactions above 64 accounts. |
| Index, explore, or reconcile transactions | Yes | Decoders that stop at 64 accounts will silently drop or misparse larger transactions. Update before activation. |
| Build hardware wallets or signing devices | Check | More accounts means a longer message to display and hash. It stays within v1's 4096 bytes, but firmware that caps the account count needs an update. |
| Rotate fee wallets to avoid write-lock collisions | Check | A transaction holding more account locks has more chances to conflict with others in the same block. Expect somewhat more contention on shared hot accounts. |
See Larger Transaction Sizes for the v1 format and current SDK support.
For Validator OperatorsNo configuration changes. Run the release as usual.+
The limit lives in the runtime behind a feature gate. There is nothing to configure.
Technical Details
SIMD-0596 raises the maximum number of addresses in a v1 transaction from 64 to 96. The limit counts every address: writable and read-only accounts, signers, and program IDs. Legacy and v0 keep their 64-account runtime limit, so the extra room is only available to applications that build v1 transactions.
The SIMD is still a draft. No feature gate has been assigned and no Agave release implements it yet, so the change cannot be tested on any cluster or local validator today. Until activation, v1 transactions above 64 accounts are rejected as they are now.
About This Upgrade
Account count sets how many components one atomic transaction can bring together. Raising the v1 limit gives routers, batchers, and multi-step protocols more room, with no change for legacy and v0 transactions.
Learn more: Solana Upgrades