Solana activated Transaction V1 on mainnet at epoch 1035, approximately 01:04 UTC on September 15, 2026. The upgrade, shipped under SIMD-0385 by Anza with an accompanying size ceiling set by SIMD-0296, raises the maximum serialized transaction size from 1,232 bytes to 4,096 bytes — a 3.3x increas...
Solana activated Transaction V1 on mainnet at epoch 1035, approximately 01:04 UTC on September 15, 2026. The upgrade, shipped under SIMD-0385 by Anza with an accompanying size ceiling set by SIMD-0296, raises the maximum serialized transaction size from 1,232 bytes to 4,096 bytes — a 3.3x increase. Legacy and V0 formats remain fully supported; V1 is opt-in for transaction senders.
The change addresses a long-standing constraint. Workloads that could not fit inside a single Solana transaction — ZK proofs, BLS aggregate signatures, large multisigs, Winternitz one-time signatures, and confidential transfers — now execute atomically in one call. For a network processing 10.1 billion transactions in Q1 2026 at an average fee of $0.00025, removing the size bottleneck opens a class of applications that previously required multi-transaction workarounds or could not be built at all.
V1 is the first of two major protocol changes landing this quarter. Alpenglow, Solana's replacement for TowerBFT consensus, is scheduled for October and targets 150-millisecond finality, down from the current 12.8 seconds.
Two Solana Improvement Documents deliver the upgrade. SIMD-0296, authored by the Solana Foundation, establishes the new 4,096-byte hard limit on serialized transaction size, up from the 1,232-byte ceiling that has been in place since the network's genesis. SIMD-0385, developed by Jacob Creech and Andrew Fitzgerald at Anza, defines the V1 message format — a 0x81 version byte and a TransactionConfigMask that replaces compute budget instructions.
The rollout followed a staged timeline:
| Milestone | Date | Detail | |---|---|---| | Local testing begins | August 2026 | Developer preview | | Testnet activation | September 1, 2026 | Epoch 1025 | | Mainnet activation (original target) | September 9, 2026 | Delayed | | Mainnet activation (actual) | September 15, 2026 | Epoch 1035, ~01:04 UTC |
The delay from September 9 to September 15 was attributed to additional validator readiness checks. No technical incidents were reported during testnet operation.
The V1 format restructures how Solana transactions declare resource requirements. Under legacy and V0 formats, a transaction must include compute budget instructions — separate program calls to ComputeBudgetProgram — to set compute unit limits, priority fees, heap size, and loaded-accounts data size. Validators must scan the full instruction list to extract these parameters before scheduling.
V1 moves these declarations into the transaction header via the TransactionConfigMask. This allows validators to identify resource requirements by reading the header alone, without parsing the instruction array. The practical effect: faster transaction ingestion at the validator level.
Key structural constraints retained in V1:
The envelope is larger, but the internal limits remain unchanged. The additional bytes are available for instruction data, not for increasing account or signature counts.
The 1,232-byte ceiling was a hard constraint that forced developers into workarounds — chaining multiple transactions, splitting operations across blocks, or abandoning certain designs entirely. At 4,096 bytes, several classes of workload now fit in a single atomic transaction:
ZK Proofs. Zero-knowledge proofs, particularly those used in confidential transfers and privacy-preserving protocols, generate proof data that exceeded the prior limit. Solana's Confidential Balances extension — a Token-2022 feature using homomorphic encryption and ZK proofs to shield transfer amounts — is a direct beneficiary. Previously, confidential transfer operations required multiple transactions; they can now settle atomically.
BLS Aggregate Signatures. BLS signature schemes allow many individual signatures to be compressed into a single compact proof. This is particularly relevant for cross-chain bridge attestations and validator-set signing, where dozens or hundreds of parties must authorize a single operation. The old transaction size made single-transaction BLS verification impractical.
Large Multisigs. Governance protocols requiring many co-signers — institutional treasury management, DAO operations, multi-party escrow — previously hit the size ceiling before all required data could be packed. V1 provides headroom for more complex signing schemes.
Winternitz One-Time Signatures. Post-quantum signature schemes, which produce larger signatures than ECDSA or EdDSA, now fit within a single transaction boundary. This is a forward-looking capability with limited immediate demand but growing relevance as the industry prepares for quantum-computing threats.
V1 adoption requires explicit opt-in by transaction senders. The format is not backward-incompatible at the network level — legacy and V0 transactions continue to function unchanged. However, RPC consumers face a mandatory update.
RPC integration change: Applications must pass maxSupportedTransactionVersion: 1 on getTransaction, getBlock, and blockSubscribe calls. Without this parameter, any V1 transaction in the response triggers error code -32015. This is the same pattern used when V0 transactions launched — RPC clients that do not update will begin seeing errors as V1 transactions appear on-chain.
Compute budget migration: In V1, the compute budget is set through the new TransactionConfigMask in the header. Legacy compute budget instructions remain valid in V0 and legacy formats but have no effect in V1 transactions. Developers building V1 transactions must use the new header-based configuration.
The Solana Foundation has published example code at github.com/solana-foundation/transaction-v1-examples to assist migration.
V1 lands on a network with significant and growing activity. Key metrics as of September 2026:
| Metric | Value | Source Period | |---|---|---| | Daily transactions | 100M+ | Q1 2026 | | Quarterly transactions | 10.1B | Q1 2026 (record) | | Average TPS | 1,500–4,000 | Typical range, mid-2026 | | Average transaction fee | $0.00025 | Mid-2026 | | Network fee revenue | $89.5M | Q1 2026 | | DeFi TVL | $5.92B | September 6, 2026 | | DEX volume (daily) | $1.96B | September 6, 2026 | | DEX volume share | 23.65% of all chains | September 6, 2026 | | SOL price | ~$105.46 | September 6, 2026 | | Market cap | ~$61.74B | September 6, 2026 | | Network uptime | 100% (trailing 90 days) | As of July 23, 2026 |
DeFi TVL rose 25.46% over the 30 days ending September 6, from $4.72B to $5.92B. DEX volume climbed 42.99% over the same window, according to Blockchain Magazine.
The validator set comprises approximately 1,414 active validators with a Nakamoto Coefficient of 19. No single validator controls more than 3.2% of total stake. Geographic distribution is spread across four jurisdictions holding over 10% of stake each: US (18.3%), Netherlands (13.7%), UK (13.7%), and Germany (13.2%).
On the client diversity front, Firedancer — Jump Crypto's independent validator client — reached 20%+ adoption among active validators during Q1–Q2 2026, following its mainnet launch on December 12, 2025. However, over 95% of active stake runs the Jito-Solana client, indicating that while client diversity is improving in validator count, stake concentration remains skewed.
Transaction V1 is the first of two major protocol upgrades scheduled for Q3–Q4 2026. Alpenglow replaces Solana's TowerBFT consensus mechanism and targets a finality time of approximately 150 milliseconds, a 98.8% reduction from the current 12.8 seconds.
Alpenglow was initially expected in September 2026 but has been delayed to October, pending the Agave 4.3 release. Activation requires sufficient validator key registration and activation of the Validator Admission Ticket (VAT). A bug bounty program offering up to 50,000 SOL is running to surface issues before mainnet deployment.
If both upgrades ship successfully, Solana will have fundamentally altered two core protocol parameters within a two-month window: transaction capacity (V1) and finality speed (Alpenglow). The combined effect — larger atomic operations settling in 150ms — positions the network for use cases that require both complex on-chain logic and near-instant confirmation: high-frequency trading, real-time payment settlement, and cross-chain bridge operations.
Solana's base-layer scaling approach contrasts with Ethereum's Layer 2 strategy. Ethereum L1 processes 15–30 transactions per second; scaling is offloaded to rollups (Arbitrum, Optimism, Base, zkSync) that post compressed data back to L1. Solana processes all transactions on a single chain at 1,500–4,000 TPS.
Transaction costs reflect the structural difference. Solana's average fee of $0.00025 is orders of magnitude below Ethereum L1 ($0.10–$0.30) and remains cheaper than most L2 solutions.
From an economic-value perspective, the fee differential raises questions about revenue sustainability. Solana generated $89.5M in network fee revenue in Q1 2026 on 10.1 billion transactions. The revenue-per-transaction is extremely low. Whether the V1 upgrade — by enabling more complex and presumably higher-value transactions — can improve unit economics remains to be seen. More complex transactions may command higher priority fees, but the base fee structure does not change.
Weekly DEX volume on Solana ($11.49B) exceeded Ethereum's ($7.62B) as of September 2026. However, Ethereum's DeFi TVL remains substantially larger — a reflection of Ethereum's role as the settlement layer for institutional capital, while Solana captures retail trading activity and consumer applications.
Adoption uncertainty. V1 is opt-in. If major wallet providers, DEX frontends, and SDK maintainers are slow to integrate, the format's benefits will remain theoretical. The RPC version-parameter requirement creates friction — applications that do not update will encounter errors as V1 transactions appear.
Retained structural limits. The 12-signature, 64-account, and 64-instruction caps remain. V1 expands the data envelope but does not increase the number of discrete operations or accounts a transaction can touch. Some workloads may still require multi-transaction patterns.
No Address Lookup Tables. V1 drops ALT support, which was a key feature of V0 transactions. Applications relying on ALTs for large account lists cannot migrate to V1 without restructuring.
Validator client concentration. With 95%+ of stake on Jito-Solana, any bug in that client's V1 implementation could have outsized impact. Firedancer's 20%+ adoption by validator count provides some resilience, but not in stake-weighted terms.
Complexity creep. Three transaction formats now coexist — legacy, V0, and V1. Developers and infrastructure providers must support all three. This increases testing surface and potential for implementation errors.
maxSupportedTransactionVersion: 1.Transaction V1 is an engineering upgrade, not a product launch. It removes a size constraint that blocked specific cryptographic workloads from executing atomically on Solana. The immediate beneficiaries are protocols building privacy features (confidential transfers), cross-chain infrastructure (BLS bridge attestations), and complex governance systems (large multisigs).
The upgrade's impact will be measured not by activation-day metrics but by adoption over the following quarters — specifically, whether developers build applications that could not exist under the 1,232-byte ceiling. The combination of V1 with Alpenglow's 150ms finality, if both ship on schedule, represents a material change in what Solana can technically support: complex, privacy-preserving operations settling in under a second.
For now, the network continues to produce blocks. The old formats still work. The new format is available. What gets built with it will determine whether V1 was a necessary infrastructure upgrade or a capability that exceeded market demand.