Solana’s transaction size limit rose from 1,232 bytes to 4,096 bytes on September 15, 2026, when the txv1 feature gate flipped at the first slot of mainnet epoch 1035. Most coverage has framed it as a developer upgrade: about 3.3 times the room for Zero-Knowledge (ZK) proofs, large multisigs and signature schemes in one atomic transaction. The operational burden lands elsewhere. The Solana Foundation’s upgrade page describes v1 as “opt-in for sending but mandatory for reading”, which puts the risk on exchanges, custodians, indexers and fee sponsors whether or not they ever build a v1 transaction.
What activated, and when
The txv1 feature account records activation at slot 447,120,000, the opening slot of epoch 1035, and Solana’s public Remote Procedure Call (RPC) endpoint returns a block time of 01:04:23 UTC for that slot (on-chain data queried September 15). Several outlets, including CryptoDaily citing CoinDesk, had reported a September 9 activation, so the switch landed six days after the date in circulation. The size increase is specified in SIMD-0296 and carried by the v1 message format in SIMD-0385. Legacy and v0 transactions keep working, and SIMD-0385 still rejects any v1 transaction with more than 64 addresses or 64 instructions, so the byte headroom does not lift the account ceiling.
Where the break sits
The Foundation lists what happens to a service that has not added maxSupportedTransactionVersion: 1 to its requests. A getTransaction call on a v1 transaction fails with error -32015. On getBlock, “One v1 transaction fails the entire block — no partial result”. A blockSubscribe stream “wedges on the first v1 slot”. Only getSignaturesForAddress is listed as unaffected. For a Centralised Exchange (CEX) or custodian that credits deposits by walking blocks, one v1 transaction from any user can stall crediting for every account touched in that block.
Fee sponsors face a quieter problem. v1 moves compute limits out of ComputeBudget instructions and into a transactionConfig field, and the Foundation warns that “Caps that scan ComputeBudget instructions stop binding”. A paymaster that polices spend by scanning those instructions enforces nothing on v1 traffic until it rewrites the check. Senders that opt in must set compute-unit and data-size limits explicitly, because both default to zero. Library support is uneven: @solana/web3.js 1.x at version 1.99.0 can read v1 but “cannot build, sign, or send” it, while sending needs @solana/kit 8.0.0, web3.js 3.x or the 4.2.x Rust crates. Custody stacks on the older library can read v1 after a patch but cannot originate it.
Why 4,096 and not more
The old cap was a networking artefact: a 1,280-byte IPv6 Maximum Transmission Unit (MTU), less overhead, left 1,232 bytes, and Solana’s move to QUIC removed that constraint. “The current transaction size limit of 1232 bytes is too small for many developer use cases,” wrote SIMD-0296 co-authors Jacob Creech of the Solana Foundation and Andrew Fitzgerald, adding that Jito bundles, the usual workaround, “are not guaranteed to be atomic like singular transactions.” Their listed beneficiaries include the ZK proofs behind Confidential Balances and nested multisig used by corporations under Squads.
The same document sizes the limit against a three-hour Jito sample taken on May 30, 2025: 50% of bundles were 2,048 bytes or smaller, 65% were 6,144 bytes or smaller, and all fitted within 9,216 bytes. The authors picked 4,096 partly to match a validator memory page. Read against those buckets, between 35% and 50% of the sampled bundles were larger than the new ceiling.
Who has to move
The firms running Solana (SOL) infrastructure are the ones exposed. MoneyGram joined Mastercard and Western Union as validators in June, Real-World Asset (RWA) value on Solana hit a record $3.4bn in July, and custodians behind products such as Morgan Stanley’s SOL staking Exchange-Traded Fund (ETF) run chain readers that now have to parse v1. The Solana transaction size change arrives alongside the 100ms finality push.
What to watch
Sending-side adoption should be gradual, because wallets must first advertise v1 through wallet-standard-features 1.5.0. Reading-side exposure is immediate: the first v1 sender makes every unprepared block reader fail, so early incidents are more likely to be delayed deposits and stalled indexer feeds than failed transactions. Pull request #596, opened by Fitzgerald on August 11, already proposes raising the v1 account lock limit to 96. Two tests follow for the Solana transaction size change: whether v1’s share of mainnet transactions rises over the next few epochs, and whether Jito bundle volumes fall. Steady bundle volumes would mean 4,096 bytes is still too small for the workloads that matter most.
This article is informational analysis only and is not financial, investment, or trading advice. Cryptocurrencies are highly volatile and can lose substantial value rapidly. Past performance and historical patterns do not guarantee future results. Do your own research and consult a regulated financial adviser before making any investment decision.
Karthik Subramanian
Karthik Subramanian is a founder, writer, and technology consultant with nine years in the crypto ecosystem. He covers token economics, L1/L2 infrastructure, DeFi protocols, wallets/custody, and the bridge between crypto and forex—broker technology, liquidity, and macro drivers. Karthik’s writing focuses on clear, practical frameworks that help professionals evaluate new products and on-chain innovation alongside FX market realities.
