Web3.js

Web3.js is a JavaScript library for querying Ethereum and other EVM networks that remains in inherited applications. Its API covers RPC, contracts, accounts and utilities. Differences between package generations matter: a v1 integration does not necessarily behave like a v4 integration.

ChainSafe announced its sunset in 2025 and published migration guidance towards Ethers or Viem. Current work centres on identifying dependencies, preserving required behaviour and planning a tested transition to a maintained library rather than extending reliance on historical examples without checking their version.

Clients use HTTP, WebSocket or EIP-1193-compatible providers to access networks. Contracts are described by address and ABI. Versions differ in numeric formats, errors and APIs, so examples from another generation should not be assumed compatible with the installed package.

Subscriptions receive events but require reconnection and historical recovery after interruptions. Web3.js is a JavaScript project distinct from web3.py: provider names and AsyncWeb3 examples belong to Python and are not valid instructions for this library. Migration documentation needs to preserve that distinction.

Migration starts with an inventory of reads, signatures, transaction submission, events and utilities. Each operation should retain a behavioural test covering response formats and expected errors. Components consuming those results should not change accidentally when the underlying client is replaced.

A bounded integration layer can support gradual migration. Compare balance reads and log decoding before changing signing flows, for example. State-changing transactions need particular attention to nonces, retries and receipt tracking so that the transition preserves operational behaviour as well as data formats.

Temporary maintenance requires understanding support status and avoiding unjustified expansion of the dependency. Migration priority depends on exposure, versions and functions used; its duration cannot be estimated solely from the library name or a generic project size category.

The transition does not necessarily require changing deployed contracts. Its aim is to preserve interfaces and improve application maintainability. Verify unit conversion, errors, cancellations and event recovery, then remove old dependencies once they are no longer used by the project or its integration tools.