Back to Changelog
ChangelogSeptember 19, 2026bySolana FoundationSolana Foundation

Solana Changelog: September 18, 2026

Solana Changelog: September 18, 2026

Releases

Notable feature gates

Mainnet

Transaction V1

Rent Reduction to 5080 lamports per byte

Slot time reduction to 250ms

New versions

Ecosystem work

SIMDs

  • A discussion on removing compute limits on Solana was started
    • WTM - Currently, blocks are fixed at 100M CUs. This discussion weighs the possibility of removing block limits entirely through a two-step process. This means that validators can pack as much compute and transactions as they feel the network can handle.
  • A discussion on being able to view a transaction configuration during transaction processing has been started
    • WTM - There exists a feature to be able to view other instructions while running a current instruction. Being able to view a transaction configuration as an instruction is being run/replayed is not possible on Solana as of yet. This discussion is asking whether there are benefits to this feature, especially considering that compute requests and usage have been moved from ComputeBudgetProgram instructions to the transaction header in Transaction V1.
  • A proposal was made to disable Legacy and V0 transaction formats
    • WTM - With Transaction V1 deployed successfully on Mainnet, removing legacy formats removes complexity on the part of the validator when processing and executing transactions. This is similar to SIMD-0500, which disallows deployments of sBPF versions older than v3.
  • A proposal was made to simplify transaction fee burning
    • WTM - Transaction fees are summed and half of that number is burned at the end of the slot. Adding all the fees for transactions in a block is more difficult math than simply doing the calculation and the burning after each transaction, especially as transactions per block get much larger.
  • A proposal was made to introduce 128-bit integer multiplication on the runtime
    • WTM - This change takes advantage of upstream BPF and Static Syscalls to standardize and improve performance of 128-bit integer multiplication. Previously, you would have had to manipulate two 64-bit integers a certain way on the runtime, which is more costly than this proposal.

Validator clients (Agave, Firedancer, Mithril)

  • Agave is making improvements to ensure smooth program deployment during the end of an epoch, namely to ensure programs are deployed in the correct environment and that they are not reloaded after the epoch boundary
    • WTM - This handles edge cases observed when making program deployments. Most users will never experience this, but because slots happen so fast, the likelihood of deploying a program during a dangerous slot isn’t zero.
  • Additional conformance work was done for block execution and transaction execution
    • WTM - Fuzzing allows for more exhaustive testing of inputs on the various Solana validator clients (Agave, Firedancer, Mithril) and on different client versions. It generates edge cases upon edge cases to ensure that the system is prepared for these inputs. Since both block and transaction execution affect consensus, they also need conformance binaries to be used across several other validator clients.
  • Work is done to improve validation during program deployments by consolidating two runtime environments on Agave
    • WTM - This simplifies the runtime so that more work is focused on processing transactions despite new and existing programs being deployed. Runtime validation happens when the transaction runs, and a lot of complexity and edge cases are removed.
  • Agave will make allocation for verified and unverified vote batches explicitly handled in its BLS verify service
    • WTM - This makes verification of Alpenglow votes a lot simpler for both core developers and the validator node to reason about. This is also a performance improvement because there is saner memory allocation for this task.
  • Agave will preemptively estimate how much time it has left to send transactions to the leader, or will send to the next leader pessimistically instead
    • WTM - This will improve transaction landing rates as slot times go down because it isn’t confident about which slot a transaction will land, nor whether a leader can receive a transaction in time. This gives the TPU client more safety to ensure it doesn’t miss a transaction being sent.
  • Agave will use XDP for the client and server egress of its Votor service
    • WTM - Votor is the Agave service used to facilitate votes and consensus. This proposal changes the protocol by which votes are sent from QUIC datagrams to XDP over QUIC. Using XDP bypasses the normal stack used to connect to the internet and is much faster. Agave already uses XDP in several places, so this change is a straightforward one.
  • Agave will make program deployments cheaper with V1 transactions enabled under solana program deploy
    • WTM - Deployments create several buffer accounts storing data and will need transactions to write to them. Because transaction sizes are now four times larger, you can pack more data for sending and writing. Therefore, using V1 transactions to deploy programs will be four times cheaper in terms of transaction fees paid.
  • Firedancer has implemented its own TLS implementation and will no longer use OpenSSL
    • WTM - This change allows Firedancer to tailor-fit TLS to its own needs, especially since there are performance-specific issues that can be resolved by doing it this way. OpenSSL is meant for things like web services. A validator would possibly need to be more performant in making TLS handshakes than your regular web server.
  • Firedancer has implemented a batch of 8 signings of ed25519 messages
    • WTM - This is a cryptography change that improves performance on message signing. This would matter during signature verification and during the signing of outgoing validator messages.

Solana Program Library (SPL) and Core BPF

  • The Token-2022 program will use the pinocchio entrypoint instead of the native one.
    • WTM - This change allows Token-2022 to be more performant, similar to the performance gains on the Token Program brought about during the implementation of p-token.

Solana program frameworks (Anchor, Pinocchio, Steel, Quasar)

Other interesting things

Developer Events

Last Week’s Issue

https://x.com/solana_devs/status/2098023409976492318?s=20

Share this article
Solana network upgrades tracker showing Agave releases and activation status

Network Upgrades

Network Upgrades

Track every Solana protocol upgrade in one place: Alpenglow and 150ms finality, 200ms slot times, rent down 90%, each listed by Agave release, activation status, and the action validators need to take. See what lands next.

See the latest status
Использовать Solana
Разработка
Для бизнеса
Продукты
Экосистема
ИИ-агенты
© 2026 Solana Foundation. Все права защищены.