Agave 4.1 Ships Alpenglow Readiness Components and Lays Groundwork for 200ms Slots

Anza released Agave v4.1.0 on June 26, marking the first major release under its new six-week cadence and shipping a cluster of features that have been building across multiple SIMDs: the consensus infrastructure Alpenglow needs, two more Pinocchio program rewrites, and a staged plan to halve slot times.

Helius hSOL$86.10+0.4% published a full technical breakdown on June 29 covering every changed component. The stable version is already recommended for mainnet validators alongside testnet and devnet.

BLS Public Keys and VAT: What Alpenglow Needs From Validators

Alpenglow, Solana's in-progress consensus replacement for Tower BFT, cannot activate on mainnet until validators have registered BLS public keys and until the admission mechanism is in place. Agave 4.1 delivers both.

SIMD-0387 adds BLS public key registration to vote accounts. Validators register their BLS keys during the 4.1 cycle while keeping their existing Ed25519 vote authority keys. BLS aggregate signatures are required for cheaper vote aggregation and verification under Alpenglow, and the rule is straightforward: any vote account without a registered BLS key cannot participate after Alpenglow activates.

The community test cluster has been running since May with approximately 100 geographically distributed validators, as Compass covered when Mithril became the fourth client to produce blocks on that cluster. The BLS key work in 4.1 is what connects mainnet validators to that test environment.

Validator Admission Tickets (VAT, SIMD-0357) replace continuous vote transaction fees with a per-epoch admission cost. Today validators pay roughly 2.1 SOL per epoch in vote transaction fees. Under VAT, the cost is 1.6 SOL per epoch, deducted from vote accounts at the epoch boundary rather than from validator identity accounts. The voting set is capped at 2,000 validators; when more qualify, the top validators by stake weight fill the slots. Only validators with both a registered BLS key and sufficient lamports pass the filter.

Fast Leader Handover Markers (SIMD-0337) round out the Alpenglow readiness work: new block markers let leaders declare and update parent blocks during streaming, reducing synchronization delays between leader rotations.

Pinocchio Rewrites: p-memo and p-ATA

Agave 4.0 shipped p-token, which cut the SPL Token program's compute consumption by roughly 95%. Agave 4.1 brings two more Pinocchio rewrites that together free a further 10% of total block capacity.

P-memo is now live on mainnet. The compute savings depend on how many signers a transaction carries: a memo with no signers drops from 2,022 CUs to 287 CUs (roughly 14% of the original cost), while a three-signer memo drops from 36,406 CUs to 743 CUs, about 2% of the original.

P-ATA targets the Associated Token Account program, which appears in around 11.9% of all Solana transactions and accounts for roughly 13.3% of total compute unit consumption, making it the fifth most-invoked program on the network. The Pinocchio rewrite cuts weighted average CU usage by an estimated 80.9%, freeing more than 2.78 million CUs per block in sampling data. Network-wide, the expected savings are around 10% of total block CU consumption.

Direct Account Pointers (SIMD-0449) support both rewrites by optimizing the program entrypoint itself: a 64-account Pinocchio entrypoint drops from 504 CUs to roughly 7 CUs, making entrypoint compute constant regardless of account count.

XDP Crosses Two-Thirds of the Network

XDP (eXpress Data Path), the kernel-bypass networking stack that replaces Solana's standard UDP path, has passed what Anza calls the "flippening" threshold: more leaders are now running XDP than not, with over two-thirds of the network activated.

The experimental label is gone. The old experimental flags have been replaced with stable equivalents (--xdp-interface, --xdp-cpu-cores, and --xdp-zero-copy), and XDP is scheduled to become the default in Agave 4.2. XDP is also a prerequisite for the 100 million compute unit block goal, since the networking throughput it provides is what makes higher block capacity achievable without adding latency elsewhere.

The 200ms Slot Plan

SIMD-0525 proposes a staged reduction of slot times from 400ms to 200ms: 400ms to 350ms, then 300ms, 250ms, and finally 200ms, each stage feature-gated. Anza has been testing this internally for months and believes the network is ready to begin the rollout.

The engineering context: replay time for a full 400ms slot today is roughly 40ms, meaning the network is spending most of each slot waiting rather than processing. The leader window at 200ms would be 800ms, down from 1.6 seconds at 400ms. Epochs would shorten from roughly two days to one day as a result.

Several parameters adjust automatically with the slot-time reduction. VAT costs scale with each stage to keep the admission cost near 0.8 SOL per day. The slots_per_year constant increases by the inverse ratio to preserve SOL's inflation rate. Per-slot work limits reduce proportionally.

One genuine tradeoff: daily validator voting costs, currently around 1.086 SOL at 400ms, would roughly double at 200ms because validators cast one vote per slot. The VAT pricing adjustment is designed to offset this, but the net economics for smaller validators will depend on how the full package lands in practice: VAT replacing continuous vote fees, combined with the slot-time scaling.

Agave 4.2, which is expected on the new six-week cadence, is slated to include the first stage of the slot-time reduction along with 4,096-byte transaction sizes and XDP as the default.

Commission Basis Points, SHA-512 Syscall, and Loader Hardening

Commission rates move from whole percentage points to basis points (100 bps = 1%) via SIMD-0291, with a new UpdateCommissionBps instruction for vote accounts. This prepares the network for SIMD-0123, block revenue distribution, which Anza CEO Brennan Watt committed to shipping this year alongside SIMD-550 and SIMD-553.

A new sol_sha512 syscall (SIMD-0512) gives onchain programs access to standard 64-byte SHA-512 digests at under 100 CUs, compared with thousands of CUs via direct computation, mirroring the existing sol_sha256, sol_keccak256, and sol_blake3 syscalls.

The upgradeable loader gets a DoS fix via SIMD-0431: the minimum extension size for ExtendProgram rises to 10,240 bytes (10 KiB), at a cost of roughly 0.072 SOL in rent-exempt lamports, closing a vector where one-byte extensions could be submitted permissionlessly to spam the loader.

Agave 4.1 also continues the RAM reduction trend visible from 3.1 through 4.0, which matters for validators running close to memory limits on current hardware.

The Six-Week Cadence

The release itself carries a structural point: Agave 4.1 is the first under Anza's new six-week major release schedule. The prior pattern was longer and less predictable. A tighter cadence compresses the feedback loop between proposal and validator adoption, which matters when the changes being staged (slot-time reductions, XDP defaults, Alpenglow activation) need to land in a specific sequence.

Agave 4.2 is where several 4.1 investments converge: XDP becomes the default, the first 200ms slot-time stage is expected to land, and Alpenglow consensus activation is described as a possibility. The work shipping now is the foundation for that.