Solana Testnet Hits 300ms Slot Times as Agave 4.2 Feature Activations Begin August 17

Solana's testnet reached 300ms block times on August 10, one week before Anza is scheduled to begin Agave 4.2 feature activations on mainnet-beta. Anza CEO Brennan Watt observed the milestone on testnet at 21:40 UTC, and Anza engineer Tim Garcia confirmed three minutes later that feature activations on mainnet are on track to begin August 17.

"300ms slots happening on testnet," Watt wrote.

The observation is a validation run, not the mainnet event itself. Watt noted the testnet runs on roughly 36-hour epochs, which means each SIMD-0525 stage unlocks far faster there than on mainnet's multi-day epoch cycle. What testnet demonstrated on August 10 is what the Agave 4.2 feature gates are designed to deliver on mainnet once activated.

From 400ms Toward 200ms: SIMD-0525's Five-Stage Plan

The slot-time reduction does not happen in a single activation. SIMD-0525, the protocol improvement that governs the change, structures the journey from 400ms to 200ms across five sequential stages: 400ms, then 350ms, then 300ms, then 250ms, and finally 200ms. Each stage is feature-gated separately, and each requires the prior stage to be running stably before the next opens.

Testnet is already two stages in, currently running at 300ms, the third target in that sequence. Mainnet activations begin on August 17, starting with the first stage. Watt's comment about waiting for 250ms slots reflects testnet's position on that ladder: at 300ms, the 250ms gate is the next milestone to unlock.

As we covered when Anza published the v4.2 release schedule in June, XDP (eXpress Data Path) clearing a supermajority of mainnet stake was the networking prerequisite for the 4.2 cycle. That threshold was reached June 30. The 100M compute unit block limit that XDP unlocked activated at epoch 1009 in late July.

Two More Features Arriving with August 17 Activation

Slot-time reduction is one of three changes in the August 17 feature set. The other two address transaction capacity and on-chain storage costs.

The transaction size ceiling rises from 1,232 bytes to 4,096 bytes, roughly tripling the instruction capacity of a single call. DeFi protocols that currently chain multiple transactions to interact with many accounts in a single operation (lending markets, complex AMM routes, structured products) can consolidate more logic into one atomic transaction.

Rent reduction cuts the lamports-per-byte storage cost by 90%, per the Agave v4.2 release documentation. Lower storage costs reduce the minimum balance required to keep accounts open, easing the overhead for programs that create and maintain large numbers of accounts.

Validators and RPC Operators: The August 10 Adoption Window Has Passed

Garcia's note that "RPC operators have some upgrading to do" came attached to his August 17 confirmation. The official release schedule marks August 10 as the general adoption recommendation for mainnet-beta, the date by which Anza recommended validators complete their upgrade to Agave v4.2. Operators who have not yet upgraded are already past that window with seven days until feature gates open.

Shorter slot times increase the rate at which validators must process and propagate blocks. Moving from 400ms to 350ms raises throughput demands modestly; subsequent stages toward 250ms and 200ms are more demanding still. Anza's staged approach, one feature gate at a time with testnet running ahead to validate each step, is designed to surface hardware and connectivity stress before mainnet encounters it rather than in a single large jump.

Alpenglow Remains Dormant Until Agave 4.3

Agave 4.2 carries Alpenglow consensus code in the codebase but does not activate it. The consensus replacement, which targets 100 to 150ms transaction finality by moving validator votes off-chain and aggregating them with BLS signatures, is planned for the Agave 4.3 cycle. The BLS key infrastructure Alpenglow requires shipped with Agave 4.1 in late June. The slot-time improvements starting August 17 are independent engineering work, not a prerequisite for Alpenglow, though both are part of the same multi-release infrastructure arc.

Watt has previously characterized v4.2 as one of the most substantial overhauls of the client software, connecting slot-time reduction to the broader trajectory toward sub-200ms latency that Alpenglow is designed to complete.