preferred on
Points of Focus
- Solana v1 would raise the transaction limit from 1,232 to 4,096 bytes and remove Address Lookup Tables.
- About 62.19% of sampled v0 transactions used at least one ALT over 30 days.
- V1 adds byte headroom, but the 64-account cap can still constrain account-heavy routes.
Solana’s proposed Transaction v1 would raise the maximum transaction size to 4,096 bytes, about 3.3 times the current 1,232-byte limit, while removing Address Lookup Tables.
Solana research published Aug. 17 found 62.19% of sampled v0 transactions used at least one ALT, showing how widely the current format relies on lookup-based compression.
Solana Transaction v1 trades ALT compression for a 4KB limit
Under v0, ALTs let transactions identify some accounts through short lookup indices rather than carrying each 32-byte public key in full.
Transaction v1 removes that lookup step and places every referenced account inside the transaction. It also moves fee and resource requests into transaction metadata, allowing validators to identify costs and the full account set earlier in the ingestion process.
That change is designed to reduce validator-side processing. V0 validators must load and resolve each referenced ALT before they know the complete account set.
SIMD-0385 proposes removing that state-dependent step, while SIMD-0296 supplies the larger 4,096-byte envelope needed to absorb the added addresses.
1/ SIMD-0385 by @jacobvcreech and @apfitzge introduces Transaction V1, a new format that moves the compute budget config directly into the transaction header. This eliminates compute budget instructions and address lookup tables for faster ingestion. Here's what changes 🧵 pic.twitter.com/TxSvwWXckK
— Anza (@anza_xyz) November 10, 2025
62% ALT usage shows where the 4KB headroom goes
The trade-off is visible in Solana’s 30-day, 1/16 transaction sample. When current ALT-using transactions were reconstructed under v1, half added less than 420 bytes and 90% added less than 1,400 bytes.
The modeled size distribution became thin above roughly 2,300 to 2,400 bytes, leaving room below the proposed 4,096-byte cap.
The sample also excludes transactions currently split, bundled or never built because they exceed today’s limit, so it can’t capture demand from applications that do not fit within the current format.
The 64-account maximum also stays unchanged. Some converted transaction groups had only a few account slots left before reaching that ceiling, which can still restrict routes that add another pool, market, vault or oracle even when byte capacity remains.
SIMD-0296 also flags bandwidth risks and overhead from fragmentation retransmissions, while calling for scheduler changes to support larger transactions. As of Aug. 17, both SIMD-0296 and SIMD-0385 remain in review, with no feature key listed for activation.
Share
Most read articles
