What Solana activated
The Solana Foundation reports that the txv1 feature gate activated on mainnet at the start of epoch 1035 on September 15 at approximately 01:00 UTC. The v1 transaction format raises the maximum transaction size from 1,232 to 4,096 bytes and is also active on testnet and devnet. The larger envelope is intended for workloads such as zero-knowledge proofs, large multisignature transactions, and onchain signature schemes that could not fit in one transaction before.
Legacy and v0 transactions continue to work. Using the larger format is opt-in for senders, but the presence of v1 transactions onchain changes the operational contract for systems that read blocks, index activity, display signing intent, co-sign transactions, or sponsor fees. The Foundation’s migration guide identifies minimum SDK versions and several cases where an old integration can fail loudly or, more seriously, continue with incorrect data.
Version support belongs in the read-path SLO
Solana’s RPC guide says getTransaction and getBlock callers must pass maxSupportedTransactionVersion: 1 to receive v1 data. Without it, a v1 transaction returns error -32015; one v1 transaction can make an entire getBlock request fail. The guide also warns that blockSubscribe can emit a null block and stop advancing. This makes format readiness an availability concern even for applications that never create v1 transactions.
Production teams should inventory every RPC consumer, not only the primary application API: indexers, compliance exports, fraud pipelines, customer-support tools, accounting jobs, and disaster-recovery readers. Add a v1 fixture to contract tests, alert on stalled slot progression and version errors, and prove that replay from the first v1-containing block reaches the same checkpoint as the live pipeline.
Silent indexer drift is the higher-risk failure
In v1, resource settings move from ComputeBudget instructions into a transactionConfig object. The Foundation warns that an indexer that keeps scanning instructions can report zero compute limits or priority fees without raising an error. For Geyser and gRPC consumers, stale generated code may interpret v1 as v0 and discard the new config field. The documented detection order is therefore structural: a present config field means v1; only when it is absent should the versioned flag distinguish v0 from legacy.
That is a schema-migration problem, not just a decoder update. Teams should retain raw messages during rollout, dual-run old and new projections, compare fee and resource fields by transaction version, and block downstream financial or risk reporting when the decoder version is unknown. Priority-fee normalization also needs an explicit rule because v0 expresses a price in micro-lamports per compute unit while v1 stores a total in lamports.
Wallets and sponsors must authorize the message that will execute
A v1 sender must explicitly set compute-unit and loaded-account-data limits; their v1 defaults are zero. Transactions larger than 1,232 bytes must use base64 submission. Before asking for a signature, a dapp also needs to check the wallet’s advertised supportedTransactionVersions rather than assuming that every installed version can parse and present v1 safely.
The sharper control boundary is fee sponsorship and server co-signing. ComputeBudget instructions are no-ops in v1, while the effective limits and total priority fee live in transactionConfig. A sponsor that approves a payment by scanning those instructions is no longer bounding the transaction it signs. Version detection, canonical decoding, limits on the actual v1 config, recipient and instruction policy, simulation, and an audit record of the signed bytes should be one atomic authorization path.
Ineeza’s view
The 4,096-byte limit enables useful cryptographic and multisignature workflows, but the production event is a protocol-format migration crossing every trust boundary around a transaction. The safest rollout starts with readers and evidence pipelines, then wallet capability negotiation, and only then v1 creation and sponsorship. Teams should treat unknown formats as an explicit degraded state, preserve raw data for reprocessing, and authorize from canonical decoded fields. Larger transactions are the feature; version-aware operations are the prerequisite.