Alloy

Alloy connects applications to blockchains.

Alloy is a rewrite of [ethers-rs] from the ground up, with exciting new features, high performance, and excellent docs.

We also have a book on all things Alloy and many examples to help you get started.

Installation

Alloy consists of a number of crates that provide a range of functionality essential for interfacing with any Ethereum-based blockchain.

The easiest way to get started is to add the alloy crate with the full feature flag from the command-line using Cargo:

cargo add alloy --features full

Alternatively, you can add the following to your Cargo.toml file:

alloy = { version = "2", features = ["full"] }

For a more fine-grained control over the features you wish to include, you can add the individual crates to your Cargo.toml file, or use the alloy crate with the features you need.

A comprehensive list of available features can be found on docs.rs or in the alloy crate's Cargo.toml.

If you want to use ProviderBuilder::connect_anvil* helpers from the alloy meta-crate, enable the provider-anvil-node feature:

cargo add alloy --features provider-anvil-node

If you only need the alloy::node_bindings re-export, enable the node-bindings feature:

cargo add alloy --features node-bindings

If you are already using full, add node-bindings explicitly because full does not include it:

cargo add alloy --features "full,node-bindings"

If you depend on alloy-provider directly instead of the alloy meta-crate, enable the anvil-node feature there.

Examples

Connecting to a Provider

Here's a simple example of connecting to an Ethereum node and querying the latest block:

use alloy::providers::{Provider, ProviderBuilder};

# async fn example() -> Result<(), Box<dyn std::error::Error>> {
// Create a provider with the HTTP transport using the `reqwest` crate.
let rpc_url = "https://eth.llamarpc.com";
let provider = ProviderBuilder::new().connect(rpc_url).await?;

// Get the latest block number.
let latest_block = provider.get_block_number().await?;
println!("Latest block number: {latest_block}");

// Get chain ID.
let chain_id = provider.get_chain_id().await?;
println!("Chain ID: {chain_id}");
# Ok(())
# }

Network generic

Alloy is network-generic, allowing you to work with any Ethereum-compatible chain. Here's an example using Optimism (see op-alloy) to demonstrate this capability:

```rust,ignore use alloy::providers::{Provider, ProviderBuilder}; use op_alloy::network::Optimism;

async fn example() -> Result<(), Box> {

// Connect to Optimism mainnet. let rpc_url = "https://mainnet.optimism.io"; let provider = ProviderBuilder::new_with_network::().connect(rpc_url).await?;

Ok(())

}

```

For more examples, check out the Alloy examples repository.

Overview

This repository contains the following crates:

• [alloy]: Meta-crate for the entire project, including [alloy-core]
• [alloy-consensus] - Ethereum consensus interface
• [alloy-consensus-any] - Catch-all consensus interface for multiple networks
• [alloy-contract] - Interact with on-chain contracts
• [alloy-eip5792] - Types for the wallet_ Ethereum JSON-RPC namespace
• [alloy-eip7547] - EIP-7547: Inclusion Lists types
• [alloy-eips] - Ethereum Improvement Proposal (EIP) implementations
• [alloy-genesis] - Ethereum genesis file definitions
• [alloy-json-rpc] - Core data types for JSON-RPC 2.0 clients
• [alloy-ens] - Ethereum Name Service (ENS) utilities
• [alloy-network] - Network abstraction for RPC types
• [alloy-network-primitives] - Primitive types for the network abstraction
• [alloy-node-bindings] - Ethereum execution-layer client bindings
• [alloy-provider] - Interface with an Ethereum blockchain
• [alloy-pubsub] - Ethereum JSON-RPC publish-subscribe tower service and type definitions
• [alloy-rpc-client] - Low-level Ethereum JSON-RPC client implementation
• [alloy-rpc-types] - Meta-crate for all Ethereum JSON-RPC types
• [alloy-rpc-types-admin] - Types for the admin Ethereum JSON-RPC namespace
• [alloy-rpc-types-anvil] - Types for the Anvil development node's Ethereum JSON-RPC namespace
• [alloy-rpc-types-any] - Types for JSON-RPC namespaces across multiple networks
• [alloy-rpc-types-beacon] - Types for the Ethereum Beacon Node API
• [alloy-rpc-types-debug] - Types for the debug Ethereum JSON-RPC namespace
• [alloy-rpc-types-engine] - Types for the engine Ethereum JSON-RPC namespace
• [alloy-rpc-types-eth] - Types for the eth Ethereum JSON-RPC namespace
• [alloy-rpc-types-mev] - Types for the MEV bundle JSON-RPC namespace
• [alloy-rpc-types-tenderly] - Types for the Tenderly node's Ethereum JSON-RPC namespace
• [alloy-rpc-types-trace] - Types for the trace Ethereum JSON-RPC namespace
• [alloy-rpc-types-txpool] - Types for the txpool Ethereum JSON-RPC namespace
• [alloy-serde] - Serde-related utilities
• [alloy-signer] - Ethereum signer abstraction
• [alloy-signer-aws] - AWS KMS signer implementation
• [alloy-signer-gcp] - GCP KMS signer implementation
• [alloy-signer-ledger] - Ledger signer implementation
• [alloy-signer-local] - Local (private key, keystore, mnemonic, YubiHSM) signer implementations
• [alloy-signer-trezor] - Trezor signer implementation
• [alloy-signer-turnkey] - Turnkey signer implementation
• [alloy-transport] - Low-level Ethereum JSON-RPC transport abstraction
• [alloy-transport-http] - HTTP transport implementation
• [alloy-transport-ipc] - IPC transport implementation
• [alloy-transport-ws] - WS transport implementation
• [alloy-tx-macros] - Derive macro for transaction envelopes

Supported Rust Versions (MSRV)

The current MSRV (minimum supported rust version) is 1.91.

Alloy will keep a rolling MSRV policy of at least two versions behind the latest stable release (so if the latest stable release is 1.58, we would support 1.56).

Note that the MSRV is not increased automatically, and only as part of a patch (pre-1.0) or minor (post-1.0) release.

Contributing

Thanks for your help improving the project! We are so happy to have you! We have a contributing guide to help you get involved in the Alloy project.

Pull requests will not be merged unless CI passes, so please ensure that your contribution follows the linting rules and passes clippy.

Note on no_std

Because these crates are primarily network-focused, we do not intend to support no_std for most of them at this time.

The following crates support no_std:

Crate	Version Badge
alloy-eips
alloy-genesis
alloy-serde
alloy-consensus

If you would like to add no_std support to a crate, please make sure to update scripts/check_no_std.sh as well.

Credits

None of these crates would have been possible without the great work done in:

License

^{Licensed under either of Apache License, Version 2.0 or MIT license at your option.}

_{Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in these crates by you, as defined in the Apache-2.0 license, shall be dual licensed as above, without any additional terms or conditions.}