> ## Content Index
> Fetch the complete content index at: https://www.solanahorizon.com/llms.txt
> Use this file to discover other available public pages before exploring further.

# Solana web3.js v3 Becomes npm Default With Kit-Based Internals
- URL: https://www.solanahorizon.com/solana-web3-js-v3-becomes-npm-default-with-kit-based-internals/
- Published: 2026-10-21T02:16:40.000Z
- Updated: 2026-10-21T02:16:39.000Z
- Description: The upgrade preserves familiar classes but changes signing, data types, and transaction confirmation defaults.
- Author: Bart Hillerich
- Tags: News, Solana, Solana Foundation

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](https://www.npmjs.com/package/@solana/web3.js?ref=solanahorizon.com), 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](https://github.com/solana-foundation/solana-web3.js/releases?ref=solanahorizon.com), 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](https://solana.com/news/solana-changelog-october-8-2026?ref=solanahorizon.com) 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:

```bash
npm install @solana/web3.js
```

An 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](https://docs.npmjs.com/cli/v11/commands/npm-install?ref=solanahorizon.com) 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:

```bash
npm view @solana/web3.js dist-tags
npm ls @solana/web3.js
```

## Familiar 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](https://solana.com/docs/clients/official/javascript?ref=solanahorizon.com), 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](https://github.com/solana-foundation/solana-web3.js/blob/main/packages/web3.js/RELEASE%5FNOTES.md?ref=solanahorizon.com).

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](https://github.com/solana-foundation/solana-web3.js/blob/main/docs/web3js-v1-to-v3-migration.md?ref=solanahorizon.com) 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](https://solana.com/docs/frontend/web3-compat?ref=solanahorizon.com) 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:

```bash
npm install @solana/web3.js@1
```

That 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.