nuthatch

nuthatch

Turn an EVM contract's history into a local SQL database. One Rust binary, no Postgres, no

subgraph to write, and an MCP server built in.

· Website: www.nuthatch-indexer.com

Also: self-hosted Etherscan-compatible history for the chains that lost their free tier. Base and BNB Chain, plus Gnosis, on your own RPC (Base and BNB Chain need an archive node with tracing): examples/paywalled-chains.

curl -fsSL https://nuthatch-indexer.com/install.sh | sh

export PATH="$HOME/.local/bin:$PATH" nuthatch init 0xC02aaA39b223FE8D0A0e5C4F27eAD9083C756Cc2 --alias weth nuthatch dev --backfill 300

Then, in a second terminal:

nuthatch sql "SELECT count(*) FROM weth__transfer"

The installer covers macOS Apple Silicon and Linux x86_64 and aarch64, and the export adds its directory, which a fresh macOS shell lacks. init indexes WETH and detects its chain. The block carries no # comments because zsh, the macOS default, does not treat a pasted # as one: it passes the rest of the line on as arguments.

The Linux binary needs glibc 2.35 or newer to run from 4.1.0, which is also what it is built on; 4.0.x ran on 2.34; older systems and Alpine have a static x86_64 build. On other platforms, build from source with Rust 1.95.0 (docs/install.md). init creates a nest: a directory holding the contract's ABI, its config and, once dev runs, its indexed data. --backfill 300 starts 300 blocks behind the tip, about an hour of mainnet, so there are rows to query within seconds on the bundled public endpoints. Without it, dev backfills from the contract's deployment block: for WETH that is 21 million blocks, a long backfill on free public endpoints and a job for your own RPC (--rpc).

Those five lines, run as written on the 4.10.1 release on 2026-10-05, took 13 s from the curl to a non-zero count in a clean macOS shell on an M5 Pro, and 21 s in a fresh ubuntu:24.04 container (docs/readme-check-2026-10-05.md, which records every command in this file).

Like Ponder, nuthatch reads the chain over JSON-RPC, so it needs an endpoint, and a provider may charge for one. The public endpoints it bundles are for trying it out, not for keeping it running. It complements The Graph rather than replacing it: a subgraph serves an application from a network of indexers, while a nest puts a contract's history in a database on your own machine.

Why. Getting at a contract's history usually means writing a subgraph or handler code, running a database, or renting someone else's copy. nuthatch generates the tables from the ABI, runs as one process with nothing else to install, and keeps the data on your machine: at most 2 GB of RAM per chain, no telemetry unless you opt in, no account. The built-in MCP server lets Claude or any MCP client query it.

---

What you get

• No authoring. init 0xAddr resolves the ABI (Sourcify, then Etherscan), generates the schema and decoders, and scaffolds the project. You write nothing.
• No infra. A single Rust binary. Embedded mode needs no Postgres, no Docker, no IPFS.
• It's just SQL. Your contract's events become per-event tables you query with real analytical SQL - the live tip *and* sealed history, one surface.
• It's yours, and it's small. ≤2 GB RAM for single-chain tip-following, CI-enforced. No telemetry by default, no mandatory API token, ever: the one opt-in is a head count at init (nuthatch count), and its totals are public. Most people say no or are never asked, so they are floors.

---

Who runs it

• [Lodestar](https://www.lodestar-dashboard.com), an analytics dashboard for The Graph Protocol on Arbitrum One, served its panels from self-hosted nests instead of The Graph gateway until the deployment was withdrawn on 2026-10-13 (record).
• [GraphOps](https://graphops.xyz), an indexer and core developer on The Graph, is a design partner. Its feedback is what led to maintained entities (RFC-0041).

An earlier example, now finished: [Arcaidia](https://arcaidia.io), a speed layer over Circle's CCTP built at ETHOnline 2026, read its indexed state from two nests on Ethereum Sepolia and Arc Testnet: its solver discovered intents there, its settlement agent tracked CCTP there, and its web console rendered from them. The nests were stopped on 2026-09-29.

More at nuthatch-indexer.com/stories.

There is no hosted platform. We will run a nest for you on the stock binary, with no billing and no accounts: ask on the Discord.

---

Install

curl -fsSL https://nuthatch-indexer.com/install.sh | sh

That downloads the prebuilt binary for your platform from the latest release, verifies its SHA-256, and installs it to ~/.local/bin (override with NUTHATCH_INSTALL_DIR). No compiler is involved. A stock macOS shell does not have ~/.local/bin on its PATH, which is why the quickstart above exports it; add the same line to ~/.zshrc (or ~/.bashrc) to keep it for new terminals. Prebuilt binaries cover macOS on Apple Silicon and Intel and Linux x86_64 and aarch64 (aarch64 from the release after 4.11.0, Intel Mac from the release after 5.16.0) and are attached to every release with their checksums, if you would rather fetch one by hand. The Intel Mac binary is the default build only and has not yet been run on Intel hardware.

The Linux binary is dynamically linked and needs one thing, measured off the published artifact with objdump -T rather than inferred:

• glibc 2.35 or newer - the measured ABI floor, and also what the release is *built* on. Up to 4.0.2 the binary referenced no symbol newer than GLIBC_2.34, so 2.34 was what you needed to run it and 2.35 only what we compiled it on (#978); 4.1.0 references hypot at GLIBC_2.35, where libm re-versioned it, so the two numbers now agree.

It links libc, libm and libgcc and no C++ runtime. Releases before 4.1 embedded DuckDB and also needed libstdc++ from GCC 11.

Debian 12 and Ubuntu 22.04 clear it. RHEL 9 and Amazon Linux 2023 ship glibc 2.34 and ran 4.0.x; from 4.1.0 they need the source build, or nuthatch-x86_64-unknown-linux-musl.tar.gz, a static build with no glibc floor (from the release after 5.16.0; it uses musl's allocator, not jemalloc, so its behaviour under load is unmeasured).

Verify who built it. Every release binary carries a build provenance attestation, which a checksum cannot give you:

gh attestation verify nuthatch-x86_64-unknown-linux-gnu.tar.gz --repo nuthatch-org/nuthatch

From source, which is the only route on a platform we do not publish a binary for:

rustup toolchain install 1.95.0

cargo +1.95.0 install --git https://github.com/nuthatch-org/nuthatch nuthatch

The +1.95.0 is required: cargo install --git ignores the repo's toolchain pin, and a newer default toolchain fails to compile a dependency.

Container images are published per release to ghcr.io/nuthatch-org/nuthatch - : for embedded, : -scaled for the scaled build. The image ships the *same binary attached to the release*, so the two cannot drift.

docs/install.md has the detail behind each of these: how the ABI floor is measured, what the attestation proves and what --repo is for, and why the toolchain pin exists.

Chains. Ethereum, Arbitrum One, Base, BSC, Polygon, Gnosis, Optimism, Monad and Robinhood Chain are *built in*, with measured public endpoints and tuned finality settings - omit `--chain` and nuthatch probes each for your contract's bytecode and picks the one it lives on. Point at your own node with --rpc.

Any other EVM chain works too - World Chain, Base Sepolia, your own devnet. Name the chain and say where it lives:

nuthatch init 0xADDR --chain world-chain --rpc https://your-endpoint.example

The chain id is read from the endpoint itself, so there is nothing to look up or type wrong. On one of the nine built-in names --rpc is not consulted for the chain id, but it is the pool: your endpoints replace the bundled public ones outright. Omit --rpc on an unregistered name and the refusal tells you the remedy.

See running an unlisted EVM chain for the finality caveat, which is the part worth reading: a chain whose finalized tag runs close to the tip needs a depth-based policy instead, or you seal immutable Parquet that could never be corrected.

Bring your own RPC endpoint

nuthatch assumes a paid RPC endpoint, or your own node, for anything you intend to keep running. That is the golden path.

Worth knowing, since we are being precise about it: most figures currently in docs/benchmarks.md were measured against *public* endpoints, and that is a known weakness of those numbers rather than a recommendation - a benchmark taken through a rate-limited endpoint measures the endpoint. On one workload the network was 99.3% of backfill wall clock (the same tape live against a public endpoint and replayed from disk, 2026-08-23, in docs/benchmarks.md), which is why the replay rig (RFC-0039) exists and why those figures carry that caveat on the page itself.

The free public endpoints bundled per chain exist for one job: so init → dev works with zero setup. Treat them as testing and initial validation. Why they are not fine for real work, said here rather than discovered at 3am:

• They are rate-limited and shared, and throughput varies by the hour.
• They fail intermittently, and not always loudly. nuthatch fails over across the pool and retries, but a window that every endpoint refuses stalls until one recovers; /ready reports stalled when that happens.
• Deep backfills will crawl or stop, and many free endpoints prune old blocks, so a backfill from a 2020 deploy block can fail partway.

Check an endpoint before you trust a backfill to it. nuthatch doctor probes one and reports the largest getLogs window it will actually serve, its batch limit, and whether it has archive history - measured, not taken from the provider's documentation:

nuthatch doctor --rpc https://your-endpoint.example --address 0xADDR

Use your own endpoint for anything you care about - your own node, or a paid provider:

nuthatch init 0xADDR --chain arbitrum-one --rpc https://your-endpoint.example/arbitrum

nuthatch dev --rpc https://your-endpoint.example/arbitrum # or set rpc_urls in nuthatch.toml

--rpc is repeatable, and nuthatch round-robins across the pool with per-endpoint health tracking, so listing two or three endpoints gets you failover as well as throughput. Every endpoint in a pool must be on the same chain - nuthatch verifies this at startup and refuses to run against a mixed pool, since indexing against the wrong chain corrupts state silently.

---

Querying your data - the whole point

Every declared event becomes