Developers installing @solana/web3.js without a version selector now get v3, the Kit-based rebuild of Solana's class-based JavaScript SDK. The package's latest release is 3.1.1, published Oct. 19.
The change brings existing web3.js conventions onto newer infrastructure without requiring developers to abandon classes such as Connection, PublicKey, and Transaction. Upgrading a v1 application still requires changes to signing, numeric types, binary data, and some RPC behavior. Legacy v1 remains available but receives only critical fixes.
What the npm Default Changes
The switch follows the rollout set out in the v3.0.0 release, which shipped Oct. 1 under npm's next distribution tag ahead of a planned Oct. 19 promotion to latest. Solana's Oct. 8 developer changelog had directed developers to request v3 explicitly; it is now the default line.
The standard installation command selects v3 in a new project with npm's default settings and a compatible runtime:
npm install @solana/web3.jsAn existing application with a v1-only dependency range, such as ^1.99.0, does not jump to v3 simply because the tag changed. npm resolves existing dependencies within their declared ranges and uses matching lockfile versions. The tag change affects new package selections; existing applications keep resolving dependencies within their declared ranges.
Developers can inspect the registry tags and their project's installed version separately:
npm view @solana/web3.js dist-tags
npm ls @solana/web3.jsFamiliar Classes, Kit Underneath
Version 3 replaces the older RPC plumbing with typed Solana Kit HTTP and WebSocket transports. Its class-based interface remains, while signing, account decoding, and transaction handling use Kit-compatible primitives.
Developers upgrading existing web3.js applications or preferring its class-based API can use v3. Solana Kit remains the recommended TypeScript SDK for new builds, with composable plugins and generated clients for onchain programs.
Version 3.1.0 lets developers pass a Connection directly to Kit-native libraries, including Anchor 2 and Codama-generated @solana-program/* clients. It implements Kit client interfaces for RPC, subscriptions, and minimum-balance queries, so developers can reuse it instead of creating a second RPC client. The release examples show a Connection supplying rent information to a token mint-creation helper and working with an Anchor provider.
A v3 Keypair also implements Kit's signer interface, while PublicKey.toBase58() returns Kit's branded address string. Existing web3.js code can keep using keypair.publicKey for class methods; keypair.address is the base58 string used for Kit signer interoperability.
The release line also introduces @solana/wallet-adapter, with Sign In With Solana 1.1 support and standalone signing. Version 3.1.1 of that package ships alongside web3.js 3.1.1.
Where v1 Applications Need Changes
Version 3 keeps familiar class names but changes behavior that affects application code and tests.
Signing and serialization are now asynchronous. Keypair.generate(), Keypair.fromSecretKey(), and Keypair.fromSeed() return promises, and applications must also await transaction signing, Transaction.serialize(), and Transaction.verifySignatures(). Functions that generate a key before signing and serializing a transaction must await each step.
Applications must replace the old {publicKey, secretKey} signer object with a Keypair or another compatible Kit transaction signer. They can import existing secret-key bytes with await Keypair.fromSecretKey(...).
Many numeric RPC results now use bigint rather than JavaScript number, and account data uses Uint8Array instead of Buffer. Raw bigint values cause JSON.stringify() to throw without a replacer, so these changes affect runtime behavior as well as TypeScript checks. Applications using older Buffer-based decoders must convert the data before passing it to those decoders and copy readonly RPC collections before modifying them in place.
A Connection created without an explicit commitment now defaults to confirmed. Applications relying on the previous default of finalized should specify it explicitly.
Version 3 removes the legacy Account class, PublicKey.unique(), and FeeCalculator-related methods. getMinimumBalanceForRentExemption() now propagates RPC failures instead of resolving to zero, so callers must handle a rejected rent query rather than interpret it as a rent-free account.
Token integrations need a separate dependency review. @solana/spl-token depends on legacy web3.js and does not run on v3. Its replacements are @solana-program/token and @solana-program/token-2022; their generated instructions and instruction plans work with v3's Transaction.add().
Upgrading or Keeping v1
The official v1-to-v3 migration guide starts at shared imports and wrapper modules, then moves through removed APIs, key handling, asynchronous transaction flows, and RPC types. It recommends testing each affected slice before running a broader integration path covering transaction sending and account reads.
Teams considering a fuller architectural change can use Solana's Kit migration overview to map legacy classes and helpers onto Kit's client, signer, wallet, and transaction-building equivalents.
Applications staying on the older API can explicitly request the v1 release line:
npm install @solana/web3.js@1That selects a v1 release rather than pinning an exact patch. The legacy code lives on maintenance/v1.x and receives critical fixes only. Keeping a v1-compatible range and a committed lockfile lets a team preserve its dependency line while scheduling the migration.
