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.
Releases
Notable feature gates
Testnet
New versions
- Agave v4.4.0-alpha.5, v4.3.0
- Firedancer Mainnet Release v26.09.4, Testnet v26.09.0
- Frankendancer Mainnet v0.1204.40300
- Superbank v0.6.1
- Shipstern v0.11.0
- Solana Awesome v0.1.1
- Address Lookup Table Program JS SDK v0.15.0
- Stake Program JS SDK v0.10.0
- System Program JS SDK v0.15.0
- Memo Program JS SDK v0.15.0
- Compute Budget Program JS SDK v0.19.0
- Token Program JS SDK v0.17.0
- Token-2022 Program v11.1.0, Rust SDK v3.1.2, JS SDK v0.19.0
- Loader V3 JS SDK v0.7.0
- Single Pool Program JS SDK v3.0.1, Legacy JS SDK v3.0.1
- Record Program JS SDK v0.5.0
- Program Metadata Program JS SDK v0.10.0
- Token Wrap Program JS SDK v2.7.1
- Token ACL Program v0.3.1
- Anchor v1.2.0
- Surfpool v1.6.0
Ecosystem work
Community Validator Discussions
SIMDs
- A proposal was made to allow program uploads larger than 1232 bytes per transaction
- WTM - V1 Transactions increase the total transaction size to 4096 bytes. This constraint is no longer necessary and must be removed.
- A proposal was made to enforce a deterministic ordering within transaction batches
- WTM - Transaction batches are groups of transactions that execute for a proof of history entry. Enforcing ordering here is one way of creating a more deterministic transaction ordering similar to more centralized systems like the NYSE or the NASDAQ.
- A proposal was made to create a syscall that generates pairs for the BN254 curve
- WTM - The BN254 curve is a primitive of many ZK proof schemes for verifying zk SNARKs. This would allow for more privacy use cases which zero-knowledge proofs are known to support.
Validator clients (Agave, Firedancer, Mithril)
- Conformance for V1 Transactions was proposed on Agave, and optimizations on conformance checks were improved with hashing
- 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. V1 transactions are active on Solana Mainnet today. All validators must implement them the exact same way to achieve consensus. Conformance checks at the byte level as implemented previously can also be quite expensive. A hash-based approach makes checking equality much easier since it is one-way, unique enough, and is smaller in size to match.
- Memory allocation improvements for Replay in Agave were made
- WTM - Page faults happen when memory isn’t allocated in a well-defined predictable way in software. It requires the computer to reconcile memory stores it can easily access with what it has to retrieve from your physical memory (your RAM stick). In the case of Replay, it was allocating a lot of memory without a sane way of freeing up that memory for later use when the service has additional work. This change modifies Agave’s current use of jemalloc arenas to solve this problem.
- Work is being done to improve performance in Repair pong handling
- WTM - Software ensures that connections with other computers stay alive with a ping-pong implementation - literally sending simple call and response messages to know if the other person is still connected. This also ensures that the right network peers are sending and receiving repair requests with each other. Because server side responses (pongs) have to be verified, they are expensive to process, when they are simply overhead to persist the connection. This change simplifies that process to do it using less compute.
- Firedancer is adding io_uring support for AccountsDB
- WTM - Reads and writes to accountsdb can sometimes block other processes from running. One way to avoid this is to use what’s called an asynchronous implementation. io_uring is one such implementation that allows work to be shared by the process and the kernel to batch accountsdb entries.
- Firedancer is adding support for running it on RISC-V, along with its ARM implementation
- WTM - Solana did not have a validator node implementation that runs on RISC-V instruction set architectures. This would be the first such implementation and would mean supporting nodes being run on more device types.
- Firedancer made improvements on its networking implementation between XDP and mlx5 interfaces
- WTM - High speed networking interfaces like XDP and mlx5 ensure that the network stays competitive. Both interfaces send raw bytes between devices. Being competitive on this front allows validators to send transactions and shreds to other validators faster.
Solana language clients (Web3.js, Solana Kit, Kit plugins, Solana SDK, Codama, Solana Go)
- Wallet adapter implementations for sign-in with signer and offchain signing implementations have been added to web3js
- WTM - Both SIWS and offchain signing are part of the spec of what makes a wallet usable on Solana. It is important that web3js support these use cases.
Solana Program Library (SPL) and Core BPF
- RUSTSEC-2026-0292: Address Lookup Table Program, Stake Program
- WTM - This advisory is a memory corruption bug in the Rust interfaces. This could crash several apps when exploited
- RUSTSEC-2026-0285: System Program, Token Program
- WTM - This advisory is a bug when establishing secure connections between devices via the `rustls` crate. This could make apps vulnerable to man-in-the-middle attacks and other security and privacy problems.
Solana program frameworks (Anchor, Pinocchio, Steel, Quasar)
- Anchor has ensured compatibility patches of their supported versions for building programs in sBPFv3
- WTM - With the upcoming activation of SIMD-0500, deployments for programs that are not of type sBPFv3 will be disabled. Anchor has added patches for versions 0.30 to 0.32 in order to ensure their legacy users can still deploy their programs without having to upgrade to a major or minor version, saving a ton of developer headache.
- Anchor will delineate multisig signers from its remaining accounts in its SPL-Token v2 implementation
- WTM - This is a bug that interprets an overlap between multisignature signers and remaining accounts (the extra accounts passed to an instruction in a transaction that an instruction handler separates from the expected). This change fixes that for Anchor’s implementation of its Token Program interface.
Other interesting things
Firedancer has made an implementation of a Solana validator on RISC-V architectures.
Solana Microscope has been open sourced.
@accretion_xyz shared an article on how to write tests for Solana programs.
sbpf and sbpf-linker crates released new versions.
@0xnaga released an implementation of Solana’s proof of history.
@cesp2099 shared their experience deploying a Solana program the usual way versus Transaction V1 + sBPFv3.
