Releases
Notable feature gates
- Reducing slot times from 300ms to 250 ms - Testnet
- Reducing slot times from 350ms to 300ms - Testnet, Devnet
New versions
- Agave v4.3 release schedule, v4.2.0
- Firedancer Testnet v26.08.0, Mainnet 1.1.4
- Frankendancer Mainnet v0.1105.40200
- Subscriptions Program v0.5.0, Typescript SDK v0.5.0, Rust SDK v0.5.0
- Token ACL Program v0.3.0
- Mollusk v0.15.0
Ecosystem work
SIMDs
- Increasing the total number of accounts a transaction can reference at a time was proposed
What this means (WTM) - This takes advantage of two new changes to the protocol: increased blockspace (from 60M CUs to 100M CU limit per block), and increased transaction sizes (from 1232 bytes to 4096 bytes). With both changes, a transaction can read from and write to several more accounts which allow for more complex applications.
Validator clients (Agave, Firedancer, Mithril)
-
Agave is working to improve its program cache implementation, including an increase in the global program cache size from 512 to 1024 programs, making cache invalidation based on the latest slot the program was deployed in the bank, and a better handling of built-in programs
WTM - The program cache is notoriously memory-intensive and error-prone. These changes allow for more programs to be loaded, while at the same time expects less program reloads onto the cache. -
Agave will not repeatedly destroy pinnable slices on its RocksDB integration
WTM - Agave’s Repair service takes data shared by other validators and reconstructs them with error correction. It requires the use of the Blockstore service for key information. Blockstore depends on a storage engine called RocksDB and it allows for a view of its data through a pinnable slice. This data structure exposes the underlying data as bytes and can actually be reused multiple times. The previous Repair implementation creates and destroys these pinnable slices each time, not taking advantage of this functionality. -
Agave will parallelize BLS vote verification
WTM - This resolves a possible security/performance scenario where incoming Alpenglow votes overload a validator’s ability to verify them. It allows for parallel verification so that multiple verification jobs are done simultaneously. -
Agave is considering prioritizing transaction processing by transaction size with a long term view of relaxing the 4KB transaction size constraint
WTM - Solana may eventually allow for transactions larger than even 4KB. To future proof for this scenario, scheduling will therefore have to take transaction size into consideration since processing time and resources allocated may proportionally increase. -
Agave is running checks for the banking stage in parallel
WTM - Before the validator changes the account state based on the transaction, it has to sanitize the transaction, check for account locks, ensure the blockhash is still valid, and other tasks. The previous implementation would run this check one transaction job at a time. This change improves this by allocating more workers for the checks, and creating a working job queue for the scheduler workers to process. -
Agave is lowering its snapshot interval from 100 slots to 200 slots
WTM - Snapshots allow validators to run fast from a restart instead of having to replay every transaction from the very first transaction. With the decrease in slot times from 400ms to 200ms, this change increases the snapshot slot coverage accordingly. -
Firedancer will allow its services to save on compute time, memory, and memory reads and writes when they are awake and running, or idle and waiting.
WTM - Firedancer has a large memory footprint when an instance is spun up - somewhere in the ballpark of around 300GB. And most of that is keeping its services in a live state. This change ensures that it allocates resources more judiciously depending on which parts are working or idle. -
Mithril is implementing the Retransmit service
WTM - The Retransmit service takes shreds when the validator node is not voting and is responsible for identifying who the next peers to receive these shreds are, and sending shreds to these peers. Every validator is required to participate in the Turbine tree. Hence, this implementation complies with the required activity of being a Solana validator.
Solana language clients (Web3.js, Solana Kit, Kit plugins, Solana SDK, Codama, Solana Go)
-
A Memo program class will be supported in Web3.js
WTM - Supporting the Memo program on your Solana application allows you to show logs in your transaction by invoking an instruction. Adding support for this on Web3.js broadens its capability as a web client. -
Kit is planning to add support for React hooks that allow state management of Solana primitives
WTM - First-class support for Solana primitives as hooks allows for more dynamic behavior in Solana applications built on React. The same way @tanstack/query-react provided hooks on fetching data, so will these hooks for Solana primitives like airdrops, etc. -
Kit is enabling more flexibility when signing transactions without necessarily sending them, allowing for use cases like partial signing
WTM - Historically, Kit has coupled both signing and sending in one method. By decoupling them in this way, it allows for partial transaction signing, signing with delayed sending (maybe timing a trade, etc). -
Effort was made to optimize base58 encoding and decoding on Solana Go.
WTM - Base58 is used across the Solana stack, including instruction data, account addresses, transaction APIs, etc. Optimizing this is a win on any front across the stack.
Solana program frameworks (Anchor, Pinocchio, Steel, Quasar)
- Anchor resolved an issue that made the Instructions Sysvar account unusable
WTM - The Instruction Sysvar allows for use cases such as Instruction Introspection - where an instruction can read data/results from other instructions in the transaction as an input/calculation within its own runtime execution. Ensuring that Anchor still allows for this keeps Anchor programs in line with what’s already supported in Solana.
Testing frameworks (mollusk, litesvm, surfpool)
- LiteSVM is preparing for support for Transactions V1
WTM - V1 transactions include a new transaction format and larger transaction sizes. LiteSVM as a testing harness would allow users to test how their programs would fare when this feature is turned on.
Incident reported August 12, 2026 04:01 UTC
Terraswitch experienced a routing issue that impacted its Frankfurt location, where several Solana validators are hosted.
Details from Solana Foundation:
Terraswitch Report Following the Incident: https://www.teraswitchstatus.com/incidents/rb6k5l3qxw9k
This issue did not result in network downtime. And this is due to the fact that not enough validator stake was affected to break the consensus threshold of ~33.33%. This is the result of previous and ongoing work by the Solana Foundation to diversify the use of other providers in other regions.
Community resources
Developers shared open-source projects, educational materials, infrastructure experiments, and ecosystem updates.
- Joey Meere maintains a repository of Solana open-source projects.
- The Solana developer community is hosting an Anchor Community Call ahead of the upcoming v2 launch.
- Birdeye supports the solana.com/data application.
- Jonas shared guidance on integrating Solana applications with MoneyGram ramps.
- Jupiter developer relations published its June changelog.
- Himanshu Rawat shared a visualization of the Solana transaction lifecycle.
- Cavemanloverboy shared a simulation of timely vote-credit reductions for validators as slot times decrease to 200ms.
- Prince published a video series on understanding Solana, covering escrows, Pyth integration, indexing, and trading bots.
- Gui Bibeau is building propAMM infrastructure.
- L0STE published svm-math, a small project exploring arithmetic on Solana.
- Solana open sourced tokens.xyz.
- Sam0xSol shared an overview of the Jetstreamer transaction-backfilling service.
Follow Solana developer updates
Follow @solana_devs for weekly Solana engineering updates. Read last week’s issue.