alloy-core: the type layer under Rust Ethereum code

The crates that everything else in the stack sits on

Alloy describes itself as the core libraries at the root of the Rust Ethereum ecosystem, and this repository is where that root lives. It is a rewrite of ethers-rs from the ground up, with new features, a focus on performance and better documentation, and ethers-rs is deprecated with users recommended to migrate. The crates in the workspace divide into three layers. alloy-primitives holds the primitive integer and byte types, which is the vocabulary everything else is written in. The ABI layer comes next, with alloy-sol-types providing compile-time ABI and EIP-712 implementations, alloy-dyn-abi providing run-time implementations of the same two things, and alloy-json-abi providing the full Ethereum JSON-ABI implementation. The macro and parser layer sits on top, with alloy-sol-macro providing the sol! procedural macro and alloy-sol-type-parser providing a simple parser for Solidity type strings, alongside syn-solidity, a syn-powered Solidity parser. alloy-core itself is the meta-crate for the entire project, the convenience dependency that pulls in the set. The project also publishes a book at alloy.rs and a separate examples repository, which is the intended path for a new user.

Compile-time ABI and run-time ABI are two different products

The most consequential choice in this repository is the one between the compile-time and the run-time crates, and it is a choice about your application rather than about the library. alloy-sol-types gives you ABI and EIP-712 implementations that are resolved at compile time, with the sol! macro generating the encoding and decoding code from a Solidity interface, which means the types are known to the compiler and the work happens before your program runs. alloy-dyn-abi gives you the same capabilities resolved at run time, which is what you want when the ABI is not known when you build, when it arrives from a file, from a contract or from a deployment, and when you want one implementation rather than a macro expansion per interface. alloy-json-abi sits alongside as the full implementation of the JSON-ABI format as the Solidity documentation defines it. A team that knows its interfaces at build time and wants the fastest possible encoding will reach for the compile-time crates, and a team building a general purpose tool that reads arbitrary ABIs at run time will reach for the dynamic ones. Both are supported, both are first class, and the workspace exposes them as separate crates so that you pull in only what you use.

Parsing Solidity is a solved problem here

Two crates cover the text side of Solidity, and they are worth separating because they do different jobs. alloy-sol-type-parser is a simple parser for Solidity type strings, which is the piece you need when you already know the type is a uint256 or a bytes32 and you want a type object for it. syn-solidity is the syn-powered Solidity parser, and syn is the Rust parsing library that this crate is built on, so this crate is the one that gives you a full syntax tree rather than a single type. The layering is the same idea as the ABI crates above, a fast narrow path and a slower complete one, and the reason both exist is that the macro needs to understand a whole Solidity file, while a runtime tool often only needs to read a type out of a string. The sol! macro itself ties the layers together, and it is the piece most users meet first, since it is how a Solidity interface becomes Rust types.

The MSRV policy is written down, which is rarer than it should be

The current minimum supported Rust version is 1.85, and the policy behind it is stated in a way that most projects do not bother with. Alloy keeps a rolling MSRV policy of at least two versions behind the latest stable release, with the example given being that if the latest stable release is 1.58, they would support 1.56. That is a deliberate buffer, so a Rust release never breaks your build on the day it lands. The readme then adds the detail that decides when you feel it. The MSRV is not increased automatically, and only as part of a patch release before 1.0 or a minor release after 1.0, which means the floor moves on a schedule you can plan around rather than on a commit that lands on a Tuesday. There is also a comment in the source telling the maintainers to update the Cargo.toml and the CI workflow when the MSRV changes, which is the kind of detail that tells you the policy is enforced rather than aspirational. The manifest confirms it, with edition 2024, rust-version 1.85 and the license field set to MIT OR Apache-2.0.

no_std everywhere, and the one WASM failure you will hit

Two portability commitments are stated at the top of the readme, and they shape what you can build. The first is that all crates in the workspace should support no_std environments, with the alloc crate, and if you find one that does not you are asked to open an issue. For a library that is used inside a node, a wallet or an embedded environment, that is a hard requirement rather than a nice-to-have, and the request that it hold for every crate in the workspace is how the guarantee stays true. The second is full support for the wasm targets, with one documented failure. When building for wasm32-unknown-unknown with the getrandom feature enabled, compilation of the getrandom crate will fail, and that is expected. There are two ways out, either disable the getrandom feature on alloy-core, or add getrandom to your own dependencies with the wasm_js feature enabled:

getrandom = { version = "0.4", features = ["wasm_js"] }

The project also states plainly that there is currently no plan to provide an official JavaScript or TypeScript accessible library interface, on the grounds that viem or ethers.js serve that need well, which is an honest boundary for a Rust library to draw.

The lint configuration is part of the design

The workspace manifest configures lints at the workspace level rather than leaving each crate to its own, and the list reads like a statement of intent. The Clippy group turns on dbg_macro, manual_string_new, uninlined_format_args, use_self, redundant_clone and missing_const_for_fn, each of which is a small correctness or consistency rule. The rust group is heavier: missing_copy_implementations and missing_debug_implementations so every public type behaves, missing_docs so the documentation is not optional, rust_2018_idioms, unreachable_pub and unused_must_use, and unnameable_types, which is the one that catches a public API leaking a type nobody can name. The rustdoc group is set to all = warn, so the generated documentation is held to the same standard as the code. The practical effect for a contributor is that the rules apply everywhere without a per-crate file, and the readme says pull requests will not be merged unless CI passes and asks that contributions follow the linting rules and pass clippy. The supporting tooling in the tree matches the same thoroughness, with a deny.toml for dependency policy, a release.toml for the release process, a cliff.toml for changelog generation, a typos.toml for spelling checks, a rustfmt.toml and a .git-blame-ignore-revs file.

Licensing, migration and the version ahead of the release

The licence is dual, Apache 2.0 or MIT at your option, with the two files in the repository, and the readme adds the clause that matters for contributors. Unless you explicitly state otherwise, any contribution intentionally submitted for inclusion in these crates shall be dual licensed as above without any additional terms or conditions, so a pull request from a company that needs a different licence has to say so explicitly rather than assume. The credits list the projects this work would not exist without, including ethers.js, rust-web3, ruint, ethabi, ethcontract-rs and guac_rs, which is a reminder that the Rust Ethereum ecosystem is a pile of shared work rather than a single lineage. On versions, the published releases are alloy-core v1.7.0 and v1.7.1 on 2026-08-25 and v1.7.2 on 2026-09-03, while the workspace manifest already reads 1.7.3, so the tree is one patch ahead of what you can install. The last push was on 2026-10-19, so the work is current, and a CHANGELOG.md and a SECURITY.md sit in the root alongside the release configuration.

Editorial conclusion

The core repository is worth building on if you are writing Rust that touches Ethereum data, because the type layer, the ABI machinery and the Solidity parsing are the parts every project ends up needing and the parts most likely to be subtly wrong. It is the wrong choice if you are on ethers-rs today and happy, since the migration is work with no functional gain, and it is the wrong choice if you need a JavaScript or TypeScript library, which the project explicitly does not plan to build. Before you start, pick your ABI flavour deliberately, since the compile-time and run-time crates are not interchangeable at the API level, and check the MSRV against your toolchain, because Alloy will not accept a build on an older compiler than it supports.

Frequently asked questions

Official sources

1. alloy-rs/core on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases