ChangelogOctober 16, 2026bySolana FoundationSolana Foundation

Solana Changelog: October 16, 2026

This is a weekly newsletter on the latest Solana engineering news this week. If you want to stay updated on Solana tech every week, follow Solana Changelog at @solana_devs and @readylayerone and turn on notifications.

PSA

npm install @solana/web3.js@3

Solana Web3.js v3.1 has been released. Update your web project dependencies using the command above. This version interoperates more closely with Solana Kit, Solana Wallet Adapter, Surfpool, Anchor, Codama, and SPL interfaces.

Releases

New versions

Ecosystem work

Community Validator Discussions

October 8, 2026

SIMDs

  • Compute unit costs for syscalls on the Secp256r1 curve were proposed

    • WTM (what this means) - Solana uses compute units (CUs) to account for the operations validators perform. This allows the protocol to limit the compute in a block and weight operations based on execution time and memory use. These units are mostly assigned arbitrarily today; for example, System Program instructions cost 10 CUs each. This proposal specifies how many CUs each operation on the cryptographic curve would cost.
  • A discussion to increase CU limits to their previous levels following reduced slot times was proposed

    • WTM - CU limits per slot decreased when slot times were reduced. The allowed CU throughput per unit of time onchain did not change, but the limits had to be reduced to implement shorter slots. This proposal would increase those limits now that 200ms slot times have reached Mainnet.
  • Post-Alpenglow improvements to the consensus implementation are being discussed

    • WTM - Alpenglow will be activated on Mainnet soon. During its development, core developers identified ways to improve the implementation further. The proposed changes include preparation for a new multiple-proposer algorithm called minCP.

Validator clients (Agave, Firedancer, Mithril)

  • Agave is working on an events system

    • WTM - Geyser is the current way to stream blockchain events to users on Solana, but those are protocol-specific rather than Agave-specific events. An Agave events system would support custom metrics and more detailed performance measurement.
  • Agave is planning an in-protocol measure to limit transaction execution time

    • WTM - Transactions do not have a well-defined execution time limit on Solana. This draft proposal explores how to implement one. A limit would allow the runtime to abort transactions earlier and process others that are waiting. The change may require a SIMD, depending on the final implementation.
  • Agave is reducing Sigverify shred batches from 1,024 to 128

    • WTM - Memory must be allocated to create and process Sigverify batches. Decreasing the number of shreds per batch means Sigverify can work with less data at a time, move to the next batch faster, and use less memory.
  • Firedancer has made memory improvements to its implementation of Votor

    • WTM - Votor relies on offchain messaging to pass votes, which can generate substantial vote traffic and require many memory allocations for connection handling. This implementation uses those resources more efficiently.

RPC 2.0

Solana language clients (Web3.js, Solana Kit, Kit plugins, Solana SDK, Codama, Solana Go)

  • Solana Web3.js will use a Solana Kit client to handle API connections

    • WTM - Using the Kit client allows Web3.js to reuse existing connection-handling tools. Web3.js provides legacy APIs while using Solana Kit internals under the hood.
  • FluxRPC’s Solana Go will implement a custom getMultipleAccountsImmutable method

    • WTM - This handler adds a cache layer for fetching multiple accounts whose data schema does not change.

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

  • Anchor is working to have its AVM CLI use the latest cargo-build-sbf installed on the user’s machine

    • WTM - Previous versions of the AVM CLI use older versions of cargo-build-sbf. Upcoming changes will enforce sBPFv3-only deployments, causing programs compiled to older versions to be rejected. This change uses the latest installed version so Anchor programs compile to sBPFv3 by default and can deploy onchain.
  • Anchor is exploring the use of sbpf-linker and upstream BPF compilers

    • WTM - This change would use an upstream BPF compiler instead of the custom toolchain commonly shipped by Solana program frameworks. It would simplify the development tooling stack and its dependencies.

Testing frameworks (Mollusk, LiteSVM, Surfpool)

  • Surfpool is working to let users take a snapshot of account state while using its scenarios feature
    • WTM - This feature would let users inspect account state changes for a given scenario and run tests against them, supporting scenario planning during program development.

Other interesting things

  • @L0STE_ shared a new primitive for pull payments

  • @solanamobile announced Ledger as its first hardware expansion partner

  • @typi_cal_ shared operational security improvements to the Umbra privacy protocol

  • @gansersol from @multisig showed post-quantum signing via Falcon-512 working in an app, with support from @bill_papas_12 from @unruggable_io

  • @raikucom shared a sidecar validator service

  • @anza_xyz announced the Alpenglow launch date on Mainnet

  • @gabrielmkoerich implemented a Pinocchio counter program that compiles with the upstream BPF compiler

  • @mikemaccana announced a new book about building financial products on Solana

  • @r0bre showed how to check a Ledger device following exploits observed during the previous week

  • The Durable Nonce deprecation announcement is live

  • @webtm from @triton_one created an interactive guide to how Superbank works

Open Developer Roles

  • Helius is hiring a developer advocate for its data platform

Last Week’s Issue

Share this article