Solana's Biggest Transaction Upgrade Arrives September 15. What Changes for Apps and Wallets?

Solana is scheduled to raise the maximum size of a single transaction from 1,232 bytes to 4,096 bytes, giving applications a larger envelope for data that previously had to be split across several steps.

The Solana Foundation lists Mainnet activation at the start of epoch 1035, expected on September 15, 2026, at about 01:20 UTC. The larger size is available only in a new v1 transaction format. Older legacy and v0 formats keep working. As of the Foundation's September 2026 upgrade page, Testnet and Devnet are already active and Mainnet is still listed as unavailable.

Why this matters

Think of a Solana transaction as a sealed envelope. Today that envelope is small. Developers who need more room, for example a large proof, a nested multisig, or several operations that must succeed or fail together, often split the work across chained transactions or use extra lookup machinery.

A larger envelope can hold more in one signed package. The Solana Foundation says workloads that once needed several chained transactions can land as one atomic transaction, which can mean fewer signatures to pay for and one confirmation instead of several. That is Foundation guidance, not a promise that every app will get cheaper or faster. Ordinary users benefit only if the wallets and apps they use adopt v1.

What is changing, and when

Two Solana Improvement Documents define the change. SIMD-0296 raises the size cap. SIMD-0385 specifies the v1 format that can carry the larger payload.

The upgrade page names the feature gate txv1, at address txv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLL. Sending a v1 transaction is opt-in. Applications that do not need the extra room can keep using the formats they use today.

A few mechanics change inside v1:

• Address Lookup Tables are removed. Account addresses are listed inline, up to the same 64-account execution limit. Duplicate addresses are rejected.
• Compute and loaded-account data limits must be set explicitly. On v1, leaving them unset means zero, which can cause the transaction to fail while loading accounts. Older formats used runtime defaults.
• A priority fee is stated as a total amount in lamports, the smallest unit of SOL. Older formats state a price in micro-lamports per compute unit. Those are different units and should not be compared as if they were the same number.

What ordinary users may notice

Most people who send, swap, or sign as they do today should see no change. The Foundation says wallets and applications that keep using legacy and v0 formats continue to work.

A user may notice v1 only in a few cases:

• A wallet or app they use starts sending larger v1 transactions for proofs, multisigs, or batched operations.
• A dapp builds a v1 transaction, but an older wallet cannot sign that version.
• An explorer, portfolio tracker, or history screen has not yet opted in to read v1, so a block or transaction fails to display.

None of those outcomes is guaranteed at activation. They depend on which products update, and when.

What wallets, apps, and infrastructure must change

The heavier lift sits with software that reads, indexes, sponsors, or sends transactions.

Readers. Any client that fetches transactions or blocks must pass maxSupportedTransactionVersion as the integer 1 on getTransaction and getBlock. Leaving the field out, or setting it to 0 or legacy, fails on a v1 transaction. One unread v1 transaction can fail an entire block response.

Indexers and fee sponsors. For v1, compute limits and priority fees live in transactionConfig. Pipelines that still scan ComputeBudget instructions can report zero without throwing an error. In v1 those instructions are ignored for configuration and run as successful no-ops.

Senders. Apps that want the larger size must build v1, set the resource limits, and check that a connected wallet actually advertises v1 support before asking it to sign.

Validators and RPC operators. The Foundation says Jito-Solana validators need v4.2.2 or later before epoch 1035, because earlier Jito builds will not include v1 transactions in blocks. RPC nodes need Agave v4.2.2 or later. Earlier RPC releases can store a v1 transaction as v0 with a zeroed compute budget.

Confirmed facts from the official record

• Maximum transaction size: 1,232 bytes today, 4,096 bytes in v1. Source: Solana Foundation upgrade page, updated September 2026.
• Mainnet activation: start of epoch 1035, expected September 15, 2026, approximately 01:20 UTC. Testnet and Devnet: active. Mainnet: unavailable on that page.
• Legacy and v0 keep working. v1 is opt-in for senders.
• v1 drops Address Lookup Tables, keeps a 64-account limit, and rejects duplicate addresses.
• SIMD-0296 says the old 1,232-byte cap came from a conservative 1,280-byte network packet limit. QUIC does not set a maximum stream size, which makes a larger transaction possible. The 4,096-byte ceiling matches a 4 KiB memory page.
• SIMD-0385 sets the v1 version byte to 129 (0x81) and moves resource requests into transaction config.

A separate Solana Foundation analysis published August 17, 2026, by Umberto Natale, estimates that about 62% of observed v0 transactions reference at least one Address Lookup Table. In that conversion study, dense ALT transactions can add more than 1,500 bytes when accounts are written inline; 50% of sampled transactions show an excess under 420 bytes, and 90% under 1,400 bytes. Those figures are Foundation analysis, not independent CryptoWorkPro measurements. The same article notes that the unchanged 64-account limit may still bind account-heavy apps.

Context and timeline

SIMD-0296 and SIMD-0385 are the technical specifications. The August 17 Foundation article explained the trade-off of removing lookup tables. The August 27, 2026 changelog, published August 28, told builders to follow the larger-transaction-sizes upgrade page. The official upgrade page still labeled the change a pending Mainnet feature.

What remains unknown

The official pages do not say which wallets, RPC providers, indexers, or apps will be ready at activation. They do not say how quickly senders will adopt v1, whether early Mainnet use will surface implementation issues, or how many real user flows will consolidate into a single transaction.

What to watch next

Watch whether Mainnet activation occurs at the start of epoch 1035 as scheduled. Watch whether wallets advertise v1 support only after they can sign that format. Watch whether RPC and Jito operators are on the versions the Foundation named. Watch whether explorers and indexers return v1 transactions without silently treating them as v0.

Sources and disclosures

• Solana Foundation, Larger Transaction Sizes upgrade page
• Solana Foundation, v1 Transactions and the ALT Trade-off, August 17, 2026
• SIMD-0296, Larger Transaction Size
• SIMD-0385, Transaction V1 Format
• Solana Changelog, August 27, 2026

The facts in this story come from the linked official records. Other news coverage is not the evidence for these claims. This article is not financial advice and does not recommend buying, selling, or holding any asset. The featured image is a generated conceptual illustration, not a photograph of a real event.