Solana (SOL) V1 Transactions Go Live on Testnet as Size Jumps to 4,096 Bytes

V1 Transactions Activate on Testnet

Solana's V1 transaction format went live on the network's testnet on Sept. 1, activating at epoch 1025 and lifting the maximum serialized transaction size from 1,232 bytes to 4,096 bytes — a 3.3x increase. Developer shop Anza shipped the release as the final rehearsal before a mainnet activation scheduled for Sept. 9, a date confirmed on Aug. 29 after local V1 testing began on Aug. 24. The upgrade lands on Solana (SOL) as the network pushes deeper into on-chain finance, where complex, multi-step operations have increasingly strained the legacy transaction format.

The change rests on two proposals from the Solana improvement process. SIMD-0296 defines the larger transaction budget, while SIMD-0385 specifies the V1 message format, moving transaction configuration out of ComputeBudget instructions and into the message itself — a restructuring that lets validators read resource requirements without scanning the instruction list. V1 also drops the address-lookup tables used by V0, embedding address mode internally instead. The practical payoff is atomicity: workloads that previously had to be split across separate transactions, such as zero-knowledge proof verification, large multi-signature schemes, and BLS signature setups, can now execute in a single all-or-nothing call. Developers have historically worked around the old 1,232-byte ceiling by stacking up to five transactions into Jito bundles, but bundles lack protocol-level atomicity and compete inside Jito's own block engine. For dApp teams and DEX aggregators building swap routes, a native V1 transaction either succeeds or reverts as one unit — with fewer fee-bearing signatures along the way. One constraint remains unchanged: the 64 distinct-account cap still applies, so account-heavy applications will not be fully unblocked. Anza CEO Brennan Watt marked the activation on X, posting a large transaction from the testnet explorer with the note “heads up: large transactions have landed on testnet.”

RPC Operators Race the Sept. 9 Deadline

V1 is opt-in, so legacy and V0 transactions keep functioning — the operational risk sits with infrastructure that must read the new traffic. Anza has required RPC providers to move to Agave v4.2.2 or v4.3.0-beta.3, and the Agave 4.2 migration guidance circulating among infrastructure teams warns that RPC consumers not declaring V1 support may see call failures such as getBlock breaking on V1 transactions. That makes this final testnet window the last preparation round for RPC operators, indexers, wallets, SDKs, and analytics platforms ahead of mainnet. The upgrade also coincides with the broader Agave 4.2 rollout, under which a phased cost-reduction plan is expected to deliver savings near 90% and cut processing time from 500 to 200 milliseconds. Momentum behind the network's on-chain finance push is visible in the data: Galaxy's Q2 2026 research on Solana documented rising stablecoin, tokenized-equity, and real-world-asset activity, arguing the chain's future hinges on assets being usable for lending, collateral, margin, and yield rather than issuance and trading alone. Readers tracking the market in real time can follow live spot and futures prices on Bybit.

Blockchain infrastructure security is the other half of this week's Solana story. An attacker exploited an outdated Rain card contract on Aug. 28, draining roughly $1.1 million from stablecoin card programs on the network, per security firm Blockaid. The reuse of a signature across two independent verification instructions let the attacker grant itself admin rights and call WithdrawCollateralAsset, with 8,233 core exploit transactions recorded over roughly two hours and 29 minutes; proceeds were bridged to Ethereum and roughly 455.9 ETH entered Tornado Cash. Avici disclosed $500,859 lost across 1,685 users and Tria $431,945 across 636 customers, both pledging reimbursements, and Rain says every program on the vulnerable version has since been upgraded. Customers' self-custodial wallets were untouched — the flaw lived in application code, not the chain itself. Read together, the two events frame the network's next phase: the base layer is scaling capacity and cutting latency just as the security burden shifts decisively to the application layer, where version hygiene across shared contract deployments — continuous monitoring alongside periodic audits — will determine whether user funds stay safe.