Solana Upgrade on September 9: What the New Transaction Format Changes

On 9 September 2026, Solana switches on a new transaction format. If you hold SOL, the most important answer comes first, and it is a reassuring one: you do not have to do anything. No swap, no wallet migration, no deadline that costs you money. What changes sits one layer deeper in the protocol, and that is exactly where individual wallets and applications may start behaving differently in the days around 9 September, without anything being broken on your side.

This article explains what actually happens on 9 September, who named the date, why it carries a few hours of leeway in both directions, and how you can tell for yourself that the switch has gone through. English-language coverage of the technical event is thin: searches for "Solana upgrade September 2026" return mostly price and ETF headlines rather than an account of the protocol change itself.

What happens on Solana on 9 September, and what does not

Solana is raising the maximum size of a single transaction from 1,232 to 4,096 bytes, a little more than triple. This is possible because of the QUIC network protocol, which, unlike the old IPv6 limit of 1,280 bytes, imposes no fixed ceiling on a data stream.

The new size does not apply to everything that moves across the chain. What matters is a new transaction format called v1, and the higher limit applies only there. The two existing formats, legacy and v0, remain valid unchanged and keep their old ceiling. Developers have to migrate to v1 deliberately; no application moves there on its own.

That also settles what does not happen on 9 September. There is no hard fork, no chain split, no migration of your balances and no network downtime. Your SOL, your tokens and your stakes sit exactly where they sat before the switch.

Who named the date, and why the official upgrade page carries none

The date does not come from a Solana Foundation document but from a statement attributed to a named individual. Jacob Creech, Vice President of Technology at the Solana Foundation, named 9 September on X on 29 August; the trade publication crypto.news picked up the announcement on 30 August (crypto.news).

The Solana Foundation's official upgrade page, by contrast, lists the change without a date. It carries the numbers (4,096 bytes instead of 1,232, a 3.3x increase) and the status "Pending Feature Activation". For the three networks it states: testnet active, devnet not activated, mainnet not activated.

The gap between announcement and document is not a contradiction but the norm at Solana. Dates for individual features come out of the release schedule of the development firm Anza and are communicated by people before they appear anywhere as a fixed calendar entry. Anyone who wants hard evidence checks the chain directly, and there is more on that below.

Transaction size: what fits into a single operation at 4,096 bytes

A transaction is the envelope that holds an instruction to the blockchain: sender, recipient, signatures, accounts involved, program call. Until now, 1,232 bytes fitted into that envelope. Anything larger had to be broken into several transactions and chained one after another, with the risk that one part goes through and the next one fails.

At 4,096 bytes, according to the official upgrade page, the following fit into a single operation for the first time: zero-knowledge proofs (cryptographic proofs that establish something without revealing the underlying data), complex multisignature instructions, and bundled operations that today require several chained transactions. For applications with a high cadence, such as liquidation engines, order books and settlement layers in DeFi, that is the real gain: fewer partial steps, fewer intermediate states, fewer sources of error.

The limit of 64 accounts per transaction remains unchanged. More room therefore means more data per participant, not more participants.

What a feature gate is, and why it only flips at epoch boundaries

A feature gate is a switch in the validator code that keeps a shipped function turned off until a majority of validators enable it together. Solana has been putting its changes behind such gates for years instead of tying them to a hard fork. The advantage lies in the decoupling: the changes in a single release are technically independent of one another and can be activated one at a time, each only after its own test. This network upgrade is therefore part of a rolling programme rather than a one-off event.

The price of that approach is that the network changes several times over in September without ever getting a big announcement with a countdown. For the larger transaction format, the gate carries the on-chain verifiable address txv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLL.

One point matters for understanding the date: a gate falls at an epoch boundary, not at a clock time. An epoch is Solana's accounting period and covers a fixed 432,000 slots; a slot is the time window in which a validator may produce a block. Only when an epoch ends does the chain adopt the newly activated functions.

Our own measurement: where the chain stood on 2 September

On 2 September 2026, at around 12:40 UTC, we queried a public mainnet node directly rather than relying on third-party figures. Three values came back in real time:

• The account of the feature gate txv1aq4pp… is empty on mainnet-beta. The gate is not activated at that point, so the announcement for 9 September is still pending rather than already executed.
• The chain was running in epoch 1027, at slot 35,113 of 432,000, roughly eight percent of the epoch.
• The nodes we queried reported client version 4.2.1. The release that ships the new format is therefore already running.

Two block times 10,000 slots apart give a measured slot time of around 314 milliseconds. On that basis a full epoch currently takes about 37.7 hours. Extrapolating, epoch 1027 ends on the evening of 3 September, and roughly three more epoch boundaries fall before 9 September. The last one before the date lands on the evening of 8 September, the next one after it on 10 September.

In practice this means 9 September is a date with a few hours of leeway in both directions, not a clock time. If you check on the morning of 9 September and notice nothing, you have not necessarily missed anything.

Address lookup tables disappear in format v1

This is where the real catch sits, and it is the reason developers will not simply enable the new format everywhere. An address lookup table (ALT) is an on-chain directory for account addresses: instead of writing every address into the transaction at its full 32 bytes, the application points to an entry in that table with a short index. This is precisely how applications have saved space in order to get under the 1,232-byte ceiling at all.

Format v1 does not support these tables. Anyone using v1 has to write all the accounts involved into the instruction directly, as full 32-byte addresses. The additional room therefore pays for part of its own extra consumption.

For developers this turns into a judgement call on each transaction: does the larger envelope deliver more than the saved address list cost? For a zero-knowledge proof the answer is clearly yes. For a swap routed through many pools that today works with a well-maintained lookup table, the old format may still be the better choice.

What this means for wallets and dApps in the days around 9 September

Because every application makes that judgement itself, the migration will be uneven. Some teams will move to v1 early, others will leave it for months, and others again will use both formats in parallel depending on the operation. For you as a user, it may look like this:

• A dApp reports marginally different fees for the same operation after the switch, because the size of the transaction has changed.
• A wallet displays a transaction differently in the preview than it did before.
• One application sticks to its old behaviour for the time being while another visibly changes.

None of these observations indicates a fault with your account. If you hold your own keys, the upgrade changes nothing about your custody; a look at the hardware wallet comparison is worthwhile for other reasons, but not because of this date. The reverse also applies: if a message, an email or a phone call tells you in these days that you have to "migrate" your wallet or enter a seed phrase because of the Solana upgrade, it is an attempted fraud. Network upgrades of this kind never require any action from end users.

Do I have to do anything as a SOL holder?

No. The answer is solid, and it rests on three grounds:

1. Existing formats remain valid. legacy and v0 transactions will run after 9 September exactly as they did before.
2. The migration is voluntary and sits with the engineering team of each application. Neither wallet users nor holders make a decision here.
3. There is no deadline at which anything expires. Unlike a token swap or a delisting at an exchange, nothing is lost at the end of this date.

If you still want to do something, do the sensible thing: in the days around 9 September, avoid leaving larger transactions to the last minute, and if you see a conspicuous error message, check the status page of the application in question before repeating it several times.

The September schedule: three changes, three dates

The larger transaction format is the middle of three changes that Solana is activating one after another over a few weeks. The schedule as Jacob Creech outlined it at the end of August:

1. A cut in storage fees (following the governance vote on proposal SIMD-0437), the first of five planned steps in the week beginning 31 August. This refers to the rent that accounts on Solana have to deposit for their storage space; as it falls, opening new accounts becomes cheaper.
2. Transaction format v1 with 4,096 bytes, scheduled for 9 September.
3. Alpenglow, the major consensus upgrade that arrives with the Agave 4.3 release and, according to the Foundation, is aimed at October.

On the last point there are two dates that appear to contradict each other at first glance, which is why we set them side by side. The release plan for Agave 4.3 names 28 September as the start of feature activation on mainnet, while the Foundation gives October as its target for Alpenglow itself. The two fit together as soon as you separate release from gate: the release brings the code, the gate decides the timing, and this roadmap is not a rigid calendar. What Alpenglow means for stakers is set out in detail in our article on the Alpenglow upgrade and staking.

How fast the chain really runs, and what Alpenglow is meant to change

Published figures on slot time diverge. The official upgrade page names a target of 200 milliseconds for the Agave 4.2 release, against 400 previously; crypto.news reported 350 milliseconds on 30 August, with interim targets of 300, 250 and 200. Our own measurement on 2 September produced 314 milliseconds. The reduction in block production is therefore proceeding in steps that likewise sit behind individual gates.

Transaction finality is a separate matter and describes the moment from which a transaction can no longer be reversed in practice. This is exactly where Alpenglow comes in. The upgrade replaces the existing TowerBFT consensus architecture with two new components, Votor for validator voting and Rotor for block propagation, and targets finality of around 100 to 150 milliseconds instead of the 12.8 seconds that has been usual so far. Part of the gain comes from settling validators' vote transactions off chain rather than routing them through the chain in the regular way, which also lowers validator costs. Proof of History, the chain's clock, is unaffected.

For everyday use, sub-second finality mainly means that exchanges and payment providers can credit deposits sooner, because settlement certainty is established earlier. That makes Solana more interesting as a settlement layer for applications that depend on fast finality. For the price, none of this follows automatically.

What validators and stakers should watch now

Anyone running a validator has the date in the calendar anyway. Anyone who only delegates, meaning you have deposited your SOL with someone else's validator, has nothing to prepare, but should know what matters over the coming weeks.

The decisive factor is client diversity: Solana today runs on several independent validator programs. If a function is finished in only one of them, the gate is delayed for everyone; changes of this kind are tested beforehand on test networks and in validators' own practice. As a staker, the individual date therefore matters less than the question of whether your validator installs current releases promptly and how reliably it produces blocks. If you were going to review your delegation anyway, look at your validator's downtime, at its commission, and at whether it keeps up with current releases.

One point that often gets lost: the level of your staking yield depends on the protocol's inflation rate and on validators' fee income, not on the transaction format. The recent fall in yields has other causes.

How you can tell that the gate has fallen

You do not need a node of your own for this. There are three routes, from the simplest to the most precise:

1. The official upgrade page. It shows the status for each network. Once the mainnet entry flips from "not activated" to active, the matter is settled.
2. The epoch counter. Public Solana explorers show the current epoch and its progress. A gate always falls at the transition to the next epoch.
3. The feature account itself. If you like, query a public node for the account txv1aq4pp281K9um3tnPgkfX8UqtFT6wcVW3hNezGLL. As long as nothing is stored there, the function is off; once the account carries data, it is on. This is precisely the route we used for this article.

And if 9 September passes without anything happening? That is not a warning sign. Feature gates regularly slip by one or two epochs when a test is still running or a client is lagging behind. The date is an intention, not a contract.

Solana upgrade: what to take away

1. Stay calm and change nothing. For holders and users there is no action, no deadline and no risk attached to this date. If you hold your SOL for the long term, nothing changes for you; where you buy remains a decision about fees and trading pairs, for which the crypto exchange comparison is a starting point.
2. If something looks off, check the application first, not the network. If a dApp departs from its usual behaviour in these days, that is most likely down to its own migration to the new format. Any prompt to enter keys or move balances because of it is fraud; which software wallets hold your keys in which way is shown in the software wallet comparison.
3. Keep the October date in view. Alpenglow is the change with real consequences for stakers and for the speed of the chain. If you delegate, check beforehand how reliably your validator operates; the benchmarks for that are set out in the overview of staking platforms.

(As of September 2, 2026. This article is not investment advice. Prices and fee structures change; check the terms with the provider before you buy.)