2026-08-27 · solana-foundation
Solana Foundation published a detailed research post examining transaction v1 and the trade-off created by removing Address Lookup Tables while increasing the maximum transaction size to 4,096 bytes. The piece focuses on how the new format can simplify validator ingestion while changing how account-heavy transactions fit inside Solana's byte limits. This is notable because transaction format changes shape the network's practical developer surface just as much as headline throughput metrics do. The post makes clear that v1 is not only about bigger transactions, but also about earlier fee and resource visibility for validators and a different balance between flexibility and compression.
The analysis says transaction v1 promotes fees and resource requests into first-class metadata, removes ALT lookups, and separates fixed-width instruction headers from variable payloads. It also quantifies how current v0 workloads would translate into the new envelope, showing that many transactions remain compatible while dense ALT users can consume much more of the expanded byte budget.
For validators and client teams, earlier access to fee and resource data can improve prioritization and block construction while reducing state-dependent processing during ingestion. For application developers, the larger envelope opens room for richer atomic transactions and proof-heavy use cases, but the unchanged 64-account cap means some account-heavy patterns may still hit structural limits.
Developers, wallets, and RPC providers should review serialization, decoding, and transaction-building assumptions that currently depend on ALT behavior. Validators and infra teams should also watch how v1 support lands across Agave, Firedancer, and tooling stacks, because format readiness will matter before the ecosystem can fully benefit from the new transaction model.
Read Original Post →