Solady: gas-optimized Solidity snippets for teams that will test them

What Solady actually replaces

Solady is a set of Solidity source files rather than a framework. The README describes it as "Gas optimized Solidity snippets" and the repository is organized as a tree of mixins and libraries under src: accounts, auth, tokens, utils. A team writing an ERC20 with EIP-2612 permits, an ERC721, an ERC4626 vault, a timelock, a reentrancy guard or an EIP-712 implementation would otherwise write those from scratch or copy them from another library. Solady supplies them pre-written and tuned for gas.

The intended audience is Solidity developers who already know what a storage slot costs and who are willing to read assembly to trust the code. The README is blunt about the trade: Solady "serves as a laboratory for cutting edge snippets that may be merged into Solmate". That sentence tells you the project sees itself as upstream experimentation, not as a frozen standard library. If you want a library that changes slowly and has a long compatibility promise, this framing is a warning sign. If you want the cheapest available implementation and you will test it yourself, it is the point.

How the snippets are structured and what that costs you

The contracts are not one monolith. Each file is an independent mixin or library, so an ERC20 import does not drag in ERC721. The README's contract tree lists roughly seventy entries, from ERC20 and ERC721 through utilities like LibClone, LibSort, MerkleProofLib, RedBlackTreeLib and JSONParserLib. That granularity is the main architectural decision: you assemble the surface you need, and you inherit only the risk in the files you actually import.

The cost of that granularity is integration work. The README states that most contracts are compatible with both upgradeable and non-upgradeable deployments, and that you must "call any required internal initialization methods accordingly". There is no single initializer contract that wires everything up for you. Mixins like Ownable, OwnableRoles, EnumerableRoles and TimedRoles are separate authorization models, and picking one is a design decision you make per contract, not a default the library makes for you.

A second structural detail matters for anyone deploying to non-Ethereum chains. The README warns that "some parts of Solady may not be compatible with chains with partial EVM equivalence" and points to a preprocessing script for the ZKsync stack. Compatibility is therefore per-file, not per-library, and the repository ships a tool to check it rather than a blanket guarantee.

Installing Solady with Foundry or npm

The README gives two installation paths. Foundry projects install directly from the repository:

forge install vectorized/solady

After that command the sources land under lib/solady and you import from the src tree, following the directory layout printed in the README, such as the tokens or utils directories. The README does not print a worked import example.

Hardhat and other npm-based projects use the published package instead. The package.json lists the package name as solady, version 0.1.26, with main and module both pointing at js/solady.js and types at js/solady.d.ts. Only src/**/*.sol and js/**/* are published, so the test and prep directories are not part of the npm payload.

npm install solady

What you should see after either command is the Solidity sources available to your compiler. Because the README requires you to call internal initialization methods yourself, an upgradeable deployment needs the initializer called explicitly; a regular deployment does not. Write a test that exercises the mixin with your own contract before you trust it.

Where Solady is the wrong tool

The safety section of the README is unusually direct for a library this widely referenced. It states that Solady is "experimental software" provided on an "as is" and "as available" basis, that the authors give no warranties and are not liable for loss, and that while it has been heavily tested, "there may be parts that may exhibit unexpected emergent behavior when used with other code, or may break in future Solidity versions". It then asks users to always include their own thorough tests.

Take that literally. If your team cannot review assembly-heavy code, or cannot maintain a test suite that covers every mixin you import, Solady shifts risk onto you rather than removing it. The failure mode is not a compile error; it is a subtle interaction between your contract and a snippet that behaves differently under a condition your tests never hit. The README's own wording about emergent behavior when combined with other code is the clearest statement of this boundary.

There is a second, narrower case. If you are deploying to a chain with partial EVM equivalence, some files may not work at all. The README directs ZKsync-stack deployers to run a compatibility scan and to investigate files with non-zero scores. That means the library's suitability is a per-file question on those chains, and a contract that works on one target may not work on another without changes.

Solady versus OpenZeppelin Contracts

The relevant comparison for most teams is OpenZeppelin Contracts, because both ship ERC20, ERC721, ERC4626, Ownable, EIP-712 and proxy tooling. The difference is the design target. Solady optimizes for gas and for small, composable files, and its README frames the repository as a laboratory whose snippets may be merged into Solmate. OpenZeppelin optimizes for a stable, widely deployed contract suite with a long release history and a broad compatibility surface.

That difference shows up in what you get alongside the code. Solady's repository includes an audits directory, but the README does not describe audit coverage per contract, so you cannot assume a given mixin has been reviewed just because the directory exists. The README also does not document a deprecation policy or a rollback procedure for a bad release. If your project needs a documented support window and a predictable upgrade path, that is a real gap, and OpenZeppelin's model is the better fit.

The honest summary is that Solady is the cheaper option at runtime and the more expensive option in engineering time. Both statements come from the same design choice, and neither library is wrong. Pick based on whether your team would rather pay in gas or in review hours.

Licence, releases and the cost of staying current

Solady is MIT licensed. LICENSE.txt sits at the repository root and package.json declares "license": "MIT". For most integrations that means you can use, modify and redistribute the sources, including in closed products, provided you keep the copyright and permission notice. That is a general description of the MIT terms, not legal advice; read LICENSE.txt and your own counsel's guidance before shipping.

The maintenance picture is active but fast-moving. The last push to main was on 2026-09-02, and the most recent release listed is v0.1.26 from 2025-08-25, preceded by v0.1.24 and v0.1.23 on 2025-07-17. The version in package.json is 0.1.26, matching the latest release. The 0.1.x line signals pre-1.0, and the README reinforces that with its warning about breaking on future Solidity versions.

Upgrade cost is therefore not zero. Because you import individual source files rather than calling a stable runtime API, a change to a mixin's internals can alter the bytecode you deploy even when your own code is untouched. Pinning the version and reading the diff between releases is the practical minimum. The repository does not document a rollback procedure for a release that turns out to be faulty, so plan for that yourself.

Editorial conclusion

Adopt Solady when you are comfortable reading inline assembly and will write your own tests around the mixins you pull in. Do not adopt it as a drop-in replacement for a fully audited contract suite, and do not assume every snippet runs on a chain with partial EVM equivalence. Before integrating, verify three things: the version pinned in package.json, whether the specific contract you need is covered by a report in the audits directory, and whether any file you import trips the ZKsync compatibility scan.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. Vectorized/solady on GitHub