Pure Zig Ethereum library -- seeking feedback from searchers

Pure Zig Ethereum library – seeking feedback from searchers

We’re building eth.zig, a zero-dependency Ethereum library in Zig. We benchmarked it against Alloy on the operations that sit on the tx construction hot path:

Operation eth.zig Alloy Speedup
ABI encode (static) 29 ns 50 ns 1.72x
ABI decode (dynamic) 75 ns 133 ns 1.77x
u256 division 3 ns 12 ns 4.00x
u256 multiply 2 ns 5 ns 2.50x
UniswapV4 mulDiv (512-bit) 12 ns 17 ns 1.42x
Keccak-256 (32b) 128 ns 175 ns 1.37x

Full 26-op comparison: RESULTS.md (19 wins, 5 losses, 2 ties). Alloy wins on secp256k1 signing due to precomputed tables.

Zig’s comptime also lets us resolve ABI function selectors at compile time – zero runtime keccak for dispatch. This isn’t possible with Rust macros.

Why we’re posting here

We’re not pitching “replace your Rust stack.” The Alloy + Reth + Revm ecosystem is mature.

Our thesis is narrower: L2 MEV is a compute game. On Base, Arbitrum, OP Stack – the sequencer is centralized, everyone has roughly equal latency. The edge shifts to how fast you decode, evaluate, and construct. These are exactly the operations where eth.zig is fastest.

What we’re building for searchers

We’ve opened issues for the features we think matter and would love feedback on priority and API design:

Questions

  1. Does compute speed matter on L2? When latency is equalized, is encoding/decoding the marginal edge, or is it something else entirely?
  2. What’s your actual hot path? RPC round-trips, tx decoding, quote calculation, signing?
  3. Would you try a non-Rust library for a new L2 strategy, even if you’d never rewrite L1 infra?
  4. What’s missing from the feature list above?

Looking for honest signal, not validation.

ethzig.org | GitHub | @StrobeLabs

2 Likes