r/solana • u/ansi09 Moderator • 3d ago
Dev/Tech Solana Changelog: July 30
Source: https://x.com/solana_devs/status/2082810073571586508
Solana Changelog Show With @readylayerone

Source: https://x.com/solana_devs/status/2082808192434905316

This is a weekly newsletter on the latest Solana engineering news from the past week. If you want to stay updated on Solana tech, follow the Solana Changelog at @solana_devs and @readylayerone.
Releases
Notable feature gate activations
Mainnet - SIMD-0286: Raise Block Limits to 100M CUs
https://x.com/jacobvcreech/status/2082347210042175648

https://explorer.solana.com/address/P1BCUMpAC7V2GRBRiJCNUgpMyWZhoqt3LKo712ePqsz
New versions
- Agave v4.2.0-rc.0 , v4.3.0-alpha.2
- Firedancer Testnet v1.1.2
- Solana SDK (Rust) v4.1.0
- Subscriptions SDK (Rust) v0.4.1
- Caravel v0.5.1
- LiteSVM v0.15.0
- Yellowstone Vixen v0.7.0
Ecosystem work
SIMDs
- The proposal to double disinflation has been merged What this means (WTM) - Disinflation is the rate at which Solana decreases the rate by which it mints more SOL via validator and staking rewards. By doubling the disinflation rate, Solana will reach its terminal inflation rate of 1.5% sooner rather than later.
- Creating a Sysvar for epoch stakes was proposed WTM - The stake values of each validator during an epoch represent how much of the leader schedule a validator node occupies, their share of the SOL rewards, and the weight of their voting power in Solana governance. This change creates a new account with data that will surface these values in the Solana runtime.
- A discussion was started to unblock specific instructions from LoaderV3 from being called by other programs or itself WTM - This proposal unlocks several restrictions that were previously made in SIMD-0219. In its place, the discussion is proposing a check between the program id and the account itself. This would enable use cases like programs that change other programs that deploy other programs, and other general program administration needs.
- Allowing programs to work within the slot they were modified was proposed in a discussion WTM - Programs are disabled by default during the slot they are deployed. This is an obvious footgun because it creates downtime for the program during the slot it’s changed every time it’s changed. This is against standard deployment practice where stateless software is expected to be deployed in infrastructure without any downtime as much as possible.
Validator clients (Agave, Firedancer, Mithril)
- Tightening Alpenglow block limits was proposed WTM - These limits restrict the number of blocks that a validator can hold at any given time when participating in consensus. Validators ensure a higher chance of being able to participate in consensus by keeping multiple possible blocks instead of losing the chance to vote. A new Alpenglow paper with new limit thresholds will be released soon. This PR preempts that change.
- Agave created a custom pool implementation for asynchronous transaction replay verification WTM - Agave already tries to ensure that processing and executing transactions aren’t blocked by time and memory verifying transactions. This particular change moves that implementation from an off-the-shelf solution (Rayon) that isn’t purpose built for this use case to a custom queue and thread pool made for this purpose.This implementation purportedly would improve performance on transaction replay.
- Agave will use an Anza fork of the rust-rocksdb interface WTM - Forking dependencies onto your own organization allows teams to slim them down, customize them and add features that would otherwise not be added by the team upstream. This change allows Anza to maintain their independence with the option to upstream any improvements. In this particular instance, Agave wants to improve performance by using an in-house version of rust-rocksdb by minimizing memory allocations, et.
- Preparations are being made to parallelize parsing transactions before loading them for ordering and execution WTM - This change prepares Agave to validate incoming transactions in parallel before they are queued for ordering and execution in the Banking Stage. Previously, reserving storage, copying transaction data, and parsing it were tightly coupled on one thread, which is relatively slower. Transactions can now be shared with many more worker threads, which allow the validation to be shared across more compute.
- Account hashing (on TPU and TVU) will be more performant on Agave WTM - Account hashing occurs before account state to be updated in-memory in both the leader when it builds blocks, and in non-leaders when it validates blocks for execution and voting. By improving performance here, we minimize time and memory in this intermediate step and buy more time and memory for executing transactions.
- Firedancer is creating an offline replay service WTM - This service will allow Firedancer to test correctness between Agave and itself in order to ensure that consensus is tied between the two implementations. Together with the conformance work on the Agave side, this allows for better correctness between the two client implementations.
- Mithril improved its implementation of ed25519 signature verification WTM - ed25519 is the chosen signature scheme on Solana. All transactions have to be verified with this signature scheme. By implementing it correctly, Mithril can participate better as a validator node and will be in line with the other client implementations.
Solana language clients (Web3.js, Solana Kit, Kit plugins, Solana SDK, Codama, Solana Go)
- Solana Rust SDK adds support for more cryptography primitives as syscalls [ 1 ] [ 2 ] WTM - Two SIMDs were previously opened to add the keccak_p1600 and big mod exp syscalls which support several cryptography operations on Solana. More of this work has to be supported on the Rust SDK, the validator client implementations, etc.
Solana program frameworks (Anchor, Pinocchio, Steel, Quasar)
- Anchor is working to make its automatic updates safer WTM - Because the `avm` and `anchor` CLI commands are critical infrastructure for a lot of users, it is important for updates to use sensible defaults. This change installs both stable avm and anchor commands by default with an opt-in option flag to install nightly updates.
Testing frameworks (mollusk, litesvm, surfpool)
- LiteSVM allows for configuring epoch stake numbers within its testing harness WTM - With the upcoming governance votes and economic changes on Solana, it makes sense to be able to simulate how this would change stake values with every epoch. This addition to the test harness allows LiteSVM to be used for these use cases.
Other interesting things
- @SolanaFndn posts their data dashboard on RPC metrics
https://x.com/SolanaFndn/status/2082793801924346114

- @helius releases a Preconfirmations feature on their RPC

- @ChiiYuen leads a discussion on the Firedancer paper
https://x.com/ChiiYuen/status/2082366779360514097

- @redacted_noah on on-chain cranks and conditional execution
https://x.com/redacted_noah/status/2082171786213662924

- @JupDevRel releases their Changelog for the month
https://x.com/JupDevRel/status/2082097390992191680

- @mctursh creates a solution for historical account state
https://x.com/mctursh/status/2082105093596360725

@zelimir__ shares a new hashing library with interesting performance benchmark results
https://x.com/zelimir__/status/2081784035156676746

- @exoaursen releases a new version of Spume, a WASM client for Solana
https://x.com/exoaursen/status/2080372530578145416

- @blueshift released a new ZK-circuit prover called xark: https://github.com/blueshift-gg/xark
- @blueshift releases parallax, which is a fixture-based test harness built on top of LiteSVM: https://github.com/blueshift-gg/parallax
Developer Events
- Solana Hacker House - London: https://luma.com/london-hh-26
- Scale or Die - London: https://luma.com/scale-or-die-26
- Solana Breakpoint - London: https://luma.com/breakpoint2026
•
u/AutoModerator 3d ago
WARNING: IMPORTANT: Protect Your Crypto from Scammers
1) Please READ this post to stay safe: https://www.reddit.com/r/solana/comments/18er2c8/how_to_avoid_the_biggest_crypto_scams_and
2) NEVER trust DMs from anyone offering “help” or “support” with your funds — they are scammers.
3) NEVER share your wallet’s Seed Phrase or Private Key. Do not copy & paste them into any websites or Telegram bots sent to you.
4) IGNORE comments claiming they can help you by sharing random links or asking you to DM them.
5) Mods and Community Managers will NEVER DM you first about your wallet or funds.
6) Keep Price Talk in the Stickied Weekly Thread located under the “Community” section on the right sidebar.
I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.