How much content a single on-chain transaction can accommodate determines whether a developer can complete the operation in one go, or whether they need to split it into multiple transactions and wait for confirmation. The new generation of V1 transaction format, which is Solana, was enabled on the mainnet on September 15th at 10:35 AM, increasing the maximum size of a single transaction from 1232 bytes to 4096 bytes. The official upgrade notes mention its uses including zero-knowledge proofs, certain more complex multi-signature methods, and institutional operations. This is a capability that has already been implemented on the mainnet and is not still under testing; however, it does not mean that "all wallets and applications automatically support large transactions." Senders need to actively adopt the V1 format, and receivers as well as signatories must also make the necessary adjustments to ensure compatibility.
The old upper limit was not set arbitrarily. In the early days of Solana, the transaction payload was limited based on more conservative network transmission units. In complex scenarios, a single transaction might not even reach the computational limit before running out of space due to the number of bytes. According to official explanations, since QUIC became the default transaction protocol, these previous restrictions could be adjusted. However, larger transactions require more network bandwidth and buffer space from verifiers. Therefore, the new upper limit remains around 4KiB instead of being infinitely expanded. Larger transactions may also need to pay a higher priority fee to have an equal chance of being processed. For users, the increase in functional capabilities does not directly equate to a reduction in usage costs.
What have big transactions brought, and what changes have been made to the format?
V1 places the transaction identification fields at the beginning, the signature at the end, and includes configurations such as the computing unit, account data size, heap memory, and priority fees within the message structure. This allows network infrastructure to more quickly identify versions and read key resource parameters. However, it also changes the way older applications understand fees. In the older V0 version, priority fees were often quoted per computing unit in terms of a certain number of micro lamport; V1 used the total lamport amount for a single transaction. If an analysis panel directly compares these two values side by side, it may lead to completely incorrect conclusions of "fees soaring" or "fees plummeting." Data service providers need to unify the units first before they can discuss trends.
The handling of account addresses is also different. V0 saves space by using an address lookup table, while V1 allows up to 64 addresses to be included directly within a larger transaction, but without using an address lookup table; duplicate addresses will still be rejected. For complex transactions, this may reduce the preparation and splitting steps; however, for applications that already rely heavily on the lookup table, simply changing the version number from 0 to 1 is not sufficient. Developers need to rebuild the messages, test the order of accounts and resource allocation, and ensure that the transactions are correctly displayed in the wallet approval interface. The value of such a format upgrade largely depends on whether the ecosystem tools handle these details properly.
Special attention should be paid to changes in "default values." The official documentation reminds that if V1 does not explicitly set an upper limit for the calculation unit and the size of the account data to be loaded, the relevant restrictions will be zero, which may lead to transactions failing during the loading phase. In the old format, some resource values could be automatically filled in at runtime by default, but this practice cannot be directly applied with V1. It is recommended to first simulate transactions with a sufficiently large upper limit to measure the actual consumption, and then allocate a margin for the final transactions to be sent. If an account does not exist during simulation but is created before sending, the data size may suddenly increase; setting a budget too tightly can still result in failure. Developers who mistakenly assume that "large transactions are already possible" because of the old code's supposedly more lenient rules are likely to fall into such pitfalls.
Mainnet launch does not equate to a painless migration of the entire ecosystem.
Wallets need to explicitly declare their support for signing V1 transactions, and applications should check for the corresponding version capabilities before sending. Even if the wallet team has released a supported version, end-users may not be installing the latest client. The RPC service and block browsers also need to raise the upper limit of supported versions; otherwise, although transactions have been added to the blockchain, the query interface might return an error indicating that the version is not supported. Stream data consumers face a more concealed risk: if they continue to parse according to V0, they might silently misinterpret the configuration of V1 instead of directly reporting an error. For payment relays, fee payment on behalf of others, and server signature services, this is not just a visual issue; it could affect fee limits and risk control decisions.
On-chain programs also have their limitations. In the past, contracts would use instructions like ComputeBudget to determine the resource requests of a transaction. However, with the introduction of V1, these instructions no longer carry valid settings; they are now configured within messages, but on-chain programs at this stage do not have a corresponding method to read them. Officials have explicitly reminded developers to adjust their logic that relies on this assumption. For ordinary users, the most reliable indicator is not an article announcing the launch of the mainnet, but whether the wallets, applications, and service providers they use have completed adaptation and can correctly display the expected operations and fees.
Coexistence of versions also means that it is not possible to force all users to migrate on the same day. The old format does not become invalid immediately just because V1 is enabled; wallets and applications can choose to send either the old or the new version depending on their compatibility capabilities. For users who only need to perform simple transfers, they may not even notice the change from 4096 bytes in the short term; however, for teams that handle privacy proofs, complex authorizations, or multi-account operations, the benefits of the new format could be quite evident. The criterion for evaluating an upgrade should be whether specific transactions can be completed more reliably at one time, rather than changing every transaction in the network to use V1.
This upgrade is worth noting as it combines operations that previously required splitting, packaging, or additional coordination into a single atomic transaction, thereby reducing the engineering complexity of certain products. However, the 4096 bytes do not represent a doubling of throughput, nor does it mean that the transaction fees for each type of transaction will decrease. It's like adding an extra lane to a road: more goods can be transported, but rules for scheduling, charging, navigation, and driving still need to be updated. Solana has already opened the mainnet entrance for V1; what remains to be seen is how solid the ecosystem is in terms of compatibility, risk control, and readability.
