Agave 4.2 Update: All You Need to Know

Introduction

With Agave 4.2, Solana’s core validator client continues to break new ground. The major release centers on three highly anticipated, feature-gated upgrades: 200ms slot times, a 90% reduction in state bonds, and 4,096-byte transactions through the new transaction v1 format. It also ships Alpenglow feature-complete ahead of its planned activation in the following release, while XDP transmit is now enabled by default.

Notable Updates

• 3.3× Larger Transactions with a new Transaction v1 standard *
• 90% State Bond (Rent) Reduction *
• Reduced 200ms Slot Times *
• Alpenglow feature-complete
• New Governance Tooling (SIMD related)

* Feature-gated upgrades

Larger Transactions (Transaction v1)

The Agave 4.2 release cycle includes a feature gate activation for larger transactions up to 4,096 bytes, up from the longstanding limit of 1,232 bytes. Formally defined in SIMD-0296: Larger Transaction Size, the higher limit represents a roughly 3.3× increase and applies exclusively to the new transaction v1 format introduced by SIMD-0385: Transaction V1 Format. Legacy and v0 transactions continue to work unchanged and remain subject to the existing 1,232-byte cap.

For developers, this is more than additional room for instruction data. Cryptographic proofs, multisig approvals, large account lists, and other payloads that could not previously fit within a one transaction can now execute in a single protocol-native atomic operation. The change does not increase Solana’s compute, account, signature, or instruction-count limits.

The original 1,232-byte limit was inherited from Solana’s earlier networking architecture. Transactions were transmitted as individual UDP datagrams and needed to fit inside the IPv6 minimum maximum transmission unit (MTU) of 1,280 bytes. After accounting for the 40-byte IPv6 header and eight-byte UDP header, 1,232 bytes remained for the transaction itself. Keeping every transaction in a single packet reduced fragmentation and made transmission more predictable.

Solana has long since migrated over from UDP to QUIC for transaction ingestion. QUIC streams are not restricted to the payload of a single network datagram, so the old 1,232-byte ceiling is no longer a requirement. Clients still need an explicit upper bound for admission control, memory allocation, and consensus validation, but that bound can now be chosen according to runtime and application requirements rather than the IPv6 MTU.

Account lists often consume a significant portion of the existing size allocation. Every Ed25519 public key or program-derived address occupies 32 bytes, and a transaction must identify every account that its instructions read or modify. This previously gave an effective ceiling of roughly 32 full account keys. To get around this, V0 transactions introduced Address Lookup Tables (ALTs), which replace each 32-byte key with a single-byte table index, allowing transactions to reach the runtime’s 64-account limit.

While ALTs are an effective form of compression, they unfortunately also introduce complexities. Applications must create and manage lookup tables onchain. RPC services and indexers decoding a raw v0 message must reconstruct its complete account list using transaction metadata or the relevant table state. This creates a challenge when parsing transactions that reference an ALT that has since been closed and is no longer available onchain. 

This developer pain point is resolved with v1 transactions, which are large enough to carry the complete account set currently supported through ALTs (64 full public keys occupying 2,048 bytes). Consequently, an application migrating from v0 can resolve its lookup-table entries and include the resulting addresses directly in a v1 transaction.

Additionally, 1,232-byte transaction sizes are particularly restrictive for cryptographic functions such as zero-knowledge proofs and BLS implementations that lack native precompiles. These workloads can carry hundreds or thousands of bytes of proof or signature data. A 4,096-byte cap covers many of these common cryptographic use cases. 

Transaction V1 Specification

A serialized v1 transaction begins with the version byte 0x81. It is followed by a three-byte legacy-style message header, a 32-bit transaction configuration mask, a 32-byte lifetime specifier, instruction and address counts, the complete array of 32-byte addresses, configuration values, fixed-size instruction headers, contiguous instruction payloads, and finally the signatures. 

VersionByte (u8)
LegacyHeader (u8, u8, u8) 
TransactionConfigMask (u32) -- Bitmask of which config requests are present.
LifetimeSpecifier [u8; 32]
NumInstructions (u8)
NumAddresses (u8)
Addresses [[u8; 32]] -- Length matches NumAddresses
ConfigValues [[u8; 4]] -- Length equal to the popcount (number of set bits)
  of TransactionConfigMask. See section TransactionConfigMask for details.
InstructionHeaders [(u8, u8, u16)] -- Length of NumInstructions. Values are
  (ProgramAccountIndex, NumInstructionAccounts, NumInstructionDataBytes)
InstructionPayloads [InstructionPayload] -- Length = NumInstructions.
  Each InstructionPayload is the concatenation of the following byte arrays:
    InstructionAccountIndexes [u8] -- Length = NumInstructionAccounts from the
    corresponding InstructionHeader
    InstructionData [u8] -- Length = NumInstructionDataBytes from the
    corresponding InstructionHeader
Signatures [[u8; 64]]

Instruction headers explicitly identify the program-account index, number of instruction accounts, and instruction-data length, making message boundaries available without interpreting each instruction’s payload.

V1 transactions remain limited to 12 signatures, 64 account addresses, 64 instructions, and 255 account indexes per instruction. Large transactions must still fit within the requested compute-unit limit, loaded-account-data limit, account-locking rules, and the block’s available execution capacity.

Existing parsers cannot treat v1 as v0 with a larger maximum length. Indexers, RPCs, SDKs, and signing infrastructure that inspect serialized transactions must recognize the 0x81 prefix and implement the new field ordering. Of particular note, v1 signatures appear at the end of the transaction rather than preceding the message as they do in legacy and v0 transactions.

Transaction v1 replaces Compute Budget program configuration instructions with fields in the transaction header. The initial `TransactionConfigMask` can declare the transaction’s:

• total priority fee in lamports
• compute-unit limit
• loaded-account-data-size limit
• requested heap size

Each set bit identifies an accompanying four-byte configuration value, with the 64-bit priority fee occupying two mask positions. The mask is designed to be extendable in future transaction versions.

State Bond (Rent) Reduction

High state-bond requirements, usually referred to as “rent”, remain one of Solana’s most significant sources of friction for account-intensive applications. The name is somewhat misleading given that rent is not a recurring storage fee but a refundable bond that an account must hold for as long as its state remains onchain. Lamports can normally be recovered when the account is closed, but until then they represent capital that a developer or user must provide upfront and leave immobilized.

Agave 4.2 introduces the feature-gated implementation of SIMD-0437: Incrementally Reduce lamports_per_byte to 696, which reduces the `lamports_per_byte` constant from 6,960 to 696. This is a 90% reduction in rent (or more accurately the rent-exempt minimum), delivered through five independent feature gates: 6,960 → 6,333 → 5,080 → 2,575 → 1,322 → 696. 

When one of the gates activates, Agave updates the Bank’s rent configuration and publishes the new value through the Rent sysvar. The staged rollout allows the network to observe how applications respond at each price level and stop before the next reduction if state growth or validator resource usage becomes concerning.

An account’s rent-exempt minimum is calculated from its allocated data size plus a fixed 128-byte storage overhead:

minimum_balance = (128 + account_data_size) × lamports_per_byte

Under this change, the rent mechanism itself does not change: accounts still need a minimum balance, and that balance remains recoverable when the account is closed. Only the amount of SOL that must be bonded changes.

A standard SPL Token account is 165 bytes. Including the 128-byte overhead, its effective size is therefore 293 bytes. The 90% rent reduction takes the SOL required for such an account from about ~$0.16 to under 2 cents. 

This has particularly important consequences for stablecoin payments, token distributions, loyalty systems, and direct airdrops. A wallet does not hold SPL tokens directly; it normally needs an Associated Token Account (ATA) for each mint. When a recipient does not yet have the required ATA, the sender can create it alongside the transfer, but must also fund the recipient's rent-exempt balance. This is generally a one-time onboarding cost for each wallet-and-mint pair rather than a cost paid on every subsequent payment. Still, at scale, it can be large enough to determine whether a business subsidizes onboarding or passes the cost to users.

Solana’s State Growth

The staged reduction is important because lowering the state bond also reduces the amount an attacker must immobilize to create and retain unwanted state. Solana state is replicated, indexed, included in snapshots, and maintained by every validator, so persistent state growth eventually affects disk requirements, AccountsDB operations, and ultimately operating costs.

According to Solana Foundation’s recent analysis, AccountsDB storage files occupy approximately 495 GB against a recommended 1 TB allocation. After the planned rent reduction, exhausting that headroom would require an attacker to commit approximately $17.2 million worth of SOL. Doubling the recommended validator storage allocation to 2 TB raises the attacker’s capital requirement to $51 million.

After accounting for both new account creation and closure of older accounts, state was found to be growing by approximately 0.3 GB per day.

A state snapshot taken in epoch 997 shows that state consumption is highly concentrated. SPL Token accounts were the largest category, while OpenBook and Serum accounts occupied roughly 30% of live state, reflecting the complex architecture of onchain order books. The analysis also estimated that roughly 30% of SPL Token space was associated with Pump.fun token launchpad-style assets.

Safety Measures

Reducing state bonds safely requires a viable path in the other direction. Without additional runtime changes, increasing the rent-exempt minimum later would instantly leave existing accounts below the new threshold. Transactions that write-lock those accounts could fail even when they did not allocate any additional state, leading to widespread disruption.

This is where SIMD-0392: Adapt Runtime for Rent Increases changes the post-execution minimum-balance rule so existing accounts can be grandfathered when rent rises. When an account already exists, does not grow in size, and retains the same owner, its permitted minimum becomes the lower of either:

1. the minimum under the current rent rate
2. the account's pre-execution balance

New accounts must still satisfy the current rent-exempt minimum. So must accounts that increase their allocated size or change owners. Zero balance continues to represent account closure. This lets existing state continue operating at its previous bonded amount while ensuring that newly allocated state pays the latest rate.

SIMD-0438: Safeguard for rent-exempt minimum increase adds a separate protective feature gate that restores `lamports_per_byte` to the legacy value of 6,960. It is intended to be activated only if reduced rent produces excessive state growth or another significant operational problem. Because the gate exists before the reductions begin, core developers would not need to design, review, and deploy a new consensus change in the middle of an emerging state-growth incident.

Together, the five reduction gates, the grandfathering rules in SIMD-0392, and the fallback in SIMD-0438 make the rollout reversible at the protocol level. The network can lower the bond incrementally, observe live-state and validator-storage behavior, pause at an intermediate value, or restore the original requirement without forcing every existing account to be topped up immediately.

Reduced 200ms Slot Times

One of Solana’s most anticipated performance upgrades is reducing target slot times from 400ms to 200ms. The primary benefit is lower latency. At 200ms slots, Solana’s four-slot leader window would shrink from 1.6 seconds to 800ms, reducing confirmation times and limiting how long a malicious leader can delay, reorder, or selectively include transactions. Shorter slots also provide applications such as oracle consumers and market makers with more granular onchain timing.

The proposal is designed to preserve Solana’s existing economics and throughput. Inflation parameters, Validator Admission Ticket costs under Alpenglow, and per-slot work limits are adjusted proportionally. However, if 200ms slots arrive before Alpenglow, validator voting costs could roughly double because validators would need to vote twice as frequently.

For a deeper look at 200ms slots, read our previous coverage in the Agave 4.1 breakdown.

Other Notable Updates

Several smaller but notable improvements are set for activation during the Agave 4.2 release cycle.

Alpenglow Readiness

Agave 4.2 ships Alpenglow feature-complete but will not activate the new consensus protocol on mainnet; the core engineering teams are using this release cycle for further testing, auditing, and hardening ahead of the consensus migration now expected with Agave 4.3. Validators running 4.2 therefore already carry the full Alpenglow implementation, including the Votor voting engine and its BLS certificate-verification components. 

To expand the code’s security review, Anza is also running an Alpenglow bug bounty competition with a prize pool of up to 50,000 SOL and a submission window from August 5th to 19th. Alpenglow had previously been excluded from the standing Agave bounty during development, monorepo migration, and internal audits; the competition marks its introduction into bounty eligibility and is intended to uncover issues that may have escaped earlier review.

Stake Program Float to Fixed-Point

The Agave 4.2 release cycle also includes the feature-gated implementation of SIMD-0391: Stake Program Float to Fixed-Point, replacing IEEE-754 floating-point arithmetic in the Stake Program’s warmup and cooldown calculations with deterministic fixed-point integer math. The primary motivation is compatibility with the standard eBPF toolchain, which does not support floating-point operations. Solana’s SBF toolchain can emulate them using deterministic soft-float routines, but this is inefficient and blocks the Stake Program’s migration toward a `no_std` implementation.

Most applications require no changes, although indexers and staking tools that independently reproduce effective, activating, or deactivating stake should implement the new integer rules once the feature activates.

New Governance Tooling

The Agave 4.2 release cycle also sees the launch of new governance tooling that has been in the works since last year. This tooling provides an onchain process for both validators and native stakers to signal their position on major economic and protocol-level decisions. 

Its central component, svmgov, is an Anchor-based program that manages proposal creation, support, stake-weighted voting, and finalization. Voting weights come from an epoch-specific stake snapshot produced by the Node Consensus Network (NCN). Independent operators derive the snapshot, reach consensus on a canonical Merkle root, and publish it onchain; validators then prove their active stake using Merkle proofs. 

Validators with at least 100,000 SOL in active stake can create proposals, while proposals need support from 15% of cluster stake before advancing through the voting process. The governance repository also includes a Rust CLI and web frontend for voting and tracking support.

Full proposal documents live in the separate Solana Governance Proposals repository and are pinned to a specific Git commit, while the onchain proposal account stores the link, lifecycle state, and vote tallies. Validators initially vote with all stake delegated to them, but individual delegators retain sovereignty over their SOL; a staker can submit an override for a specific stake account, removing that stake from the validator’s tally and reallocating it according to the staker’s own vote.

Solana Governance Proposals (SGPs) are intended to complement rather than replace SIMDs: an SGP answers the directional question of whether the network should pursue a change, while the associated SIMD specifies how the change should be implemented.

Three SGPs have already passed the support phase and will mark the first round of governance votes under the new system:

• SGP-0001: The Solana Constitution proposes ratifying a canonical governance social contract that defines the roles of developers, validators, and stakers and formally establishes the SGP process.
• SGP-0002: Double Disinflation asks the network to double SOL’s annual disinflation rate from 15% to 30% while leaving the 1.5% terminal inflation rate unchanged, shortening the estimated path to that terminal rate from approximately 5.7 years to 2.8 years. 
• SGP-0003: Resource and Inclusion Fee proposes replacing the existing flat base-fee structure with a 2,500-lamport inclusion fee paid to the leader and a separate resource fee based on requested transaction cost units that is burned in full, while leaving priority-fee distribution unchanged.

Conclusion

Agave 4.2 is one of Solana’s most consequential releases in recent memory. Faster 200ms slots push the network closer to real-time responsiveness, the planned 90% reduction in state bonds makes account creation dramatically more affordable, and 4,096-byte transaction v1 unlocks substantially more room for complex instructions, cryptographic proofs, and account-heavy applications. Together, these changes make Solana faster, cheaper, and more expressive for developers and users alike.

Further Resources

• Agave 4.2 Release Schedule
• Feature Gate Tracker Schedule
• Agave 4.2 Change Log
• Agave 4.2 Pull Requests