# rust-web3: A Multi-Transport Ethereum JSON-RPC Client

> rust-web3 gives Rust applications HTTP, WebSocket, and IPC access to Ethereum JSON-RPC methods. Its transport selection is broad, but the repository labels the package barely maintained and points new projects to ethers-rs.

**tomusdrw/rust-web3** — Ethereum JSON-RPC multi-transport client. Rust implementation of web3 library.  ENS address: rust-web3.eth

- Repository: https://github.com/tomusdrw/rust-web3
- Stars: 1,507 · Forks: 465
- Language: Rust
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/tomusdrw-rust-web3

## Why rust-web3 Targets Ethereum RPC in Rust

rust-web3 addresses a specific integration problem: sending Ethereum JSON-RPC calls from Rust without writing the request serialization, response deserialization, and transport setup for every method. It is aimed at Rust services and command-line applications that interact with Ethereum-compatible JSON-RPC endpoints. The repository describes the crate as an Ethereum JSON-RPC client and a Rust implementation of the Web3.js library, but its actual surface is a native Rust API rather than a JavaScript-compatible runtime layer.

The crate groups calls into `eth()`, `net()`, `web3()`, and `personal()` interfaces. The checked API list covers `eth_*` methods, Ethereum filters, Ethereum pubsub, `net_*`, `web3_*`, `personal_*`, and batch requests. It also provides Ethereum data types such as `U256`, `H256`, `Address` based on `H160`, transaction receipts, rich blocks, work, and syncing statistics. That scope suits applications reading balances, enumerating accounts, creating contract bindings, and reacting to logs.

It is less suitable for Parity-specific and tracing workloads. The README marks `traces_*`, read-only `parity_*`, and `signer_*` as incomplete. Parity accounts are described as partially implemented. A project whose correctness depends on those method families would be adopting a client with known coverage gaps, not a complete replacement for every Ethereum JSON-RPC namespace.

The repository explicitly recommends ethers-rs for new projects. That recommendation matters because rust-web3 is not merely a fresh release waiting for adoption. Its own status section calls the package barely maintained and seeks an active maintainer. The last push was on 2026-04-27, more than six months ago, which further limits the basis for describing current development activity.

## HTTP, WebSocket, and IPC Select the Request Path

A `Web3` instance is constructed from a transport, so the selected object determines how JSON-RPC requests leave the application. The README and feature list confirm three transport families: HTTP, IPC, and WebSockets. HTTP requires a `tokio` runtime because its implementation uses `hyper` through the dependency set. WebSockets can use either `tokio` or `async-std`, depending on the selected feature. IPC uses `ipc-tokio` and is enabled by default.

The example initializes HTTP against a node at `http://localhost:8545`, wraps it with `Web3::new`, and then calls methods through `web3.eth()`. Calls such as `accounts()` and `balance()` return Rust futures. This makes the client suitable for asynchronous applications, but it also means the host application needs a compatible async runtime and must await the returned operations.

Transport choice has operational consequences. WebSockets suit long-lived subscriptions and event streams, which explains the separate `pubsub` examples. IPC can avoid a network listener when an Ethereum client and Rust process run on the same host. HTTP is the simplest fit for ordinary request-response calls, although it does not provide a subscription channel. The repository also includes examples named `transport_batch.rs`, `transport_either.rs`, `transport_http.rs`, and `transport_ws.rs`, indicating support or intended patterns for batching, transport alternatives, and WebSocket use.

TLS is feature-specific rather than uniform. Default HTTP TLS uses `reqwest/default-tls`, while `http-rustls-tls` selects rustls. WebSocket TLS options similarly distinguish native TLS from rustls and distinguish `tokio` from `async-std`. This configurability helps with platform and certificate constraints, but it increases the dependency matrix that maintainers must account for. The futures migration checklist still mentions reconnecting and pings for WebSockets as unfinished work, so persistent connection recovery should not be assumed from transport support alone.

## Adding web3 0.19.0 and Making the First RPC Calls

The README's installation step adds the published `web3` dependency to `Cargo.toml`. Add the following entry under `[dependencies]` in an existing Rust project.

```toml
[dependencies]
web3 = "0.19.0"
```

There is an important version discrepancy to check first. The README names `0.19.0`, while the repository's `Cargo.toml` declares package version `0.20.0`. The README also lists v0.19.0 as the latest stated release. Do not assume that the manifest version represents a published release without checking the package registry used by your build.

For the first HTTP use, create a `tokio` async main, construct the transport, and query accounts and balances. The README provides the following example.

```rust
#[tokio::main]
async fn main() -> web3::Result<()> {
    let transport = web3::transports::Http::new("http://localhost:8545")?;
    let web3 = web3::Web3::new(transport);
    let mut accounts = web3.eth().accounts().await?;
    println!("Accounts: {:?}", accounts);
    Ok(())
}
```

The reader should have an Ethereum JSON-RPC endpoint listening on port `8545`. The call returns an address list and prints it. Exact account availability depends on the node configuration; the README does not document which client flags expose accounts or how authentication is configured.

The longer README example appends a specific address and requests its balance with the `None` block parameter. That detail matters because a single optional argument can affect the JSON-RPC request shape. The API is typed, but provider behavior remains outside the crate's control.

For contract deployment output, the README directs users to `solc` and writes bytecode and ABI files into `build`. This is a compiler step outside the Rust client.

```bash
solc -o build --bin --abi contracts/*.sol
```

After compilation, the repository's `examples/contract.rs` and other files under `examples/` are the documented starting points for contract calls, storage, logs, and pubsub.

## Cargo Features Change Platforms and Native Dependencies

The default feature set is not universally usable. Windows documentation says IPC is unsupported and must be disabled. The documented manifest selects HTTP only.

```toml
web3 = { version = "_", default-features = false, features = ["http"] }
```

The placeholder version `"_"` appears exactly in the README and is not intended as a normal pinned release selection. A real application should substitute its chosen published version before compiling.

On Linux, the README says `native-tls` uses OpenSSL. Applications that want to avoid that dependency can disable default features and select the rustls-based HTTP and WebSocket features.

```toml
web3 = { version = "_", default-features = false, features = ["http-rustls-tls", "ws-rustls-tokio"] }
```

The README also warns that fully reproducing default features requires adding `signing` and `ipc-tokio`. Disabling defaults is therefore a deliberate reduction, not a drop-in replacement for the standard configuration. If local signing is required, omitting `signing` removes the documented account namespace and local-signing support. If IPC is needed, omitting `ipc-tokio` removes that transport.

For browser or other WASM compilation, the feature list requires `wasm` and says to disable default features. For chains that omit fields considered mandatory by Ethereum, `allow-missing-fields` inserts defaults for those fields. That feature names Celo and Fantom as examples, but it can change interpretation of responses, so it should be selected only when the target chain's behavior requires it. `arbitrary_precision` and `eip-1193` serve narrower serialization or provider-interface needs rather than general RPC access.

## Contracts, Custom Namespaces, and Incomplete API Families

Contract support is present through ABI encoding and generated examples, which makes rust-web3 more than a thin account and balance client. The repository includes examples for contract deployment, calls, storage access, log filters, and log pubsub. The README instructs users to compile Solidity contracts with `solc`, producing bytecode and ABI artifacts in `build`. It does not provide a code-generation command in the documented excerpt, so applications should follow the repository's contract example rather than assume an undocumented generator flag.

The client also offers an extension mechanism for custom namespaces. The README shows a `CustomNamespace` accessed through `Web3::api`.

```rust
let web3 = Web3::new(transport);
web3.api::<CustomNamespace>().custom_method().wait().unwrap()
```

This pattern is useful for private or application-specific RPC namespaces, although the example uses `wait()` rather than the async-await style shown by the main HTTP example. A project with a `tokio`-based application will need to account for that API difference.

Coverage is the larger constraint. The checked boxes in the README indicate Ethereum, network, web3, personal, selected Parity set methods, batch requests, and extendable own APIs. The unchecked boxes explicitly include Ethereum tracing, Parity read-only methods, Parity accounts, and `signer_*`. The unchecked futures migration items include removal of `parking_lot`, reconsideration of `Unpin` requirements, and WebSocket reconnecting and pings. These entries describe known boundaries in the documented roadmap. They do not guarantee breakage in every build, but they prevent a fair evaluation from treating the crate as a complete, actively finished Ethereum SDK.

## Licensing and Upgrade Cost for Existing Integrations

The package is distributed under the MIT license, as stated in both the repository metadata and `Cargo.toml`. That permits use and modification under the license's conditions, but this review does not interpret the license text or provide legal advice. Projects still need to account for their own dependency licenses and distribution obligations.

The direct upgrade cost is potentially higher than the small crate surface suggests. A Rust application depends on an older async ecosystem arrangement: `parking_lot`, futures-related abstractions, `Unpin` concerns, and multiple runtime choices appear in the README and manifest. HTTP dependencies include `reqwest` and `bytes`, WebSocket support spans several TLS and runtime variants, and IPC defaults to `ipc-tokio`. Moving from the README's `0.19.0` to a future release can therefore involve more than changing an API call if dependencies, feature defaults, or runtime assumptions have changed.

The custom namespace mechanism lowers the cost of adding proprietary methods because it does not require every namespace to be built into the core client. Feature flags can also reduce platform-specific dependency pressure. Against that, the maintenance notice and long gap since the latest listed release increase the chance that adoption decisions depend on your own compatibility work.

ethers-rs is the real alternative named by the project. Its recommended status is explicit in the README, but the excerpt does not document its API, transport list, feature configuration, or migration procedure. The defensible comparison is therefore limited: rust-web3 documents HTTP, IPC, WebSockets, typed Ethereum methods, contracts, and custom namespaces, while its maintainer directs new projects to ethers-rs. Confirm the alternative's current interfaces directly before committing to a rewrite.

## Conclusion

Adopt rust-web3 when an existing Rust application needs its established Ethereum method wrappers or a transport configuration that matches its architecture. Do not choose it for a new Ethereum stack without first checking compatibility with ethers-rs, current releases, dependency versions, and the transports your node exposes. The repository's own status notice is the decisive starting point because it labels the package barely maintained, while the last recorded release predates the current Cargo.toml version.

## FAQ

### Which transports does rust-web3 support?

The README and Cargo feature list identify HTTP, IPC, and WebSockets transports. HTTP requires `tokio`, WebSockets can use supported `tokio` or `async-std` features, and IPC uses `ipc-tokio`.

### How do I install rust-web3 for a Rust project?

The README instructs users to add `web3 = "0.19.0"` under `[dependencies]` in `Cargo.toml`. The repository manifest declares version `0.20.0`, so the intended package version should be checked before choosing a dependency declaration.

### Is rust-web3 actively maintained?

The README calls the package barely maintained and asks for an active maintainer. It also recommends ethers-rs for new projects, while the repository records its last push on 2026-04-27.

### Does rust-web3 work on Windows and with rustls?

The README says Windows does not support IPC and documents disabling default features with the `http` feature. It also documents `http-rustls-tls` and `ws-rustls-tokio` as alternatives to the default native TLS dependencies.

## Sources

- [Issues](https://github.com/tomusdrw/rust-web3/issues)
- [License: MIT](https://github.com/tomusdrw/rust-web3/blob/master/LICENSE)
- [README](https://github.com/tomusdrw/rust-web3/blob/master/README.md)
- [Releases](https://github.com/tomusdrw/rust-web3/releases)
- [tomusdrw/rust-web3 on GitHub](https://github.com/tomusdrw/rust-web3)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tomusdrw-rust-web3