// the find
Vectorized/solady
Optimized Solidity snippets.
Solady is a gas-optimized Solidity library covering everything from ERC20/721/1155 token standards to fixed-point math, sorting, JSON parsing, and account abstractions. It's aimed at protocol developers who care about gas costs and want drop-in replacements for OpenZeppelin equivalents that are measurably cheaper. Think of it as the performance-focused alternative to OZ's more defensive, accessibility-oriented approach.
- The assembly usage is purposeful and well-commented — not just obfuscated code, but documented tricks like storage hitchhiking in ERC721 and packed slot tricks that produce real gas savings you can measure.
- Test coverage is extensive: nearly every contract has a corresponding Foundry test file, there's a 'Brutalizer' fuzzing harness for memory safety, and Wake (Python-based) tests add a second testing layer for critical contracts like ERC20 and ERC721.
- Multiple published audits (Cantina/Spearbit, Ackee, individual component audits) are included directly in the repo, which is more transparency than most libraries provide.
- The breadth of utilities (RedBlackTree, MinHeap, LibZip, JSONParser, WebAuthn, P256, EIP-7702 support) means you can stay in one dependency instead of pulling in five different micro-libraries.
- The 'experimental software, no warranties' disclaimer is real — several contracts (ERC4337, EIP7702Proxy, BLS) are moving targets as EIPs evolve, and the repo doesn't clearly signal which parts are production-stable vs. actively experimental.
- Heavy inline assembly makes auditing your own code harder when you extend these contracts. Mistakes in assembly don't get caught by the type system, and the optimizations can introduce subtle footguns that only appear in edge cases with non-standard ERC20s or unusual call contexts.
- ZKsync and other partial-EVM-equivalent chains require manual analysis via a script and may have no substitute implementations — the compatibility story for L2s is patchwork rather than systematic.
- The library is primarily maintained by one person (Vectorized), which is a bus-factor risk for a dependency used in production protocols. PR reviews and release cadence depend heavily on that single contributor's availability.