Solana SDK Evolution: What's Changing Next for Bot Builders

When the Foundation Shifts Under Your Feet

Writing a Solana bot in 2026 feels a little like remodeling a house while the contractor is replacing the foundation underneath you. The chain itself is fine — fast, predictable, throughput-rich. But the libraries I depend on to read state, sign transactions, and ship code on-chain are in the middle of the biggest overhaul I've seen since I started this project. Both the JavaScript SDK and the Rust SDK have effectively been redesigned from scratch, and the changes are not optional in any long-term sense.

For a solo developer maintaining an MEV bot, an SDK rewrite is not an academic event. Every renamed type, every removed field, every package that splits into ten smaller packages is something I'll eventually have to chase through my own code. So this is the post I keep promising myself I'll write: a survey of where the Solana SDK landscape is right now, what's coming, and why a bot builder should care about each piece.

The JavaScript Reset: web3.js v1 to @solana/kit

The first big shift is on the JavaScript side. According to Anza Labs, @solana/web3.js version 2.0.0 was released on November 7, 2024, with the package landing on NPM on December 16, 2024. Soon after, the package was renamed entirely. What used to be @solana/web3.js@2 is now distributed as @solana/kit. Anza Labs launched a dedicated documentation site for it at www.solanakit.com on August 27, 2025, and per their announcement, @solana/kit is now the recommended SDK for all new dApps, with the v1.x line described as stable but no longer being actively improved.

What does that mean in practice? It means that anyone whose bot was scaffolded against web3.js v1 is on a slowly decaying branch. Critical bugs may still get patched, but new features, performance work, and ecosystem alignment are all moving to Kit. It's the difference between owning a car that's still under warranty and owning one that has officially gone out of production. The vehicle still runs, but the dealer is no longer ordering parts.

The more uncomfortable detail is that this is not a polite, incremental upgrade. The Anza release notes describe the v1-to-v2 transition as a completely incompatible API change. Almost every concept a v1 user knows has been renamed, restructured, or replaced.

What Kit Actually Looks Like

To see how disruptive the change is, look at the most basic operations a bot performs. According to Anza Labs' release post, the v1 Keypair class is replaced by KeyPairSigner, generated via generateKeyPairSigner() instead of Keypair.generate(). The familiar PublicKey class is replaced by a lighter address type produced by an address() function. Numeric amounts no longer ride on JavaScript number values; they use native BigInt with the n suffix, so 1_000_000 becomes 1_000_000n.

Transaction construction has also been overhauled. Helius's walkthrough describes the new flow as functional rather than class-based: you create a message, set the fee payer, set the lifetime, append instructions, and sign — all composed through a pipe() function. Anza Labs's blog notes that the version-aware message type also collapses the old split between Transaction and VersionedTransaction into a single concept, which is a quiet but huge ergonomic win.

Under the hood, Kit is built as a constellation of small, tree-shakable modules: @solana/rpc, @solana/rpc-subscriptions, @solana/transactions, @solana/accounts, @solana/codecs, @solana/signers, and more. The Helius post highlights complementary packages like @solana-program/system and @solana-program/compute-budget, which expose the System Program and compute budget instructions in a typed, on-chain-aware way.

The most attention-grabbing claims, though, are about performance.

Why Kit Is Faster (and Why It Matters for Bots)

According to Anza Labs, cryptographic operations — keypair generation, signing, and verification — are substantially faster in the new SDK because it leans on native cryptography APIs in modern Node.js and browsers. Bundle sizes drop meaningfully too: Triton One's measurement of the Solana Explorer homepage's landing bundle showed a 26% reduction — from 311 KB to 226 KB — after the migration.

The number that should make any latency-obsessed bot builder pay attention, however, is confirmation time. The same Ping Thing benchmark observed roughly 200 milliseconds faster confirmation latency for Kit compared to web3.js v1, with slot latency unchanged. That kind of improvement isn't a vanity metric. For a bot that competes on inclusion timing, 200ms is the difference between landing in a block and missing it. It's also the difference between a clean confirmation poll and an unnecessary retry, and retries are where bot accounting tends to bleed.

For context, that's roughly the time it takes to blink twice. In MEV terms, it's a small eternity.

The Cost of the Migration

Kit isn't free, of course. The migration table is long, and every breaking change is somewhere a v1 codebase has to be touched. There are a few softeners: a @solana/compat library is available that lets developers interoperate between legacy v1 objects like VersionedTransaction, PublicKey, and Keypair and the new types Address, Transaction, and CryptoKeyPair. That bridge is what makes it possible to migrate incrementally rather than as a big-bang rewrite, which is how anyone with a production bot will actually want to do it.

There's also a subtler but important issue: ecosystem readiness. Anza's release notes specifically flag that as of early 2025, Anchor framework support for Kit was still pending, with a workaround that uses the Codama framework to generate clients for custom programs. For developers whose bots talk to a lot of Anchor-based DEXes, that's a real blocker, and it explains why some teams have been slow to switch. The good news is the ecosystem is moving. Adoption signals from prominent Solana toolchains and SDKs suggest the new package is not a research project.

The Rust SDK Is Also Being Rebuilt

If the JavaScript story were the only thing happening, that would be enough. But the Rust side of the house is going through an arguably more dramatic transition. According to a session writeup from Solana Compass covering Accelerate 2025, the old solana-sdk crate had grown into a monster. Building a simple program would pull in around 147 crates and take roughly 24 seconds. The same example program against the new SDK builds with around 21 crates in under 3 seconds.

That is a dramatic improvement, and it isn't an artifact of test-rig setup. Solana Compass quotes broader figures from the same talk: the old SDK required roughly 300 crates for off-chain use and 150 crates for on-chain use. The new architecture is structured as approximately 100 component crates, hosted in a separate repository under the Anza organization, with semantic versioning that the old monolith never quite achieved. Crucially, it's also decoupled from the Solana validator (Agave) release cycle, which means SDK changes no longer have to wait for, or align with, validator releases.

The anza-xyz/solana-sdk GitHub repository shows just how granular the decomposition is. There are more than fifty extracted modules, including names like solana-address-lookup-table-interface, solana-bn254 (formerly alt_bn128), solana-client-traits, solana-commitment-config, solana-nonce, and solana-nonce-account. As of the repository state checked on May 23, 2026, it lists 379 total releases, with the latest being [email protected] released on May 21, 2026. The current stable line per Solana Compass is the 2.2.x series.

It's the Rust equivalent of replacing a single all-in-one kitchen appliance with a separate fridge, stove, dishwasher, and microwave. More moving parts, yes, but each can be upgraded, swapped, or even uninstalled independently.

v3 Is Coming, and It Will Break Things

The Accelerate 2025 talk also previewed where the Rust SDK is going. Standardized base types across frameworks like Anchor and Pinocchio are on the v3 roadmap, along with a new serialization library that supports zero-copy, simpler enums, and variable-length types. The stated goal is interoperability — making programs written in different frameworks talk to each other without the awkward conversion gymnastics today's developers know all too well.

The official GitHub repository lays out an explicit migration strategy: "The easiest way to upgrade to v3 is: upgrade to the latest v2 crates, fix all deprecation warnings, (optional) switch to using SPL interface crates v1, upgrade to v3-compatible crates." That stepwise approach matters because it means projects don't have to flip everything at once. They can chase deprecation warnings on v2, knock them down one at a time, and then take the v3 jump.

The breaking changes in v3 itself are not small. Per the repository docs, the SDK introduces a new Address type that conceptually replaces uses of Pubkey — Pubkey becomes a type alias of Address, which eliminates naming confusion while preserving compatibility. The rent_epoch field on AccountInfo is removed and labeled _unused, reflecting that rent epoch is no longer meaningful in modern Solana. The inner bytes of Hash are now private, requiring Hash::as_bytes() for access. On-chain memory operations are marked unsafe, forcing developers to acknowledge what they're doing when they reach into raw memory. And the keypair constructor moves from Keypair::from_bytes to Keypair::try_from.

There are also SPL-side renames. The repository lists the migration from spl-token to spl-token-interface v2, from spl-token-2022 to spl-token-2022-interface v2, and from spl-associated-token-account to its corresponding interface v2. For a bot that swaps across DEX protocols and touches both classic SPL and Token-2022 mints, that's a non-trivial chunk of imports to update.

CLI and Runtime: Smaller Headlines, Real Impact

While the SDKs get most of the attention, the CLI and runtime are evolving in parallel, and the changes affect deployment workflows directly. Solana Compass reports that from Agave 2.2 onward, the CLI exposes a skip preflight check parameter — useful when the developer is confident the program will pass and wants to avoid the round-trip cost of running it locally first.

The deployment-time numbers from that same source are striking. For an average Anchor program, deploying via public endpoints can take around 10 minutes, while using paid nodes with the --use-rpc-for-write flag can bring that down to seconds. The gap isn't really about the SDK; it's about the realities of public RPC throughput. But the CLI improvements make it possible to choose the right path more deliberately.

On the runtime side, SIMD-0191 — authored by Andrew Fitzgerald at Anza, per Solana Compass — relaxes transaction constraints around loading failures and lets validators collect fees for transactions they process, even if those transactions ultimately fail. The economic logic is straightforward: validators were doing work without compensation, which is unsustainable. SIMD-163 lifts certain CPI caller restrictions, which Solana Compass describes as eliminating double deserialization and improving the efficiency of all CPI-heavy transactions. The program cache size has been doubled for validators, reducing the frequency of automatic program eviction, and the executable flag check on the runtime has been replaced by owner checks. The latter sounds minor but is the kind of subtle correctness improvement that bot developers benefit from without ever noticing.

The same Solana Compass changelog also introduces a new tool called Velos — a data streaming client that the source describes as offering up to 50% reduction in infrastructure costs for indexing Solana data. Whether that holds up under real load is something every team will need to test for themselves, but the existence of more options for indexing is unambiguously good.

The Enterprise Layer: Solana Developer Platform

A different category of change worth tracking is the Solana Developer Platform, launched in 2026. This isn't an SDK per se. It's a set of API modules — Issuance, Payments, and Trading — designed to give enterprises a higher-level entry point into the chain. Per the Solana Foundation's announcement, the Payments module is live at launch, the Trading module is launching later in 2026, and the Issuance module covers tokenized deposits, stablecoin issuance, and tokenized real-world assets.

Why mention this in a bot-builder context? Because the Developer Platform's existence reshapes the ecosystem around the SDK. According to The Block, early enterprise partners include Mastercard, Worldpay, and Western Union — names that bring volume and seriousness to the chain whether or not a solo bot developer interacts with them directly. The Foundation also lists more than twenty infrastructure partners spanning node operators, wallets, compliance vendors, and on/off-ramps. More volume, more flow, more legitimate use cases mean more arbitrage opportunities and, equivalently, more sophisticated competition.

The Solana Foundation also notes that the platform is compatible with mainstream AI coding assistants. I'm not naming the specific tools here, but the broader signal is that infrastructure providers are explicitly designing for an AI-augmented development workflow. That's a tailwind for solo builders who pair with AI tools — and a reminder that the moats around bot work are eroding faster than they used to.

What's Underneath: Firedancer and Alpenglow

It would be misleading to talk about SDK evolution without acknowledging the network-level changes that motivate it. The validator client overhaul, Firedancer — developed by Jump Crypto — is the largest of these. According to Solana Compass's 2025 roadmap coverage, Firedancer's internal tests can push throughput to roughly 1 million TPS, an order-of-magnitude improvement over the pre-upgrade ceiling. A hybrid version called "Frankendancer" was already running on 207 validators as of October 2025, up from 32 in June 2025, with full mainnet deployment expected in Q2 2026.

Separately, the Alpenglow consensus upgrade announced in May 2025 targets finality of about 150 milliseconds using a lightweight voting system. Per the same Solana Compass coverage, Alpenglow's testnet was planned for December 2025 with mainnet integration in Q1 2026.

From a bot perspective, these matter because every order-of-magnitude throughput improvement on the chain raises the bar on what the SDK has to deliver. A client library that holds up at 60,000 TPS may not hold up at 600,000. A confirmation poll that costs nothing today may flood an RPC under tomorrow's load. The Kit performance work — faster crypto, smaller bundles, lower latency — only makes sense in a world where the chain itself is sprinting faster.

What This Means for a Solo Bot Developer

Putting it all together, the headline reality is that the Solana SDK landscape is moving from monolithic-and-stable to modular-and-versioned. The JavaScript world is mid-migration from web3.js v1 to @solana/kit. The Rust world has already transitioned the underlying SDK to a roughly hundred-crate modular structure and is preparing v3, with breaking changes that touch addresses, hashes, memory, and keypair handling. The CLI and runtime are quietly absorbing fee-fairness fixes and CPI improvements. The enterprise-grade Developer Platform is opening new flows of capital and use cases on top of all of it.

For a solo bot developer, the practical takeaways are not glamorous. They look like this. Pin SDK versions explicitly in CI, because the days when latest was safe are gone. Plan migration windows for both the JS and Rust sides, even if neither feels urgent today. Use compatibility bridges like @solana/compat to migrate incrementally, not all at once. Read the deprecation warnings — they're not noise; they're the v2-to-v3 migration path mapped out for free. And revisit any custom abstractions written against v1, because most of them will need to change or be retired entirely.

There's a temptation to wait it all out, hoping the dust settles. But the chain is moving fast enough that "wait it out" is itself a position. Confirmation latencies are dropping. Bundle sizes are shrinking. Validator-side fee fairness is improving. The teams that adopt early get those benefits compounded, and the teams that don't get to watch their bots inherit a slowly worsening competitive disadvantage.

A Quiet, Important Detail

One thing that sometimes gets lost in coverage of these changes is the architectural philosophy underneath them. Both Kit and the new Rust SDK are doing the same thing in different languages: breaking a single, large, opinionated library into many small, focused libraries that can evolve at their own pace. That's the same playbook that web frameworks went through years ago, and it works. It trades a little ergonomics — more packages to learn, more imports to manage — for a lot of flexibility.

For a bot, flexibility is currency. The faster the SDK can ship a specific fix to a specific module, the faster a bot can benefit from it. Monolithic SDKs hold everyone to the slowest part. Modular SDKs let the fast parts move first.

Key Takeaways

• JavaScript SDK is now @solana/kit, recommended for all new dApps; web3.js v1.x is stable but no longer actively improved, per Anza Labs.
• The v1-to-Kit transition is a full API rewrite — Keypair, PublicKey, numeric handling, and transaction construction all change, with a @solana/compat library available as a transition bridge.
• Performance gains are concrete: cryptographic operations are substantially faster (Anza Labs) and confirmation latency is roughly 200ms lower than web3.js v1 (Ping Thing benchmark).
• The Rust solana-sdk has been modularized into approximately 100 component crates per Solana Compass's Accelerate 2025 coverage, with build times dropping from around 24 seconds to under 3 seconds for a simple example program.
• v3 brings breaking changes including a new Address type, removed rent_epoch field, private Hash bytes, unsafe-marked memory operations, and a new Keypair::try_from constructor, per the anza-xyz/solana-sdk repository.
• CLI, runtime, and enterprise platform improvements are running in parallel, and Firedancer plus Alpenglow are reshaping the throughput and finality ceiling the SDKs have to meet.