Feature gates reduced mainnet slot times from 400ms to 350ms, while Testnet moved from 250ms to 200ms. The week also brought releases across validator clients and developer tooling, alongside new work on transaction processing, program caching, and validator repair.
Releases
Notable feature gate activations
- Reducing slot times from 250ms to 200 ms - Testnet
- Upgrade BPF Stake Program to v5.1.0 - Testnet
- Reducing slot times from 300ms to 250ms - Devnet
- Reducing slot times from 400ms to 350ms - Mainnet
New versions
- Agave v4.3.0-beta.0, v4.2.1
- Firedancer Mainnet v0.1106.40201
- Solana Kit v7.1.1
- Token 2022 Program JS SDK v0.15.0
- Program Metadata Program JS SDK v0.8.1
- Token ACL Gate Program v0.3.0
Ecosystem work
Community Validator Discussions: August 13, 2026
SIMDs
-
A new proposal to prevent nonce transactions to use their own nonce account addresses as program IDs has been added
What this means (WTM) - All transaction instructions must specify a program ID. This prevents a reflexive case where an instruction in the nonce transaction stored in the nonce account refers to itself as the program ID. -
A proposal to remove inactive stakes from the runtime stakes cache has been proposed.
WTM - In practice, storing inactive stakes are not useful for processing transactions and stores more data and use more resources than necessary. However, it affects the lattice hashing (the digital signature) of the account stake which is used in consensus. This change ensures that removing them does not negatively impact consensus.
Validator clients (Agave, Firedancer, Mithril)
-
Agave is exploring the replacement of a rayon implementation of signature verification of shreds with dedicated worker threads.
WTM - The rayon crate is being avoided because its thread pool implementation does not allow for the flexibility needed to adjust compute resources depending on load. This exploration allows shred signature verification to be possibly leaner and more performant. -
Agave is working to make the loading of accounts on the runtime more customizable from its Accounts DB implementation
WTM - This change creates a new capability which allows account data to be loaded on the runtime (which takes time and optimizing this improves performance) based on a certain condition specified by calls by validator services. This is helpful for when you want to manage loads based on things like who owns the account, how much rent the account has etc. -
Agave is working to prevent slot rolling.
WTM - Slot rolling is when transactions that aren’t processed in one slot get processed in another. This makes it difficult to do the necessary cost tracking to enforce CU limits per slot. This change schedules the block scheduling step to do it for a specific slot, rather than rolling transactions over if limits are reached. -
Agave is considering refactoring their Gossip implementation
WTM - The Gossip implementation of Solana allows validators to communicate with each other offchain with information like their stake, their network addresses, etc. Historically, this service has been a performance bottleneck for several reasons, and this draft change explores what a more readable, more performant Gossip would look like. A notable change here is that instead of using several threads to run the service, it makes use of a single event loop and worker threads. -
Given changes to the program cache last week, Agave is continuing with requiring the deployment slot of a program when invalidating the program cache
WTM - This allows for finer grain control when loading the program buffer into the program cache. The runtime can eventually extract the program from the parent slot (or any slot for that matter) based on this new API. This makes things like program changes more straightforward and allows for cache behavior to be more predictable. -
Agave’s TPU will sanitize transactions in the ingress stage before running signature verification.
WTM - To confirm that the user signed a transaction, validators verify that the signatures were indeed created by their signers. Unfortunately, this is a rather expensive calculation. This change makes it simpler such that invalid transactions based on simple parameters (instruction limits, account lock limits, etc) are checked for first and are easier to dismiss a transaction for. -
Mithril will soon allow itself to be open to repair requests from other validators
WTM - Validators are not always able to reassemble the block that it got from shreds from the block propagation phase, which means it couldn’t validate, which means it couldn’t vote. To get around this they make what’s called a repair request to other validators for the shreds they have missing via Repair. Mithril is allowing itself to send shreds to other validators who do not have a complete set for the block.
Solana language clients (Web3.js, Solana Kit, Kit plugins, Solana SDK, Codama, Solana Go)
- Support for V1 transactions are underway on the following language clients - Web3.js, Solana Kit (previous progress), Solana Go
WTM - V1 transactions are the new transaction schema format that will be released in the coming weeks. All language and platform clients should be able to support this or risk incurring errors on the part of their users.
Solana Program Library (SPL) and Core BPF
- Ed25519 Programmatic Signer Program added an implementation for their executor program

WTM - The programmatic signer implementation is an exploratory repository for a durable nonces replacement. It already has a signer program which verifies signatures and promotes PDAs as signers, and a nonce program which creates and modifies the nonce account containing the transaction and ensures it can only be used once. This new program advances the nonce and allows that to be executed.
Community work and discussions
Community members shared validator notes, application experiments, infrastructure work, and technical discussions.
- Axis Pizza, a new validator, began sharing technical notes and open-source contributions.
- Jonas of SolPlay created a meetings penalty payment app.
- The discussion around SGP-0002 continued with analyses from mert and brianlong.
- Triton One implemented faster, less resource-intensive indices.
- Beeman shared how Solana mobile applications interface with wallet applications.
- NotDeGhost formally introduced Anchor v2.
Resources
Watch the Community Validator Discussions from August 13, 2026, or revisit the previous issue. Follow @solana_devs for future engineering updates.